Release candidate for IDE 1.6.0 (rc1)

[c.ma...@bug.st]

Hi,

I've packaged a release candidate Arduino IDE 1.6.0rc1.

Here the download links:

Linux 32:
http://downloads.arduino.cc/arduino-1.6.0rc1-linux32.tgz

Linux 64:
http://downloads.arduino.cc/arduino-1.6.0rc1-linux64.tgz

Mac OS:
http://downloads.arduino.cc/arduino-1.6.0rc1-macosx.zip

Mac OS for Java 7:
http://downloads.arduino.cc/arduino-1.6.0rc1-macosx-java7.zip

Windows installer:
http://downloads.arduino.cc/arduino-1.6.0rc1-windows.exe

Windows ZIP:
http://downloads.arduino.cc/arduino-1.6.0rc1-windows.zip

besides the usual bugfix/improvements activity, there are no significant
differences between version 1.5.8 and 1.6.0rc1. This pre-release is only
for testing purposes to avoid last minutes bugs.

If everything goes well the final 1.6.0 stable will be released in two
weeks.

Thanks for testing!

C

[Paul Stoffregen]

Looks like my serial monitor speedup didn't get ported into the 1.5.x
branch yet?

I'm running 1.6.0-rc1 now, with Due printing fast. With only couple
minutes, it's already up to 3 GB memory and consuming nearly 100% CPU.

[Andrew Kroll]

As I posted on basecamp, I'll repeat my findings here, so that others may see what I have found, and what I have ran into within my own code.

GCC: this is the only GCC bug I have managed to trip up:
GCC 4.8.1/4.7.2 has an optimizer bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58545
As a temporary fix, I discovered that using __attribute__((optimize("0"))) in the function definition avoids the problem, at the cost of slightly larger code.

I'm falling into many very nasty bugs with the  G++. These same issues are present on older versions as well. and all related to extending classes. I am working to develop a simple demo of what is happening for the newly discovered one and any others that I can manage to find,  but that may be a few days.

Thunks that use variadic args. This bug is documented and already reported gnu's bug tracking.
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53440
perhaps there is use an option we can pass to G++ to fix this? Note that the AVR compiler fails here too.

More class extending issues:
Incorrect non-virtual thunk choice due to calculating values in advance.
A critical value gets optimized out, causing the wrong code path to be chosen. I have to see if the same incorrect path is chosen with a virtual thunk too. This would point directly to a code generator or optimizer problem, which seems to be causing many problems in extending classes. Please note that the same identical code that I have works without any issue at all with the AVR G++ compiler, thus it is absolutely a bug.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Mikael Patel]

I have rebuilt Cosa with 1.6.0rc1 and recompiled all supported boards and all example sketches. I have also rebuilt and run the benchmark suite. Please find the logs in commit. https://github.com/mikaelpatel/Cosa/commit/bf8a4ed97b338017a0e3e04d14b9c3e60f986dfb

They all compiled correctly and the benchmarks are as for 1.5.8.

Cheers! Mikael

[Mikael Patel]

Opps! Forgot an important comment. I have rerun some of the benchmarks in the IDE and see the improvement to the build with regard to avoiding recompile. The extra core library update has also been removed. Good job! Mikael

Den torsdagen den 11:e december 2014 kl. 18:41:27 UTC+1 skrev c.maglie:

[c.ma...@bug.st]

Il 11/12/2014 23:47, Paul Stoffregen ha scritto:
> Looks like my serial monitor speedup didn't get ported into the 1.5.x
> branch yet?

yes, we didn't had the time to port/debug the serial monitor speedup to
1.6 yet.

I decided to not postpone the release of the rc1 more, but I'm confident
that the serial monitor speedup will be included in the final 1.6.0.

C

[c.ma...@bug.st]

Hi Andrew,

Il 11/12/2014 23:51, Andrew Kroll ha scritto:
> As I posted on basecamp, I'll repeat my findings here, so that others
> may see what I have found, and what I have ran into within my own code.

The developers list a more appropriate place indeed.

Since this isn't something we can easily solve in time for the 1.6
release, starting a new specific thread with a meaningful subject may be
useful to not lose this discussion, for example if someone wants to
search it from the archives.

> GCC: this is the only GCC bug I have managed to trip up:
> GCC 4.8.1/4.7.2 has an optimizer bug:

[..cut..]

