Re: [buildrobot] avr-rtems
On Tue, 2013-11-26 04:28:41 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build log is available at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38764 . Eric seems to be not (or no longer?) reachable with his listed email address: ,--- | Eric Weddington (eric.wedding...@atmel.com)mailto:eric.wedding...@atmel.com | Your message can't be delivered because delivery to this address is | restricted. `--- MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:Arroganz verkürzt fruchtlose Gespräche. the second : -- Jan-Benedict Glaw signature.asc Description: Digital signature
Re: [buildrobot] alpha64-dec-vms / alpha-dec-vms
On 26 Nov 2013, at 04:23, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Hi! Build log is available at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=36942 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40027 Yes, we are aware of that. Basically, the openvms configuration doesn't yet support C++ :-( There is scheduled work to support C++. Tristan.
infrastructure to detect whether code originates from macro expansion
Hi, in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Manuel López-Ibáñez mentioned that starting with gcc 4.7 there is supposed to be infrastructure to figure out for diagnostics whether the location of an error was created by macro expansion and that this can be used to disable a warning in that case. Can anyone point me to the name of a function/macro I should use to check that or another example in the code that already does this? I mean I can see how maybe_unwind_expanded_macro_loc figures out whether it needs to unwind macro expansions but I am not sure whether this linemap_lookup/linemap_macro_expansion_map_p stuff is what I am supposed to use in the place where I check for the diagnostics to emit or whether there is a higher level abstraction of this functionality. Additionally I found that the mentioned linemap_lookup/linemap_macro_expansion_map_p stuff seems to produce useful information on the gcc 4.8 branch with the example from the bug report but not on the gcc 4.7 branch. On the latter I actually don't get the macro unwinding information. Thus it seems that this is not the infrastructure Manuel was refering to. Robert
Re: gcc's obvious patch policy
On Tue, Nov 26, 2013 at 10:01:23AM +0100, Steven Bosscher wrote: On Tue, Nov 26, 2013 at 6:17 AM, Alan Modra wrote: Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote: This patch is obvious and it fixes breakage. Please go ahead and commit it. Sorry to pick on you here Steven, but this doesn't meet gcc's definition of an obvious patch. Don't believe me? See http://gcc.gnu.org/svnwrite.html#policies Hmm I guess the patch will have to be reverted, then :-) Or maybe this would be under the banner of We don't want to get overly anal-retentive about checkin policies. We are not amused. Some lack-wit adviser told us it would be wise to not seem anal-retentive, whatever that means, and thus we allowed comment fixes against our better judgement. Don't you dare extend our magnanimous dispensation. :-) In any case, it's not unprecedented that obviously obvious patches get checked in even if they're not obvious according to that policy. To list a few from just this month: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02989.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02975.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02970.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02972.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02496.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02331.html Oh no! There I am, listed with a bunch of other sinners. -- Alan Modra Australia Development Lab, IBM
Re: [buildrobot] avr-rtems
Is avr-elf not in the set your are building? This looks like a generic target build issue and not something architecture specific. -Joel Jan-Benedict Glaw jbg...@lug-owl.de wrote: Hi! Build log is available at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38764 . g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c In file included from ../../../gcc/gcc/c-family/c-common.c:29:0: ../../../gcc/gcc/c-family/c-common.c: In function ‘void c_common_nodes_and_builtins()’: ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5537:22: note: in expansion of macro ‘get_identifier’ char16_type_node = get_identifier (CHAR16_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5537:22: note: in expansion of macro ‘get_identifier’ char16_type_node = get_identifier (CHAR16_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5537:22: note: in expansion of macro ‘get_identifier’ char16_type_node = get_identifier (CHAR16_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5537:22: note: in expansion of macro ‘get_identifier’ char16_type_node = get_identifier (CHAR16_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5553:22: note: in expansion of macro ‘get_identifier’ char32_type_node = get_identifier (CHAR32_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5553:22: note: in expansion of macro ‘get_identifier’ char32_type_node = get_identifier (CHAR32_TYPE); ^ ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5553:22: note: in expansion of macro ‘get_identifier’ char32_type_node = get_identifier (CHAR32_TYPE); ^ cc1plus: all warnings being treated as errors MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:http://catb.org/~esr/faqs/smart-questions.html the second :
Re: [buildrobot] microblaze-elf / microblaze-linux
Was microblaze-rtems attempted? I would have expected a failure like these if so. --joel Jan-Benedict Glaw jbg...@lug-owl.de wrote: Hi! Build logs at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718 (I also think that we'd have the little endian version on the target list at contrib/config-list.mk ...) g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c ../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’: ../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *recog_data.dup_loc[i] = orig_dup[i]; ^ cc1plus: all warnings being treated as errors make[2]: *** [reload1.o] Error 1 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second :
Re: [buildrobot] avr-rtems
On Tue, 2013-11-26 06:31:44 -0600, Joel Sherrill joel.sherr...@oarcorp.com wrote: Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build log is available at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38764 . g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c In file included from ../../../gcc/gcc/c-family/c-common.c:29:0: ../../../gcc/gcc/c-family/c-common.c: In function ‘void c_common_nodes_and_builtins()’: ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull] ? get_identifier_with_length ((str), strlen (str)) \ ^ ../../../gcc/gcc/c-family/c-common.c:5537:22: note: in expansion of macro ‘get_identifier’ char16_type_node = get_identifier (CHAR16_TYPE); ^ [...] Is avr-elf not in the set your are building? This looks like a generic target build issue and not something architecture specific. It is, but it compiled okay, see details in any of it's builds: http://toolchain.lug-owl.de/buildbot/?limit=5000target=avr-elf -- http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40118 -- http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38774 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 17:45 @Eimann Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr the second : 17:46 @jbglaw Eimann: Wofür braucht man das? 17:46 @jbglaw Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein Gegeüber hören kann. Und daß mein Gegenüber mich versteht... 17:47 @KrisK jbglaw: was du meinst ist wodka. 17:47 @KrisK jbglaw: es klingelt und man hört stimmen signature.asc Description: Digital signature
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill joel.sherr...@oarcorp.com wrote: Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build logs at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718 (I also think that we'd have the little endian version on the target list at contrib/config-list.mk ...) g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c ../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’: ../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *recog_data.dup_loc[i] = orig_dup[i]; ^ cc1plus: all warnings being treated as errors make[2]: *** [reload1.o] Error 1 Was microblaze-rtems attempted? I would have expected a failure like these if so. No, it wasn't. It's not on the list of targets in .../gcc/contrib/config-list.mk . So we'd probably add that to the target list I guess? I'll propose a patch later tonight (adding to another pending patch to config-list.mk) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: ...und wenn Du denkst, es geht nicht mehr, the second : kommt irgendwo ein Lichtlein her. signature.asc Description: Digital signature
Re: [buildrobot] First results of running contrib/config-list.mk
On Mon, Nov 25, 2013 at 7:20 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: The two build robot instances that schedule jobs using contrib/config-list.mk are done with two rounds. I haven't looked at the details (and thus there are no patches), but I'd like to point out the results. Depending on the host, gcc/g++ is: gcc20: g++ (GCC) 4.9.0 20131122 (experimental) gcc76: g++ (GCC) 4.9.0 20131121 (experimental) Binutils were not freshly build, so they're older. I tried to find the respective maintainers and Cc'ed them, but that wasn't obvious in some cases. But I hope we'll see some fixes soon. At least a good number of the -Werror build breakages look quite simple to fix. Thank you for doing this. Ian
Using BIGGEST_ALIGNMENT to remove alignment constraints
Hi,
I am slightly confused about the BIGGEST_ALIGNMENT docs which state:
Biggest alignment that any data type can require on this machine, in bits.
Note that this is not the biggest alignment that is supported, just the biggest
alignment that, when violated, may cause a fault.
What kind of fault would this be?
We currently have it set to 64, word_size. However, we really have no alignment
restrictions being able to align data types to byte boundaries if necessary.
Therefore, from this piece of code:
unsigned int
get_mode_alignment (enum machine_mode mode)
{
return MIN (BIGGEST_ALIGNMENT, MAX (1, mode_base_align[mode]*BITS_PER_UNIT));
}
I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just align the
data at any byte boundary. Would this be a fair use of BIGGEST_ALIGNMENT? If
not, then should BIGGEST_ALIGNMENT be equal to the largest supported mode on
our machine? I am quite confused about what fault it could happen in
BIGGEST_ALIGNMENT is violated, therefore for our machine I guess
BIGGEST_ALIGNMENT can be as high as possible.
Paulo Matos
Re: [buildrobot] microblaze-elf / microblaze-linux
On 26 November 2013 14:51, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill joel.sherr...@oarcorp.com wrote: Was microblaze-rtems attempted? I would have expected a failure like these if so. No, it wasn't. It's not on the list of targets in .../gcc/contrib/config-list.mk . So we'd probably add that to the target list I guess? I'll propose a patch later tonight (adding to another pending patch to config-list.mk) The idea if config-list.mk is not to build every conceivable target configuration, but to give a reasonable converage of the different target architectures and OS/library configurations so that you can effectively test a patch with unknown target-specific impact. Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included?
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 2013-11-26 15:21:12 +, Joern Rennecke joern.renne...@embecosm.com wrote: On 26 November 2013 14:51, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill joel.sherr...@oarcorp.com wrote: Was microblaze-rtems attempted? I would have expected a failure like these if so. No, it wasn't. It's not on the list of targets in .../gcc/contrib/config-list.mk . So we'd probably add that to the target list I guess? I'll propose a patch later tonight (adding to another pending patch to config-list.mk) The idea if config-list.mk is not to build every conceivable target configuration, but to give a reasonable converage of the different target architectures and OS/library configurations so that you can effectively test a patch with unknown target-specific impact. Is it like that? My impression is/was that people collected a list of targets they somewhat care for. With around 200 configurations, among them some that are quite similar, adding another just adds 1/2%, which I'd call neglectible. Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? Probably not (without having looked at what that configuration would actually pull in.) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser. the second : signature.asc Description: Digital signature
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/25/13 19:26, Jan-Benedict Glaw wrote: Hi! Build logs at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718 (I also think that we'd have the little endian version on the target list at contrib/config-list.mk ...) g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c ../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’: ../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *recog_data.dup_loc[i] = orig_dup[i]; ^ cc1plus: all warnings being treated as errors make[2]: *** [reload1.o] Error 1 I do not see this error in my build of microblaze-elf. I notice that there are flags in your compile that do not appear in mine: -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror I don't see any warnings in my build, either. My build is using gcc-4.1.2 (on CentOS 5.9) as a build compiler. My guess is that this is the cause of the differences. I'll upgrade to building with a more recent version of gcc and investigate this failure, but I won't be able to look at this for about two weeks. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [buildrobot] pdp11-aout
On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Hi! Build log at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40865 g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o cfgexpand.o -MT cfgexpand.o -MMD -MP -MF ./.deps/cfgexpand.TPo ../../../gcc/gcc/cfgexpand.c ../../../gcc/gcc/cfgexpand.c: In function ‘basic_block_def* expand_gimple_cond(basic_block, gimple)’: ../../../gcc/gcc/cfgexpand.c:2027:65: error: comparison is always true due to limited range of data type [-Werror=type-limits] else if (BRANCH_COST (optimize_insn_for_speed_p (), false) 4) ^ cc1plus: all warnings being treated as errors make[2]: *** [cfgexpand.o] Error 1 Interesting. In the pdp11 target, BRANCH_COST is either 0 or 1. So yes, that comparison is always true. Is there a requirement that all targets must have branch cost that it, at least some of the time, 4 or greater? If so, why? If not, then I suppose cfgexpand.c could be changed to defeat this message, but how, or why? In general, it seems perfectly reasonable to have code guarded by conditions that may be always true, or always false. That's what we have optimizers for. Defeating such optimizations by calling them an error seems like a bad idea. paul
Re: Using BIGGEST_ALIGNMENT to remove alignment constraints
On 26/11/13 16:12, Paulo Matos wrote:
Hi,
I am slightly confused about the BIGGEST_ALIGNMENT docs which state:
Biggest alignment that any data type can require on this machine, in
bits. Note that this is not the biggest alignment that is supported,
just the biggest alignment that, when violated, may cause a fault.
What kind of fault would this be? We currently have it set to 64,
word_size. However, we really have no alignment restrictions being
able to align data types to byte boundaries if necessary. Therefore,
from this piece of code: unsigned int get_mode_alignment (enum
machine_mode mode) { return MIN (BIGGEST_ALIGNMENT, MAX (1,
mode_base_align[mode]*BITS_PER_UNIT)); }
I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just
align the data at any byte boundary. Would this be a fair use of
BIGGEST_ALIGNMENT? If not, then should BIGGEST_ALIGNMENT be equal to
the largest supported mode on our machine? I am quite confused about
what fault it could happen in BIGGEST_ALIGNMENT is violated,
therefore for our machine I guess BIGGEST_ALIGNMENT can be as high as
possible.
Paulo Matos
I don't know what sort of fault could be generated by larger
alignments, but the gcc manual gives a suggested usage of
__BIGGEST_ALIGNMENT__ in user code:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
(Note - I am not sure whether BIGGEST_ALIGNMENT and
__BIGGEST_ALIGNMENT__ are in bits or bytes.)
The idea, I think, is that it should be the smallest size that makes
things like optimised memory copies as fast as possible. Typically it
should match cache line sizes on the target. Making it bigger than that
will mean that anyone following the advice in the manual would be
wasting space.
I can't see that BIGGEST_ALIGNMENT should ever be set to something
smaller than the alignment needed for the biggest types (double,
int64_t, or perhaps int128_t types).
For some uses, it's important to be able to allocate data with much
bigger alignments - in embedded systems I have had occasion to declare
data with very large alignments.
mvh.,
David
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/13 07:27, Jan-Benedict Glaw wrote: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? Probably not (without having looked at what that configuration would actually pull in.) I believe that microblaze-rtems is almost identical to microblaze-elf. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [buildrobot] pdp11-aout
On 26 November 2013 15:55, Paul Koning paulkon...@comcast.net wrote: Is there a requirement that all targets must have branch cost that it, at least some of the time, 4 or greater? Not by design, although there seem to be a number of issues with supporting targets with a lower branch cost. E.g. consider LOGICAL_OP_NON_SHORT_CIRCUIT - the default of which also seems to assume superscalarity and a cheap flag-set operation - and its impact on/treatment by the test suite. If so, why? If not, then I suppose cfgexpand.c could be changed to defeat this message I agree. , but how, or why? Changing this target macro into a target hook should do the trick.
Re: [buildrobot] pdp11-aout
P.S.: This is PR54664. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 2013-11-26 07:50:34 -0800, Michael Eager ea...@eagercon.com wrote: On 11/25/13 19:26, Jan-Benedict Glaw wrote: Build logs at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718 (I also think that we'd have the little endian version on the target list at contrib/config-list.mk ...) [...] I do not see this error in my build of microblaze-elf. I notice that there are flags in your compile that do not appear in mine: -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror See the introduction email: This is (as advised) with an up-to-date GCC (just a few days old), using --enable-werror-always at configure time (as done by .../contrib/config-list.mk). Thanks for looking into the issue anyways! (...and what do you think about adding a microblazeel target to the list?) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:http://catb.org/~esr/faqs/smart-questions.html the second : signature.asc Description: Digital signature
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 2013-11-26 08:13:12 -0800, Michael Eager ea...@eagercon.com wrote: On 11/26/13 08:08, Jan-Benedict Glaw wrote: Thanks for looking into the issue anyways! (...and what do you think about adding a microblazeel target to the list?) Sounds OK to me. Any suggestion of which target(s) to choose? MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:Lauf nicht vor Deinem Glück davon: the second : Es könnte hinter Dir stehen! signature.asc Description: Digital signature
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/13 08:08, Jan-Benedict Glaw wrote: On Tue, 2013-11-26 07:50:34 -0800, Michael Eager ea...@eagercon.com wrote: On 11/25/13 19:26, Jan-Benedict Glaw wrote: Build logs at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718 (I also think that we'd have the little endian version on the target list at contrib/config-list.mk ...) [...] I do not see this error in my build of microblaze-elf. I notice that there are flags in your compile that do not appear in mine: -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror See the introduction email: This is (as advised) with an up-to-date GCC (just a few days old), using --enable-werror-always at configure time (as done by .../contrib/config-list.mk). Missed that email. Thanks for looking into the issue anyways! (...and what do you think about adding a microblazeel target to the list?) Sounds OK to me. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [buildrobot] pdp11-aout
On 11/26/13 08:55, Paul Koning wrote: On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Hi! Build log at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40865 g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o cfgexpand.o -MT cfgexpand.o -MMD -MP -MF ./.deps/cfgexpand.TPo ../../../gcc/gcc/cfgexpand.c ../../../gcc/gcc/cfgexpand.c: In function ‘basic_block_def* expand_gimple_cond(basic_block, gimple)’: ../../../gcc/gcc/cfgexpand.c:2027:65: error: comparison is always true due to limited range of data type [-Werror=type-limits] else if (BRANCH_COST (optimize_insn_for_speed_p (), false) 4) ^ cc1plus: all warnings being treated as errors make[2]: *** [cfgexpand.o] Error 1 Interesting. In the pdp11 target, BRANCH_COST is either 0 or 1. So yes, that comparison is always true. Is there a requirement that all targets must have branch cost that it, at least some of the time, 4 or greater? If so, why? If not, then I suppose cfgexpand.c could be changed to defeat this message, but how, or why? In general, it seems perfectly reasonable to have code guarded by conditions that may be always true, or always false. That's what we have optimizers for. Defeating such optimizations by calling them an error seems like a bad idea. No, there's no such requirement on the targets to have a branch cost 4. Jeff
Re: [buildrobot] pdp11-aout
On Nov 26, 2013, at 11:03 AM, Joern Rennecke joern.renne...@embecosm.com wrote: On 26 November 2013 15:55, Paul Koning paulkon...@comcast.net wrote: Is there a requirement that all targets must have branch cost that it, at least some of the time, 4 or greater? Not by design, although there seem to be a number of issues with supporting targets with a lower branch cost. E.g. consider LOGICAL_OP_NON_SHORT_CIRCUIT - the default of which also seems to assume superscalarity and a cheap flag-set operation - and its impact on/treatment by the test suite. The doc says that the default branch cost is 1. So it seems reasonable for a target to have branch cost 4 at all times, if the target doesn't have expensive branches or widely varying branch costs. Low speed processors with simple execution units are likely to be such targets (and indeed the pdp11 is a good example). If so, why? If not, then I suppose cfgexpand.c could be changed to defeat this message I agree. , but how, or why? Changing this target macro into a target hook should do the trick. Is there such a target hook in the current code? paul
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 26 Nov 2013, Jan-Benedict Glaw wrote: The idea if config-list.mk is not to build every conceivable target configuration, but to give a reasonable converage of the different target architectures and OS/library configurations so that you can effectively test a patch with unknown target-specific impact. Is it like that? My impression is/was that people collected a list of targets they somewhat care for. With around 200 configurations, among them some that are quite similar, adding another just adds 1/2%, which I'd call neglectible. For example, the list should include at least one target for every target header in GCC. So if there's a header specific to an (architecture, OS) pair, a matching configuration should be included. -- Joseph S. Myers jos...@codesourcery.com
Re: [buildrobot] First results of running contrib/config-list.mk
Many such failures may already have bugs in Bugzilla (generally filed by Joern). I think it's time to remove targets that have been under --enable-obsolete for a while - and to obsolete, for possible future removal, targets without stdint.h type information configured in GCC (see list in http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00248.html) (the avr-rtems failures seem to be an issue with missing or broken stdint.h configuration, though I'm not sure why it would be missing there). -- Joseph S. Myers jos...@codesourcery.com
Re: Using BIGGEST_ALIGNMENT to remove alignment constraints
On Tue, Nov 26, 2013 at 7:12 AM, Paulo Matos pma...@broadcom.com wrote:
I am slightly confused about the BIGGEST_ALIGNMENT docs which state:
Biggest alignment that any data type can require on this machine, in bits.
Note that this is not the biggest alignment that is supported, just the
biggest alignment that, when violated, may cause a fault.
What kind of fault would this be?
An instruction that fails to execute correctly because the memory
address is misaligned. For example, on many RISC chips, a memory load
of a 16-bit or larger value from an odd address will fail. For
example, on x86, an aligned load of an SSE register from an address
not aligned to an 16-byte boundary will fail (the x86 does have
different unaligned load instructions for SSE registers).
We currently have it set to 64, word_size. However, we really have no
alignment restrictions being able to align data types to byte boundaries if
necessary. Therefore, from this piece of code:
unsigned int
get_mode_alignment (enum machine_mode mode)
{
return MIN (BIGGEST_ALIGNMENT, MAX (1,
mode_base_align[mode]*BITS_PER_UNIT));
}
I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just align
the data at any byte boundary. Would this be a fair use of BIGGEST_ALIGNMENT?
If not, then should BIGGEST_ALIGNMENT be equal to the largest supported mode
on our machine? I am quite confused about what fault it could happen in
BIGGEST_ALIGNMENT is violated, therefore for our machine I guess
BIGGEST_ALIGNMENT can be as high as possible.
If your processor can execute a memory load instruction from any
address, and if memory is addressed in 8-bit bytes, then
BIGGEST_ALIGNMENT should be set to 8.
Ian
Re: Using BIGGEST_ALIGNMENT to remove alignment constraints
I am slightly confused about the BIGGEST_ALIGNMENT docs which state: Biggest alignment that any data type can require on this machine, in bits. Note that this is not the biggest alignment that is supported, just the biggest alignment that, when violated, may cause a fault. What kind of fault would this be? Unaligned memory access fault. I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just align the data at any byte boundary. Would this be a fair use of BIGGEST_ALIGNMENT? Yes, you may set BIGGEST_ALIGNMENT to 8 if unaligned memory accesses can never generate a fault on the architecture. But, in practice, you might want to take into account performance considerations. -- Eric Botcazou
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/13 08:16, Jan-Benedict Glaw wrote: On Tue, 2013-11-26 08:13:12 -0800, Michael Eager ea...@eagercon.com wrote: On 11/26/13 08:08, Jan-Benedict Glaw wrote: Thanks for looking into the issue anyways! (...and what do you think about adding a microblazeel target to the list?) Sounds OK to me. Any suggestion of which target(s) to choose? microblazeel-elf. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [RFC] Detect most integer overflows.
On Nov 9, 2013, at 02:48, Ondřej Bílka nel...@seznam.cz wrote: I've done the overflow checking in Gigi (Ada front end). Benchmarking real world large Ada programs (where every integer operation is checked, including array index computations etc.), I found the performance cost *very* small (less than 1% on typical code, never more than 2%). There is a bit more cost in code size, but that is mostly due to the fact that we want to generate error messages with correct line number information without relying on backtraces. Overhead is mostly from additonal branches that are not taken. We need more accurate measure of cache effects than code size, for example looking to increased number icache hits which will not count code that is never executed. Indeed, and execution time testing shows there isn't a significant increase in icache pressure. [...] A few things helped to make the cost small: the biggest one is that typically on of the operands is known to be negative or positive. Gigi will use Ada type information, and Natural or Positive integer variables are very common. So, if you compute X + C with C positive, you can write the conditional expression as: On x64 efect of this analysis is small, processor does overflow detection for you. The problem as always is that of pass ordering. If we would encapsulate the overflow check some kind of builtin that we'd directly very late in the compilation process to processor-specific instructions, then early optimizers cannot do their work. By just expanding out to regular additions, comparisons and control flow we can avoid this problem. (if X Integer'Last - C then X + C else raise Constraint_Error) On my x86-64 this generates something like: 00 cmpl$0x7fff,%de 06 je 0x000c 08 leal0x01(%rdi),%eax 0b ret [..] This has redundant compare instruction that cost a cycle and 6 bytes. You can just write 0: 83 c7 01add$0x1,%edi 3: 71 03 jno0x8 [...] When you know that one operand is positive or you deal with unsigned then you could replace jno with jnc which is bit faster on sandy bridge processors and later as add, jnc pair is macro-fused but add jno is not. Indeed that is ideal, assuming condition flags are dead, but I think that the right way to do that is by late combine-like optimizations after instruction selection. In looking at generated code in actual programs, most checks are optimized away. This is more important than saving a cycle here or there in the much smaller number of checks that remain. After all, we all know that our programs will never fail any overflow checks, so it is just a matter of the compiler to be smart enough to prove this. While it won't achieve that goal (halting problem etc), for a large fraction localized analysis is sufficient to prove checks cannot fail. I'm afraid that premature optimization will always be a loss here. Probably combine, in combination with some machine-specific instruction patterns, could be taught to do some of the optimizations you mention, and that would have as advantage that they'd be also applicable to manual tests people write. -Geert
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/2013 10:52 AM, Joseph S. Myers wrote: On Tue, 26 Nov 2013, Jan-Benedict Glaw wrote: The idea if config-list.mk is not to build every conceivable target configuration, but to give a reasonable converage of the different target architectures and OS/library configurations so that you can effectively test a patch with unknown target-specific impact. Is it like that? My impression is/was that people collected a list of targets they somewhat care for. With around 200 configurations, among them some that are quite similar, adding another just adds 1/2%, which I'd call neglectible. For example, the list should include at least one target for every target header in GCC. So if there's a header specific to an (architecture, OS) pair, a matching configuration should be included. It is true that the RTEMS configurations are generally similar to the *-elf ones. However, we turn on pthreads support in C++ and multitasking in the languages which have it including Ada. We have good test results even in FORTRAN. With tasking and filesystem support on near bare metal, *-rtems can potentially be used to test a lot more than *-elf. For the basic code generation, there likely isn't much difference. I often can reproduce our code generation problems using *-elf. But we have different code and more code. The key to seeing the value of testing *-rtems is moving beyond builds or not and into running tests on more languages. as to Joern's question: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. Plus we do have at least one OS/Target specific file for each *-rtems configuration. There is at least a config/*/*rtems*.h and often a config/*/t-* which is specific to RTEMS. Plus config/*rtems* is used in all *-rtems targets. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/2013 06:38 PM, Joel Sherrill wrote: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. Correct. microblaze-rtems* is incomplete in libgcc. I have a patch pending for gcc-4.8.x, but haven't yet tried with gcc-4.9.x. Ralf
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/2013 11:58 AM, Ralf Corsepius wrote: On 11/26/2013 06:38 PM, Joel Sherrill wrote: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. Correct. microblaze-rtems* is incomplete in libgcc. I have a patch pending for gcc-4.8.x, but haven't yet tried with gcc-4.9.x. It should be the same patch. I wrote one too and obviously forgot to upstream it. For those who care, this is the seemingly benign patch which broke it. http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=98f2ac05e3adaf283a55531a3e274e20aad6048d The lesson is that every target has to take a path through those large switches. And things can and do break. Ralf -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Your research papers are recommended to Docear's users
Hello, we are the developers of Docear, which is a software to manage academic literature, PDFs, and references. Among other features, the software provides an automated recommender system for research articles that are freely available online. Docear's Web Crawler discovered 3 of your papers online and Docear wishes to recommend these papers to users with related research interests. The papers Docear found are - Generic and gimple: A new tree representation for entire functions - GCC internals - Embedded Software Development with eCos We hope that recommending these papers to our users is in your interest. If you would nonetheless like to exclude your papers from being recommended, or if you are not the author of the papers, please visit https://www.docear.org/my-docear/my-documents/?email=gcc@gcc.gnu.orgtoken=629f40b8-4d1e-11e3-8844-8c89a52b0951, where you can change the indexing settings. If you have questions about Docear's recommender system, please do not hesitate to contact us (www.docear.org/docear/contact/). Please do not reply to this message. Please also feel free to have a look at Docear http://www.docear.org. Its concept for managing references, organizing PDFs and drafting academic literature is truly unique. With kind regards, The Docear Team Joeran Beel, Stefan Langer, and Marcel Genzmehr -- Web: http://docear.org Blog: http://www.docear.org/docear/blog/ Twitter: https://twitter.com/Docear_org Facebook: https://www.facebook.com/pages/Docear/137985949605902 Google+: https://plus.google.com/106965732112113749959/posts
Fixed! (was: [buildrobot] epiphany-elf)
Hi! On Tue, 2013-11-26 04:27:56 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build log at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40206 I think Joern is rewarded with the First Fixer's Trophy :) http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=41484 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 23:53 @jbglaw So, ich kletter' jetzt mal ins Bett. the second : 23:57 @jever2 .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?) 00:00 @jbglaw jever2: *patsch* 00:01 @jever2 *aua*, wofür, Gedanken sind frei! 00:02 @jbglaw Nee, freie Gedanken, die sind seit 1984 doch aus! 00:03 @jever2 1984? ich bin erst seit 1985 verheiratet! signature.asc Description: Digital signature
Re: [buildrobot] microblaze-elf / microblaze-linux
On 26 November 2013 17:38, Joel Sherrill joel.sherr...@oarcorp.com wrote: The key to seeing the value of testing *-rtems is moving beyond builds or not and into running tests on more languages. Well, we are already configuring with --enable-languages=all,ada,go , so there are a lot of frontends being build - just not the libraries. as to Joern's question: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. In order to catch such a problem, we'd have to at least build libgcc. Which requires to have an assembler for the respective target first. How should this be handled? Test if an cross-asembler for target has been installedon the host? Or having a separate list of targets that are supported by FSF GAS, and a curent gas checkout, and then building gas for those targets?
Re: [buildrobot] microblaze-elf / microblaze-linux
On Tue, 2013-11-26 19:50:10 +, Joern Rennecke joern.renne...@embecosm.com wrote: On 26 November 2013 17:38, Joel Sherrill joel.sherr...@oarcorp.com wrote: as to Joern's question: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. In order to catch such a problem, we'd have to at least build libgcc. Which requires to have an assembler for the respective target first. How should this be handled? Test if an cross-asembler for target has been installedon the host? Or having a separate list of targets that are supported by FSF GAS, and a curent gas checkout, and then building gas for those targets? I think it'd possible to eg. first create a linked tree and then build all-gas all-ld install-gas install-ld all-gcc . I think that most targets should be gas-/ld-supported. At least, we'd give that a try and see where it takes us. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, träume ich. the second : signature.asc Description: Digital signature
[RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
The jump threading changes have exposed a latent bug on machines with
conditional execution such as the ARM.
Going into the last conditional execution pass we have:
[ ... ]
(insn 16 60 17 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(jump_insn 17 16 19 2 (set (pc)
(if_then_else (ne (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 25)
(pc))) j.c:14 235 {arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 5000 (nil)))
- 25)
;; succ: 4 [50.0%]
;; 3 [50.0%] (FALLTHRU)
; basic block 3, loop depth 0, count 0, freq 7500, maybe hot
;; Invalid sum of incoming frequencies 5000, should be 7500
;; prev block 2, next block 4, flags: (RTL)
;; pred: 2 [50.0%] (FALLTHRU)
(note 19 17 18 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note/s 18 19 20 3 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ:
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 25)
;; basic block 4, loop depth 0, count 0, freq 0
;; Invalid sum of incoming frequencies 5000, should be 0
;; prev block 3, next block 5, flags: (RTL)
;; pred: 2 [50.0%]
(code_label 25 21 26 4 2 [1 uses])
(note 26 25 27 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
;; succ: 5 [100.0%] (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 2500
;; prev block 4, next block 1, flags: (RTL)
;; pred: 4 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 26 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note carefully BB3 which is the result of a __builtin_unreachable in the
original source. It has no code, no successors and a trailing barrier
(all as expected).
ce3 comes along and creates this mess:
[ ... ]
(insn 16 60 18 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(note/s 18 16 20 2 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ: 5 [100.0%] (FALLTHRU)
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 27)
;; basic block 5, loop depth 0, count 0, freq 2500
;; Invalid sum of incoming frequencies 12500, should be 2500
;; prev block 2, next block 1, flags: (RTL)
;; pred: 2 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 21 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note how it's removed the conditional jump at the end of bb2. BB2 still
has an outgoing edge, to BB5, but there's a barrier after BB2.
This, of course, trips a checking failure.
ISTM that when we merge blocks due to if-conversion of this code of
code, we're always going to have an outgoing edge from the merged block
(sanity check, right?)
Something along these lines I think. However, I'm not at all familiar
with this code, so some sanity checking would be greatly appreciated.
Thoughts?
Jeff
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index ac0276c..f7f6243 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -3154,6 +3154,17 @@ merge_if_block (struct ce_if_block * ce_info)
{
merge_blocks (combo_bb, then_bb);
num_true_changes++;
+
+ /* THEN_BB might have been created by a __builtin_unreachable and
+thus have no outgoing edges and a barrier. We need to remove
+the barrier. */
+ rtx end = BB_END (then_bb);
+
+ while (end NOTE_P (end))
+ end = NEXT_INSN (end);
+
+ if (GET_CODE (end) == BARRIER)
+ delete_insn (end);
}
/* The ELSE block, if it existed, had a label. That label count
@@ -3163,6 +3174,17 @@ merge_if_block (struct ce_if_block * ce_info)
{
merge_blocks (combo_bb, else_bb);
num_true_changes++;
+
+ /* ELSE_BB might have been created by a __builtin_unreachable and
+thus have no outgoing edges and a barrier. We need to remove
+the barrier. */
+ rtx end = BB_END (else_bb);
+
+ while (end NOTE_P (end))
+ end = NEXT_INSN (end);
+
+ if (GET_CODE (end) == BARRIER)
+ delete_insn (end);
}
/* If there was no join block reported, that means it was not adjacent
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On Tue, Nov 26, 2013 at 8:20 PM, Jeff Law wrote:
The jump threading changes have exposed a latent bug on machines with
conditional execution such as the ARM.
Going into the last conditional execution pass we have:
[ ... ]
(insn 16 60 17 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(jump_insn 17 16 19 2 (set (pc)
(if_then_else (ne (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 25)
(pc))) j.c:14 235 {arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 5000 (nil)))
- 25)
;; succ: 4 [50.0%]
;; 3 [50.0%] (FALLTHRU)
; basic block 3, loop depth 0, count 0, freq 7500, maybe hot
;; Invalid sum of incoming frequencies 5000, should be 7500
;; prev block 2, next block 4, flags: (RTL)
;; pred: 2 [50.0%] (FALLTHRU)
(note 19 17 18 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note/s 18 19 20 3 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ:
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 25)
;; basic block 4, loop depth 0, count 0, freq 0
;; Invalid sum of incoming frequencies 5000, should be 0
;; prev block 3, next block 5, flags: (RTL)
;; pred: 2 [50.0%]
(code_label 25 21 26 4 2 [1 uses])
(note 26 25 27 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
;; succ: 5 [100.0%] (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 2500
;; prev block 4, next block 1, flags: (RTL)
;; pred: 4 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 26 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note carefully BB3 which is the result of a __builtin_unreachable in the
original source. It has no code, no successors and a trailing barrier (all
as expected).
ce3 comes along and creates this mess:
[ ... ]
(insn 16 60 18 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(note/s 18 16 20 2 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ: 5 [100.0%] (FALLTHRU)
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 27)
;; basic block 5, loop depth 0, count 0, freq 2500
;; Invalid sum of incoming frequencies 12500, should be 2500
;; prev block 2, next block 1, flags: (RTL)
;; pred: 2 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 21 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note how it's removed the conditional jump at the end of bb2. BB2 still has
an outgoing edge, to BB5, but there's a barrier after BB2.
This, of course, trips a checking failure.
I've been running into more of these.
rant
BARRIERs should not exist as long as we have a CFG. The CFG has all
the information.
/rant
This is one of my goals for the next stage1.
ISTM that when we merge blocks due to if-conversion of this code of code,
we're always going to have an outgoing edge from the merged block (sanity
check, right?)
Something along these lines I think. However, I'm not at all familiar with
this code, so some sanity checking would be greatly appreciated.
I'm surprised if-conversion applies here at all. You basically have an
incomplete diamond and that's only partially handled by ifcvt.
There is this comment:
/* If the THEN block has no successors, conditional execution can still
make a conditional call. Don't do this unless the ELSE block has
only one incoming edge -- the CFG manipulation is too ugly otherwise.
Check for the last insn of the THEN block being an indirect jump, which
is listed as not having any successors, but confuses the rest of the CE
code processing. ??? we should fix this in the future. */
and it is assumed that there is a noreturn call in the block without
successors. In other words, the THEN block is really a dead end in the
CFG and it cannot be merged away unless the noreturn call is
if-converted away. In the case of builtin_unreachable, obviously there
isn't a call, but I'm guessing your test case goes through this path
anyway.
I believe the proper fix would be to not recognize this as an
if-conversion block candidate in cond_exec_find_if_block.
Ciao!
Steven
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On 11/26/13 13:30, Steven Bosscher wrote:
On Tue, Nov 26, 2013 at 8:20 PM, Jeff Law wrote:
The jump threading changes have exposed a latent bug on machines with
conditional execution such as the ARM.
Going into the last conditional execution pass we have:
[ ... ]
(insn 16 60 17 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(jump_insn 17 16 19 2 (set (pc)
(if_then_else (ne (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 25)
(pc))) j.c:14 235 {arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 5000 (nil)))
- 25)
;; succ: 4 [50.0%]
;; 3 [50.0%] (FALLTHRU)
; basic block 3, loop depth 0, count 0, freq 7500, maybe hot
;; Invalid sum of incoming frequencies 5000, should be 7500
;; prev block 2, next block 4, flags: (RTL)
;; pred: 2 [50.0%] (FALLTHRU)
(note 19 17 18 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note/s 18 19 20 3 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ:
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 25)
;; basic block 4, loop depth 0, count 0, freq 0
;; Invalid sum of incoming frequencies 5000, should be 0
;; prev block 3, next block 5, flags: (RTL)
;; pred: 2 [50.0%]
(code_label 25 21 26 4 2 [1 uses])
(note 26 25 27 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
;; succ: 5 [100.0%] (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 2500
;; prev block 4, next block 1, flags: (RTL)
;; pred: 4 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 26 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note carefully BB3 which is the result of a __builtin_unreachable in the
original source. It has no code, no successors and a trailing barrier (all
as expected).
ce3 comes along and creates this mess:
[ ... ]
(insn 16 60 18 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [121])
(nil)))
(note/s 18 16 20 2 (lab2) NOTE_INSN_DELETED_LABEL 3)
;; succ: 5 [100.0%] (FALLTHRU)
(note/s 20 18 21 (lab) NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 27)
;; basic block 5, loop depth 0, count 0, freq 2500
;; Invalid sum of incoming frequencies 12500, should be 2500
;; prev block 2, next block 1, flags: (RTL)
;; pred: 2 [100.0%] (FALLTHRU)
;; 5 [100.0%] (DFS_BACK)
(code_label 27 21 28 5 5 [1 uses])
(note 28 27 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 28 57 5 (set (pc)
(label_ref 27)) 249 {*arm_jump}
(nil)
- 27)
;; succ: 5 [100.0%] (DFS_BACK)
(barrier 57 56 58)
(note 58 57 0 NOTE_INSN_DELETED)
Note how it's removed the conditional jump at the end of bb2. BB2 still has
an outgoing edge, to BB5, but there's a barrier after BB2.
This, of course, trips a checking failure.
I've been running into more of these.
rant
BARRIERs should not exist as long as we have a CFG. The CFG has all
the information.
/rant
This is one of my goals for the next stage1.
Excellent. BARRIERS are from a era before we had a CFG. I will lose no
sleep when they're gone.
ISTM that when we merge blocks due to if-conversion of this code of code,
we're always going to have an outgoing edge from the merged block (sanity
check, right?)
Something along these lines I think. However, I'm not at all familiar with
this code, so some sanity checking would be greatly appreciated.
I'm surprised if-conversion applies here at all. You basically have an
incomplete diamond and that's only partially handled by ifcvt.
Yea. I was surprised too, but then realized if-converting a block with
no-successors is still useful.
I have a hack here (bootstrapped and tested even) which filters out this
case and just leaves things alone. But after pondering it overnight I
felt that code was just papering over the real problem.
There's nothing that says that an if-converted block has to have
successors. For example, it might be an if-converted block that ends in
a call to abort, which gets turned into a conditional call to abort.
There is this comment:
/* If the THEN block has no successors, conditional execution can still
make a conditional call. Don't do this unless the ELSE block has
only one incoming edge -- the CFG manipulation is too ugly otherwise.
Check for the last insn of the THEN block being an indirect jump, which
is listed as not having any successors, but confuses the rest of the CE
code processing. ??? we should fix this in the future. */
and it is assumed that there is a noreturn call in the
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On Tue, Nov 26, 2013 at 10:03 PM, Jeff Law wrote: I believe the proper fix would be to not recognize this as an if-conversion block candidate in cond_exec_find_if_block. That's easy enough to do, but leaves a fair amount of useless cruft in the IL and ultimately the resulting code. If instead we recognize this case and remove the BARRIER appropriately, all the cruft just disappears. I suppose with cruft you mean the dead end in the CFG due to builtin_unreachable, correct? If so, then I suppose you could also just let cfgcleanup handle that cruft and not wait until if-conversion. It still puzzles me what exactly the semantics __builtin_unreachable are, but AFAIU, a basic block ending in __builtin_unreachable could go anywhere (undefined behavior). So why do we emit a BARRIER after then to begin with? Or why not even drop __builtin_unreachable completely during expand? (It's caused me quite a lot of pain already: __builtin_unreachable in the middle of a basic block confuses find_many_sub_basic_blocks, there's a PR somewhere with my name on it...). Hacking BARRIERs by hand in a function that's supposed to know about the CFG just seems wrong :-( Ciao! Steven
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On 11/26/13 14:41, Steven Bosscher wrote: I suppose with cruft you mean the dead end in the CFG due to builtin_unreachable, correct? Yes. If so, then I suppose you could also just let cfgcleanup handle that cruft and not wait until if-conversion. But what does all this look like at the RTL level. A block resulting from __builtin_unreachable is just a block with no successors. So while we could clean it up in this case, I don't think we can in general. ie, we might ahve: [ ... ] fubar (); __builtin_unreachable (); Where the programmer is effectively asserting that fubar never returns. So we have a block which calls fubar. The block would have no successors. And I think we're right back in the same situation. We're going to have a BARRIER after that block with no successors and ifcvt is going to muck things up tripping the checking failure. Furthermore, ISTM, that while __builtin_unreachable is part of this instance of the problem, ultimately the core issue is that the ifcvt code doesn't properly handle cases where the converted blocks have no successors. It still puzzles me what exactly the semantics __builtin_unreachable are, but AFAIU, a basic block ending in __builtin_unreachable could go anywhere (undefined behavior). So why do we emit a BARRIER after then to begin with? Or why not even drop __builtin_unreachable completely during expand? (It's caused me quite a lot of pain already: __builtin_unreachable in the middle of a basic block confuses find_many_sub_basic_blocks, there's a PR somewhere with my name on it...). I believe __builtin_unreachable is fundamentally broken, but I'm not really up for arguing with Jakub about it right now :( Your understanding is basically correct. The barrier exists because __builtin_unreachable, when we convert to RTL is emit_barrier(). Nothing more, nothing less. You can't directly see a __builtin_unreachable at the RTL level. Arguably it could be dropped, as we expand, but then you drop useful information from the CFG. Namely that certain blocks of code never rejoin the main control flow. ie, once you're on that path, you're going to hang, abort/exit and the like. Thus you don't need edges from those paths back to the main stream. Hacking BARRIERs by hand in a function that's supposed to know about the CFG just seems wrong :-( Open to other suggestions. The fundamental issue is BARRIERs live outside the CFG. So a pass that thinks it can manipulate the CFG and ignore the underlying RTL are going to have problems with things like this. Jeff
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On Tue, Nov 26, 2013 at 11:05 PM, Jeff Law wrote: On 11/26/13 14:41, Steven Bosscher wrote: I suppose with cruft you mean the dead end in the CFG due to builtin_unreachable, correct? Yes. If so, then I suppose you could also just let cfgcleanup handle that cruft and not wait until if-conversion. But what does all this look like at the RTL level. A block resulting from __builtin_unreachable is just a block with no successors. So while we could clean it up in this case, I don't think we can in general. ie, we might ahve: [ ... ] fubar (); __builtin_unreachable (); Where the programmer is effectively asserting that fubar never returns. Right. I saw that one in the documentation and my first reaction was ECF_NORETURN. But that flag applies to functions, not call statements. So we have a block which calls fubar. The block would have no successors. And I think we're right back in the same situation. We're going to have a BARRIER after that block with no successors and ifcvt is going to muck things up tripping the checking failure. In RTL-land the NORETURN flag is already a statement thing via REG_NORETURN. But I'm not sure if such a note is added for calls followed originally by a builtin_unreachable. I'm guessing not. Furthermore, ISTM, that while __builtin_unreachable is part of this instance of the problem, ultimately the core issue is that the ifcvt code doesn't properly handle cases where the converted blocks have no successors. True. It only handles cases where it can see why there are no successors. I'm pretty sure most of the time that bit of information is encoded somehow (trap, REG_NORETURN, etc.). As far as I'm aware, __builtin_unreachable is the only exception. Arguably it could be dropped, as we expand, but then you drop useful information from the CFG. Namely that certain blocks of code never rejoin the main control flow. ie, once you're on that path, you're going to hang, abort/exit and the like. Thus you don't need edges from those paths back to the main stream. And yet, that's what merge_if_blocks will do if you remove the BARRIER. You're basically closing the diamond so that the conditional jump can be optimized away. That's a good thing, of course. But it seems arbitrary to do it in ifcvt.c and only for cond_exec targets. Does the condjump survive to assembler output on e.g. x86_64? Hacking BARRIERs by hand in a function that's supposed to know about the CFG just seems wrong :-( Open to other suggestions. Can't claim to have any, at least not for short-term solutions. Ciao! Steven
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On 11/26/13 15:44, Steven Bosscher wrote: So we have a block which calls fubar. The block would have no successors. And I think we're right back in the same situation. We're going to have a BARRIER after that block with no successors and ifcvt is going to muck things up tripping the checking failure. In RTL-land the NORETURN flag is already a statement thing via REG_NORETURN. But I'm not sure if such a note is added for calls followed originally by a builtin_unreachable. I'm guessing not. I'm not aware of any code to do that. Also note that we could get the same behaviour from a *magicaddr = magicnum if we were talking to a special piece of hardware. Though perhaps we wouldn't if-convert the volatile memory reference. And yet, that's what merge_if_blocks will do if you remove the BARRIER. You're basically closing the diamond so that the conditional jump can be optimized away. That's a good thing, of course. Exactly why I ultimately came up with the hack I posted rather than the hack to cond_exec_find_if_block which was my original fix. But it seems arbitrary to do it in ifcvt.c and only for cond_exec targets. Does the condjump survive to assembler output on e.g. x86_64? Yup. It lives all the way to assembler output. Jeff
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On 26 November 2013 22:05, Jeff Law l...@redhat.com wrote: Open to other suggestions. The fundamental issue is BARRIERs live outside the CFG. So a pass that thinks it can manipulate the CFG and ignore the underlying RTL are going to have problems with things like this. Here, the barrier itself acts like a JUMP_INSN with a special target - a bit like return, except that our special destination here is 'unreachable'. If you want to express this in the cfg other than having no successors, you should have a special UNREACHABLE block, which thus becomes competition for the exit block.
Re: [buildrobot] ia64-hpux
On Tue, 2013-11-26 04:26:57 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build log at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39052 g++ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o ia64.o -MT ia64.o -MMD -MP -MF ./.deps/ia64.TPo ../../../gcc/gcc/config/ia64/ia64.c In file included from ./tm.h:20:0, from ../../../gcc/gcc/config/ia64/ia64.c:25: ../../../gcc/gcc/config/ia64/hpux.h:185:34: error: ‘default_c99_libc_has_function’ was not declared in this scope #define TARGET_LIBC_HAS_FUNCTION default_c99_libc_has_function ^ ./target-hooks-def.h:1140:5: note: in expansion of macro ‘TARGET_LIBC_HAS_FUNCTION’ TARGET_LIBC_HAS_FUNCTION, \ ^ ../../../gcc/gcc/config/ia64/ia64.c:659:29: note: in expansion of macro ‘TARGET_INITIALIZER’ struct gcc_target targetm = TARGET_INITIALIZER; ^ make[2]: *** [ia64.o] Error 1 I *guess* it should have been no_c99_libc_has_function instead of default_c99_libc_has_function, referring to an equal change to pa/hpux.h in r201838: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201838 http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=30f690e026ecdf99c68e777a48562b58afe37f43 But I don't actually know HP-UX's libc and whether or not it ships an equal set of functions on all target it runs on... MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Alles sollte so einfach wie möglich gemacht sein. the second : Aber nicht einfacher. (Einstein) signature.asc Description: Digital signature
Re: [buildrobot] ia64-hpux
On 11/26/13 19:50, Jan-Benedict Glaw wrote: On Tue, 2013-11-26 04:26:57 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: Build log at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39052 g++ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o ia64.o -MT ia64.o -MMD -MP -MF ./.deps/ia64.TPo ../../../gcc/gcc/config/ia64/ia64.c In file included from ./tm.h:20:0, from ../../../gcc/gcc/config/ia64/ia64.c:25: ../../../gcc/gcc/config/ia64/hpux.h:185:34: error: ‘default_c99_libc_has_function’ was not declared in this scope #define TARGET_LIBC_HAS_FUNCTION default_c99_libc_has_function ^ ./target-hooks-def.h:1140:5: note: in expansion of macro ‘TARGET_LIBC_HAS_FUNCTION’ TARGET_LIBC_HAS_FUNCTION, \ ^ ../../../gcc/gcc/config/ia64/ia64.c:659:29: note: in expansion of macro ‘TARGET_INITIALIZER’ struct gcc_target targetm = TARGET_INITIALIZER; ^ make[2]: *** [ia64.o] Error 1 I *guess* it should have been no_c99_libc_has_function instead of default_c99_libc_has_function, referring to an equal change to pa/hpux.h in r201838: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201838 http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=30f690e026ecdf99c68e777a48562b58afe37f43 But I don't actually know HP-UX's libc and whether or not it ships an equal set of functions on all target it runs on... I approved a patch today that I think will fix this. Jeff
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On 11/26/13 15:44, Steven Bosscher wrote: Open to other suggestions. Can't claim to have any, at least not for short-term solutions. How about rtl_merge_blocks getting smarter about removing BARRIERS between the blocks-to-be-merged? Something like this (untested, except for verifying it avoids the problem in the testcase on arm)? diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c index 63f44af..8f3763c 100644 --- a/gcc/cfgrtl.c +++ b/gcc/cfgrtl.c @@ -878,8 +878,15 @@ rtl_merge_blocks (basic_block a, basic_block b) a_end = PREV_INSN (del_first); } - else if (BARRIER_P (NEXT_INSN (a_end))) -del_first = NEXT_INSN (a_end); + + /* If there is a BARRIER between A B, remove it, this can happen if + we if-convert a block with no successors. */ + rtx end = NEXT_INSN (a_end); + while (end NOTE_P (end)) +end = NEXT_INSN (end); + + if (BARRIER_P (end)) +del_first = end; /* Delete everything marked above as well as crap that might be hanging out between the two blocks. */ Thoughts? jeff
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
On Wed, Nov 27, 2013 at 6:47 AM, Jeff Law wrote: How about rtl_merge_blocks getting smarter about removing BARRIERS between the blocks-to-be-merged? It'd be breaking away further from the rule that merge_blocks should only work if can_merge_blocks. (But that isn't enforced in cfgrtl mode right now anyway.) I suppose we'll have to look for a better solution in the next stage1. Ciao! Steven
[Bug middle-end/59273] [4.9 Regression] ICE in expand_expr_real_2, at expr.c:9188 on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59273 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31293 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31293action=edit gcc49-pr59273.patch Untested fix.
[Bug c++/59297] [4.7/4.8/4.9 Regression] ICE: openmp atomic with indirect LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59297
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Breakpoint 5, verify_gimple_stmt (stmt=gimple_with_cleanup_expr
0x719b9990)
at /home/marek/src/gcc/gcc/tree-cfg.c:4296
4296{
(gdb) call debug_gimple_stmt(stmt)
Unknown GIMPLE statement: gimple_with_cleanup_expr
[Bug c++/58950] [4.9 Regression] Missing statement has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- For __builtin_shuffle, the issue is that we now call save_expr, which always sets TREE_SIDE_EFFECTS to 1. I don't know if it would make sense to introduce a maybe_save_expr that is equivalent to save_expr but does not set TREE_SIDE_EFFECTS if its argument doesn't have it. No, this would defeat the purpose of the SAVE_EXPR, since you could duplicate the expression or move it at will, leading to nasty order of evaluation issues.
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 --- Comment #17 from chrbr at gcc dot gnu.org --- Although not fully tested yet, could you guys please have a look at it? Christian, does it fix your Linux build problems, or are there still more / new ones? the 2.6.32 kernel build is fixed. thanks
[Bug tree-optimization/59245] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:443
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59245 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204454, set_value_range is called with INT_MIN as min and INT_MIN(ovf) as max.
[Bug tree-optimization/59287] points-to analysis confused by union accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59287 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Nov 26 09:04:44 2013 New Revision: 205380 URL: http://gcc.gnu.org/viewcvs?rev=205380root=gccview=rev Log: 2013-11-26 Richard Biener rguent...@suse.de PR tree-optimization/59287 * tree-ssa-structalias.c (get_constraint_for_component_ref): Remove no longer necessary special-casing of union accesses. * gcc.dg/tree-ssa/alias-29.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-29.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/59287] points-to analysis confused by union accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59287 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0 Resolution|--- |FIXED --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/59245] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:443
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59245 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine then.
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59289] [4.9 Regression][ARM] regression on unsigned-extend-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59289 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.9.0 Target Milestone|--- |4.9.0 Summary|[ARM] regression on |[4.9 Regression][ARM] |unsigned-extend-2.c |regression on ||unsigned-extend-2.c
[Bug target/59229] [4.9 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
C testcase:
void bar (char *);
void
foo (char *p, unsigned long l)
{
if (l 1 || l 6)
return;
char buf[7];
__builtin_memcpy (buf, p, l + 1);
bar (buf);
}
[Bug fortran/59298] New: ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 Bug ID: 59298 Summary: ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: adam at aphirst dot karoo.co.uk Created attachment 31294 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31294action=edit Minimal test case (thanks to gmarkall from #fortran for minimising further than I originally had) Defining a derived-type which contains an integer 2D array, and then attempting to initialise a PARAMETER variable of an array of that type using an array constructor causes an Internal Compiler Error. == Options used to build test case: == gfortran -Wall -Wextra -std=f2008 -march=native -s -c IBZ.f90 (in directory: /home/adam/Documents) f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions. Compilation failed. == GCC version and build options: == [adam@blaze ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.8.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --enable-multilib --disable-libssp --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.2 (GCC)
[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 Adam Hirst adam at aphirst dot karoo.co.uk changed: What|Removed |Added Attachment #31294|0 |1 is obsolete|| --- Comment #1 from Adam Hirst adam at aphirst dot karoo.co.uk --- Created attachment 31295 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31295action=edit Updated minimal test case (corrected a typo) Whoops, typo in the test-case I submitted. I was accidentally assigning an array to a scalar inside the function. Not sure how that crept in there. Anyway, with that 'fixed', the error message on compilation is exactly the same.
[Bug target/59229] [4.9 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31296 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31296action=edit gcc49-pr59229.patch Untested fix.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 --- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org --- However, building a tsan instrumented CP2K is non-trivial, as it requires Maybe let's do some remote debugging then :) The crash looks like someone corrupted the internal tsan's memory. Can you insert some Printf statements in sanitizer_stackdepot.cc to see how we get this crazy pointer value: 0x4d634810890c5593
[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- On x86_64-apple-darwin* the ICE is f951(47525) malloc: *** error for object 0x8: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug f951: internal compiler error: Abort trap The test compiles with gfortran 4.4.7, but ICE with revision 154654 (2009-11-25).
[Bug tree-optimization/59154] [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- H.J., can you please verify whether this is fixed now? Thanks.
[Bug c++/59296] [c++11] ref-qualified member function is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-26 Ever confirmed|0 |1
[Bug rtl-optimization/59166] [4.9 Regression] ICE in simplify_subreg, at simplify-rtx.c:5901 on valid code (at -O1 and above with -g enabled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59166 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204698.
[Bug tree-optimization/59288] [4.7/4.8/4.9 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I have a fix.
[Bug c++/58700] [4.8/4.9 Regression] ICE declaring static bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Nov 26 11:31:46 2013 New Revision: 205389 URL: http://gcc.gnu.org/viewcvs?rev=205389root=gccview=rev Log: /cp 2013-11-26 Paolo Carlini paolo.carl...@oracle.com PR c++/58700 * decl.c (grokdeclarator): Don't try to pass declarator-id_loc to build_lang_decl_loc when declarator is null. /testsuite 2013-11-26 Paolo Carlini paolo.carl...@oracle.com PR c++/58700 * g++.dg/parse/bitfield4.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/bitfield4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58700] [4.8 Regression] ICE declaring static bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.8.3 |4.9.0 Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE |declaring static bit-field |declaring static bit-field --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug rtl-optimization/59166] [4.9 Regression] ICE in simplify_subreg, at simplify-rtx.c:5901 on valid code (at -O1 and above with -g enabled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59166 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- In *.asmcons we still have correct: (debug_insn 30 29 31 7 (var_location:HI D#1 (subreg:HI (reg/v:SI 93 [ p ]) 0)) pr59166.c:20 -1 (nil)) but in *.ira we have: (debug_insn 30 29 31 7 (var_location:HI D#1 (reg/v:SI 97 [orig:93 p ] [93])) pr59166.c:20 -1 (nil)) (note the wrong mode).
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Nov 26 11:48:16 2013 New Revision: 205390 URL: http://gcc.gnu.org/viewcvs?rev=205390root=gccview=rev Log: PR target/58314 PR target/50751 * config/sh/sh.c (max_mov_insn_displacement, disp_addr_displacement): Prefix function names with 'sh_'. Make them non-static. * config/sh/sh-protos.h (sh_disp_addr_displacement, sh_max_mov_insn_displacement): Add declarations. * config/sh/constraints.md (Q): Reject QImode. (Sdd): Use match_code mem. (Snd): Fix erroneous matching of non-memory operands. * config/sh/predicates.md (short_displacement_mem_operand): New predicate. (general_movsrc_operand): Disallow PC relative QImode loads. * config/sh/sh.md (*movmode_reg_reg): Remove it. (*movqi, *movhi): Merge both insns into... (*movmode): ... this new insn. Replace generic 'm' constraints with 'Snd' and 'Sdd' constraints. Calculate insn length dynamically based on the operand types. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/constraints.md trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug tree-optimization/59249] if-conversion doesn't handle basic-blocks with only critical predecessor edges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59249 --- Comment #4 from Bingfeng Mei bmei at broadcom dot com --- Even I split one critical predecessor edge, predicate of BB6 is still ORed result of two conditions from BB4 BB5. ORing two conditions results in a sequence of statements that cannot be vectorized. Vectorizer complains of bit-precision arithmetic not supported because of boolean operations. Not sure how to transform the code except reverting back to a form similar to pre jump-threading.
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #32 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Nov 26 11:48:16 2013 New Revision: 205390 URL: http://gcc.gnu.org/viewcvs?rev=205390root=gccview=rev Log: PR target/58314 PR target/50751 * config/sh/sh.c (max_mov_insn_displacement, disp_addr_displacement): Prefix function names with 'sh_'. Make them non-static. * config/sh/sh-protos.h (sh_disp_addr_displacement, sh_max_mov_insn_displacement): Add declarations. * config/sh/constraints.md (Q): Reject QImode. (Sdd): Use match_code mem. (Snd): Fix erroneous matching of non-memory operands. * config/sh/predicates.md (short_displacement_mem_operand): New predicate. (general_movsrc_operand): Disallow PC relative QImode loads. * config/sh/sh.md (*movmode_reg_reg): Remove it. (*movqi, *movhi): Merge both insns into... (*movmode): ... this new insn. Replace generic 'm' constraints with 'Snd' and 'Sdd' constraints. Calculate insn length dynamically based on the operand types. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/constraints.md trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug rtl-optimization/59166] [4.9 Regression] ICE in simplify_subreg, at simplify-rtx.c:5901 on valid code (at -O1 and above with -g enabled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59166 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31297 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31297action=edit gcc49-pr59166.patch Untested fix.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
However, building a tsan instrumented CP2K is non-trivial, as it requires
Maybe let's do some remote debugging then :)
We can give this a try, but I might need rather detailed instructions. I.e.
starting from a sample printf statement and a suggested line number. With my
current setup, I get the segfault in a new location:
Program received signal SIGSEGV, Segmentation fault.
__sanitizer::find (s=0x, s@entry=0x74c2e8b8,
stack=stack@entry=0x74d797b8, size=size@entry=19,
hash=hash@entry=1116003544)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:109
109if (s-hash == hash s-size == size) {
(gdb) bt 7
#0 __sanitizer::find (s=0x, s@entry=0x74c2e8b8,
stack=stack@entry=0x74d797b8, size=size@entry=19,
hash=hash@entry=1116003544)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:109
#1 0x735ae1a1 in __sanitizer::StackDepotPut (stack=0x74d797b8,
size=19)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:150
#2 0x73570e4d in __tsan::CurrentStackId (thr=0x,
pc=140737301157816) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:305
#3 0x735a1404 in __tsan::user_alloc (thr=0x74d79780,
pc=140737276073318, sz=24, align=optimized out)
at ../../../../gcc/libsanitizer/tsan/tsan_mman.cc:110
#4 0x7358d58c in __interceptor_malloc (size=24) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:447
#5 0x757ba78c in timings::timestop (handle=339) at
/data/vjoost/clean/cp2k/cp2k/src/../src/timings.F:328
#6 0x776accf6 in dbcsr_error_handling::dbcsr_error_stop (handler=1,
error=...)
at
/data/vjoost/clean/cp2k/cp2k/src/../src/dbcsr_lib/dbcsr_error_handling.F:180
(More stack frames follow...)
(gdb) print s
$3 = (__sanitizer::StackDesc *) 0x
[Bug middle-end/59273] [4.9 Regression] ICE in expand_expr_real_2, at expr.c:9188 on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59273 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #3) Created attachment 31293 [details] gcc49-pr59273.patch Untested fix. I have started a native bootstrap + regtest on alpha.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
Maybe let's do some remote debugging then :)
For the current setup, the crash is always in StackDepotGet
The following printfs:
StackDesc *s = (StackDesc*)(v ~1);
printf(Getting %p\n,s);
for (; s; s = s-link) {
if (s-id == id) {
*size = s-size;
return s-stack;
}
printf(Following %p\n,s-link);
}
Always crash at an output like:
Getting (nil)
Getting 0x70305eb0
Following 0xc004832c2
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70461100 (LWP 24991)]
0x735ae4e0 in __sanitizer::StackDepotGet (id=4030474480, size=0x0) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:196
196 if (s-id == id) {
(gdb) print s
$2 = (__sanitizer::StackDesc *) 0xc004832c2
so the s-link field containing something unexpected.
[Bug middle-end/59152] [4.9 Regression] ICE: loop 2's latch does not have an edge to its header with -fopenmp -fipa-pure-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59152 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31298action=edit gcc49-pr59152.patch Untested fix.
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 Ed Smith-Rowland 3dw4rd at verizon dot net changed: What|Removed |Added CC||3dw4rd at verizon dot net --- Comment #4 from Ed Smith-Rowland 3dw4rd at verizon dot net --- It looks like libcpp/charset.c might have a lot of the guts that could help with the implementation of codecvt_utf8, etc. Maybe we could either get libcpp to handle it or just steal the code.
[Bug bootstrap/55552] --enable-gold=default doesn't work with in-tree binutils
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Nov 26 13:31:25 2013 New Revision: 205392 URL: http://gcc.gnu.org/viewcvs?rev=205392root=gccview=rev Log: Add -fuse-ld=bfd/-fuse-ld=gold support to exec-tool.in PR bootstrap/2 * configure.ac (install_gold_as_default): New. Set to yes for --disable-ld or --enable-gold=default. (gcc_cv_ld_gold_srcdir): New. (gcc_cv_ld): Also check in-tree gold if install_gold_as_default is yes. (ORIGINAL_LD_BFD_FOR_TARGET): New AC_SUBST. (ORIGINAL_LD_GOLD_FOR_TARGET): Likewise. * configure: Regenerated. * exec-tool.in (ORIGINAL_LD_BFD_FOR_TARGET): New variable. (ORIGINAL_LD_GOLD_FOR_TARGET): Likewise. (original) [collect-ld -fuse-ld=bfd]: Set to $ORIGINAL_LD_BFD_FOR_TARGET. (original) [collect-ld -fuse-ld=gold]: Set to $ORIGINAL_LD_GOLD_FOR_TARGET. (dir) [collect-ld ../gold/ld-new]: Set to gold. (fast_install) [collect-ld ../gold/ld-new]: Set to yes. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/exec-tool.in
[Bug bootstrap/55552] --enable-gold=default doesn't work with in-tree binutils
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Fixed for 4.9.0.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 --- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org --- Just insert more printfs everywhere you can :) E.g. print everything around s-link = s2 in StackDepotPut
[Bug tree-optimization/59299] New: We do not sink loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59299
Bug ID: 59299
Summary: We do not sink loads
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
When fixing PR57517 I noticed that we don't sink loads leading to that PR
int x[1024], y[1024], z[1024], w[1024];
void foo (void)
{
int i;
for (i = 1; i 1024; ++i)
{
int a = x[i];
int b = y[i];
int c = x[i-1];
int d = y[i-1];
if (w[i])
z[i] = (a + b) + (c + d);
}
}
results in
bb 4:
# i_18 = PHI i_15(3), 1(2)
a_5 = x[i_18];
b_6 = y[i_18];
_7 = i_18 + -1;
c_8 = x[_7];
d_9 = y[_7];
_10 = w[i_18];
if (_10 != 0)
goto bb 5;
else
goto bb 8;
bb 8:
goto bb 6;
bb 5:
_11 = a_5 + b_6;
_12 = c_8 + d_9;
_13 = _11 + _12;
z[i_18] = _13;
bb 6:
i_15 = i_18 + 1;
if (i_15 != 1024)
goto bb 3;
else
goto bb 7;
instead of
bb 4:
# i_18 = PHI i_15(3), 1(2)
_10 = w[i_18];
if (_10 != 0)
goto bb 5;
else
goto bb 8;
bb 8:
goto bb 6;
bb 5:
a_5 = x[i_18];
b_6 = y[i_18];
_7 = i_18 + -1;
c_8 = x[_7];
d_9 = y[_7];
_11 = a_5 + b_6;
_12 = c_8 + d_9;
_13 = _11 + _12;
z[i_18] = _13;
bb 6:
i_15 = i_18 + 1;
if (i_15 != 1024)
goto bb 3;
else
goto bb 7;
note that we eventually sink all computations into the if arm but only
stop at the loads.
tree-ssa-sink.c says:
@@ -294,8 +285,6 @@ statement_sink_location (gimple stmt, ba
be seen by an external routine that needs it depending on where it gets
moved to.
- We don't want to sink loads from memory.
-
We can't sink statements that end basic blocks without splitting the
incoming edge for the sink location to place it there.
but doesn't give a good reason IMHO.
I have a simple patch.
[Bug tree-optimization/59154] [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- It is fixed as of revision 205321: http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01801.html
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Bug 56706 depends on bug 59154, which changed state. Bug 59154 Summary: [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Ed Smith-Rowland from comment #4) It looks like libcpp/charset.c might have a lot of the guts that could help with the implementation of codecvt_utf8, etc. Maybe we could either get libcpp to handle it or just steal the code. That would be useful, thanks for the pointer. I have implementations of wstring_convert and wbuffer_convert but no way to test them without the new codecvt facets.
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- We also have ext/codecvt_specializations.h but it needs a lot of work to re-use.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #8)
Just insert more printfs everywhere you can :)
E.g. print everything around s-link = s2 in StackDepotPut
hmm I can write a lot of printfs, but it is not very targetted..
However, I think I got a little further. For this kind of crash:
Getting 0x7fffed22e328
Following 0x704b8a80
Following 0x40027bd6cd50653b
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed2f5100 (LWP 9760)]
0x7fffebbae530 in __sanitizer::StackDepotGet (id=3978818064, size=0x0)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:197
197 if (s-id == id) {
(gdb) print s
$3 = (__sanitizer::StackDesc *) 0x40027bd6cd50653b
I have put a hardware breakpoint on this field
break __sanitizer::StackDepotGet
awatch ((StackDesc*)0x704b8a80)-link
(which is the link that gets corrupted).
This breakpoint gets activated from CP2K at:
[Switching to Thread 0x7fffed3ec100 (LWP 9804)]
Hardware access (read/write) watchpoint 13: ((StackDesc*)0x704b8a80)-link
Value = (PTR TO - ( __sanitizer::StackDesc )) 0x40027bd6cd50653b
0x7fffee8811fe in hfx_load_balance_methods::estimate_basic (p=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1829
1829 p1=p(1) ; p2=p(2) ; p3=p(3) ; p4=p(4)
(gdb) bt
#0 0x7fffee8811fe in hfx_load_balance_methods::estimate_basic (p=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1829
#1 0x7fffee881020 in hfx_load_balance_methods::cost_model (nsa=1, nsb=1,
nsc=1, nsd=1, npgfa=6, npgfb=6,
npgfc=6, npgfd=6, ratio=-0.3026277383289448, p1=..., p2=..., p3=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1817
#2 0x7fffee87ee8c in hfx_load_balance_methods::estimate_block_cost
(natom=3, nkind=2, list_ij=...,
list_kl=..., set_list_ij=..., set_list_kl=..., iatom_start=1, iatom_end=1,
jatom_start=1, jatom_end=1,
katom_start=1, katom_end=1, latom_start=1, latom_end=1, particle_set=...,
coeffs_set=..., coeffs_kind=...,
is_assoc_atomic_block_global=..., do_periodic=.FALSE., kind_of=...,
basis_parameter=..., pmax_set=...,
pmax_atom=..., pmax_blocks=0, cell=0x7d312d80, do_p_screening=.FALSE.,
map_atom_to_kind_atom=...,
eval_type=1, log10_eps_schwarz=-10, log_2=0.3010299956639812,
coeffs_kind_max0=1.1049525569372649,
use_virial=.FALSE., atomic_pair_list=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:2212
This is the 'correct' place for corruption, as this routine is only called for
those runs that segfault.
Potentially interesting is that this is also a routine that is somewhat special
in Fortran, i.e. a contained subroutine, which presumably is treated somewhat
special by the compiler (not sure about the C-like equivalent, maybe nested
functions or so ?)
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31299 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31299action=edit patch Patch fixing the testcase (but otherwise untested - we don't have too many internal fn testcases).
[Bug c++/59300] New: visibility computation misses some attributes in namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
Bug ID: 59300
Summary: visibility computation misses some attributes in
namespaces
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Given
namespace nfoo {
class foo {
void f();
};
}
namespace nfoo __attribute__((visibility(hidden))) {
void foo::f() {}
}
gcc trunk r205392 produces a symbol with default visibility. GCC normally
considers the visibility of followup decls, so I was expecting hidden.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- well, maybe a more simple reason. If I export export OMP_STACKSIZE=32M (i.e. stack size for the threads), the segfault disappears... does that sound like a good reason (i.e. tsan instrumented binary might require more stack), or does this seem just lucky coincidence ?
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Nov 26 15:06:06 2013 New Revision: 205394 URL: http://gcc.gnu.org/viewcvs?rev=205394root=gccview=rev Log: [gcc/] 2013-11-26 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/59290 * config/arm/arm.md (*zextendsidi_negsi): New pattern. * config/arm/arm.c (arm_new_rtx_costs): Initialise cost correctly for zero_extend case. [gcc/testsuite/] 2013-11-26 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/59290 * gcc.target/arm/negdi-2.c: Scan more general register names. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/negdi-2.c
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 --- Comment #6 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|arm |arm-*-* Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/59245] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:443
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59245 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Nov 26 15:14:52 2013 New Revision: 205395 URL: http://gcc.gnu.org/viewcvs?rev=205395root=gccview=rev Log: 2013-11-26 Richard Biener rguent...@suse.de PR tree-optimization/59245 * tree-vrp.c (set_value_range): Assert that we don't have overflowed constants (but our infinities). (set_value_range_to_value): Drop all overflow flags. (vrp_visit_phi_node): Likewise. (vrp_visit_assignment_or_call): Use set_value_range_to_value to set a constant range. * gcc.dg/torture/pr59245.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59245.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/59245] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:443
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59245 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/59301] New: Please enable -Wstrict-overflow as part of -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301
Bug ID: 59301
Summary: Please enable -Wstrict-overflow as part of -Wextra
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: j at uriah dot heep.sax.de
The -fstrict-overflow behaviour can lead to surprising results. Consider
the following code that came up in a forum, complaining about why GCC
optimizes the first loop into an endless one:
int main (void)
{
int i = 0;
while (--i)
asm(nop);
for (;;);
}
The (obvious, in that short piece of code) expectation of the programmer
was that the NOP is executed a finite number of times (basically, just
waiting a bit that way), and the code flow then proceeds to the final
infinite loop.
Instead, the resulting code is an infinite loop around the NOP statement.
(The original question came out for the AVR target, but the behaviour is
completely independent of the actual target.)
Specifying the commonly used -Wall -Wextra options doesn't tell the innocent
programmer the compiler basically already detected some undefined behaviour,
and might have reordered the code due to that undefined behaviour. Only
by specifying -Wstrict-overflow, one gets:
foo.c: In function 'main':
foo.c:4:11: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
I think it would be much better to include -Wstrict-overflow into -Wextra,
so people get aware of the potential problems.
[Bug sanitizer/59302] New: tsan: Unexpected mmap in InternalAllocator!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302 Bug ID: 59302 Summary: tsan: Unexpected mmap in InternalAllocator! Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org One tsan test I'm doing fails with: Unexpected mmap in InternalAllocator apart from expecting a somewhat more useful output (e.g. Sanitizer internal error: Unexpected mmap in InternalAllocator ) Maybe this shouldn't happen ? I'm getting this with the following backtrace: [Switching to Thread 0x703ce100 (LWP 17517)] Breakpoint 1, Allocate (stat=optimized out, alignment=optimized out, size=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948 948MapUnmapCallback().OnMap(map_beg, map_size); (gdb) bt #0 Allocate (stat=optimized out, alignment=optimized out, size=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948 #1 Allocate (cleared=optimized out, alignment=optimized out, size=optimized out, cache=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:1187 #2 RawInternalAlloc (cache=0x7039e4c8, size=131080) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.cc:75 #3 __sanitizer::InternalAlloc (size=131072, cache=0x7039e4c8) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.cc:93 #4 0x735a6c6f in EnsureSize (size=4097, this=0x737dc310 __tsan::ctx_placeholder+64656) at ../../../../gcc/libsanitizer/tsan/tsan_vector.h:98 #5 PushBack (v=..., this=0x737dc310 __tsan::ctx_placeholder+64656) at ../../../../gcc/libsanitizer/tsan/tsan_vector.h:60 #6 HandleRacyStacks (thr=optimized out, addr_max=optimized out, addr_min=optimized out, traces=...) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:487 #7 __tsan::ReportRace (thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:676 #8 0x735a9e82 in __tsan_report_race_thunk () at ../../../../gcc/libsanitizer/tsan/tsan_rtl_amd64.S:122 #9 0x73577a48 in HandleRace (old=..., cur=..., shadow_mem=optimized out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376 #10 MemoryAccessImpl (cur=..., shadow_mem=optimized out, kIsAtomic=optimized out, kAccessIsWrite=optimized out, kAccessSizeLog=optimized out, addr=optimized out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:460 #11 __tsan::MemoryAccess (thr=0x7035b780, pc=542014296, addr=3378151234108248, kAccessSizeLog=8, kAccessIsWrite=true, kIsAtomic=true) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:531 #12 0x0004006f23be9d58 in ?? () #13 0x0fffc0d69de0 in ?? () #14 0x0008 in ?? () #15 0x in ?? () (gdb) cont Continuing. Unexpected mmap in InternalAllocator![Thread 0x703ce100 (LWP 17517) exited] [Thread 0x70462100 (LWP 17516) exited] [Thread 0x74cf6100 (LWP 17515) exited] [Thread 0x7fffeefff700 (LWP 17514) exited] [Inferior 1 (process 17510) exited with code 01]
[Bug tree-optimization/59303] New: [ARM/AArch32//AArch64] regressions in uninit-pred-8_b.c and uninit-pred-9_b.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 Bug ID: 59303 Summary: [ARM/AArch32//AArch64] regressions in uninit-pred-8_b.c and uninit-pred-9_b.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 204194 from Andrew Pinski: 2013-10-29 Andrew Pinski apin...@cavium.com * tree-ssa-ifcombine.c: Include rtl.h and tm_p.h. (ifcombine_ifandif): Handle cases where maybe_fold_and_comparisons fails, combining the branches anyways. (tree_ssa_ifcombine): Inverse the order of the basic block walk, increases the number of combinings. * gimple.h (gsi_start_nondebug_after_labels_bb): New function. 2013-10-29 Andrew Pinski apin...@cavium.com Zhenqiang Chen zhenqiang.c...@linaro.org * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: New test case. * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: New test case. * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: New test case. * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: New test case. * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: New test case. * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: New test case. * gcc.dg/tree-ssa/phi-opt-9.c: Use a function call to prevent conditional move to be used. * gcc.dg/tree-ssa/ssa-dom-thread-3.c: Remove. I have noticed regressions on ARM targets. The 2 mentioned testcases now FAIL (used to PASS): gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 20) gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 24) It is the case in the following configurations: targets: arm-none-linux-gnueabi, arm-none-linux-gnueabihf, armeb-none-linux-gnueabihf mode: arm,thumb cpu: cortex-a9 fpu: default, vfpv3, neon-fp16 targets: aarch64-none-elf, aarch64-none-linux These 2 regressions do not appear when configuring --target arm-none-linux-gnueabihf --with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16 However, when configuring --target arm-none-linux-gnueabihf --with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16, some of the newly introduced tests fail: gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c scan-tree-dump optimized gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c scan-tree-dump optimized gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c scan-tree-dump-times optimized 2 gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c scan-tree-dump-times optimized \\| 2