> classes. Please note that the same identical code that I have works
> without any issue at all with the AVR G++ compiler, thus it is
> absolutely a bug.

Thanks for the heads up!
Do you think we can do something about that? I mean, apart waiting for
the gcc developers to fix the bug upstream?

C

[Matthew Ford]

Almost 2 years ago now I requested the option to turn off compiler
optimisations to assist in tracking down coding problems.
Replies were along the line of "cannot see the need"
An option like that could be useful here.
matthew

[Paul Stoffregen]

On 12/12/2014 10:19 AM, Matthew Ford wrote:
> Almost 2 years ago now I requested the option to turn off compiler
> optimisations to assist in tracking down coding problems.

Well, during those 2 years, Arduino's underlying system has changed from
hard-coded settings to a highly configurable system. So it looks like
your request has happened.

Perhaps you're simply not aware of this? Or maybe you don't like
editing the platforms.txt file to access more obscure/technical settings?

[Andrew Kroll]

I think he is looking for a menu that lists these options. Best would be a per-sketch/per-board settings. E.G a menu that has all the sketch defaults for a compile and then sub-menu for each board or perhaps arch if required, although the dev of the code should be able to use the usual #if's for this. Who knows though, perhaps it would be handy, even if complicated to a noob. If this would be considered too complicated, have it under some sort of advanced settings toggle to allow editing, but always read the settings if present.. The idea is that the noob can get a sketch with the settings already included from someone who is more advanced, and the code will just work, without the noob having to touch anything. Might be also cool to have some sort of standard header that is always included in each lib... Although, I kind-of already know how to do this using an #include-next hack.

[Andrew Kroll]

More info (as posted on basecamp too, in order to get the word out better...)

  The  bug has been discovered.
I'll put up a sample showing how to cause the problem, if you can't figure but what I am talking about.
For now, I'll explain the problem.

Apparently 'true' and 'false' are not the same on both AVR and ARM platforms due to an assumption.  This is causing the arm G++ to attempt generate even more code paths, and then choosing the wrong code path in very specific circumstances.

Here is what is going on:
For AVR the Arduino devs decided that in Arduino.h to use a define for true and false instead of using the compiler keywords for C++...
While this is all fine and dandy for C, it isn't for C++.
In C++ true and false are type bool.
boolean is typedef'd to uint8_t on both platforms.
While the 'value' and storage size is identical, the actual meaning is different.

when you use 'boolean' type like this:
void someclass::foo(boolean bar) {
// code...
}

...and then someplace else try this...

someclass::foo(true);

... the bool type isn't the same as the typedef'd boolean, which is uint8_t.
There isn't an overloaded class method for it. and on ARM, the define is properly omitted.

Here comes the fun part...

When you just have all the object files linking (the IDE does this for libraries), it appears that the linker actually is ignoring the types completely and starts using thunks.
These thunks will short-circuit code paths and take an incorrect path.
The compiler isn't type-checking methods correctly, and is applying some incorrect thunk code as a leaking bandage based on incorrect assumptions.

If instead when the linker tries to link using ar files, it can't, because the type is different... This is actually the correct behavior. It shouldn't be able to link it.

I also managed to trip another bug, where the file and line indicating where the ar is broken is incorrect. I have not checked to see if the same problem would occur on AVR if I changed Arduino.h to properly not define them if in C++, but I will do that just to compare.

[Chris Lilley]

Hello,

Tuesday, December 16, 2014, 6:45:53 AM, Andrew wrote:
> For AVR the Arduino devs decided that in Arduino.h to use a
> define for true and false instead of using the compiler keywords for C++...
> While this is all fine and dandy for C, it isn't for C++.
> In C++ true and false are type bool.

Surely then the solution is to remove those superfluous defines in
Arduino.h?


--
Best regards,
Chris Lilley, Technical Director, W3C Interaction Domain

[Matthew Ford]

would making these changes in the Arduino.h solve this problem?

// #define true 0x1
// #define false 0x0

//typedef uint8_t boolean;
#define boolean bool

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Andrew Kroll]

Not bool, _Bool :-) go look and read stdbool.h.

[Matthew Ford]

<stdbool.h>  contains
#define	bool	_Bool

and many arduino methods are defined using bool

my understanding is that
 When a symbol is evaluated, it generates a string of tokens which are scanned again.

so that boolean -> bool -> _Bool 

[Andrew Kroll]

Correct. Tokens are recursively scanned on the current line until all are resolved.