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

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 avoi

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 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

Re: [buildrobot] ia64-hpux

On Tue, 2013-11-26 04:26:57 +0100, Jan-Benedict Glaw 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 -

Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM

On 26 November 2013 22:05, Jeff Law 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

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 fa

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

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

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

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

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 (

[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

Re: [buildrobot] microblaze-elf / microblaze-linux

On Tue, 2013-11-26 19:50:10 +, Joern Rennecke wrote: > On 26 November 2013 17:38, Joel Sherrill 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? >

Re: [buildrobot] microblaze-elf / microblaze-linux

On 26 November 2013 17:38, Joel Sherrill 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

Fixed! (was: [buildrobot] epiphany-elf)

Hi! On Tue, 2013-11-26 04:27:56 +0100, Jan-Benedict Glaw 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 --

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 paper

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

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

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

Re: [RFC] Detect most integer overflows.

On Nov 9, 2013, at 02:48, Ondřej Bílka 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

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 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 sugges

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 o

Re: Using BIGGEST_ALIGNMENT to remove alignment constraints

On Tue, Nov 26, 2013 at 7:12 AM, Paulo Matos 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

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

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 unk

Re: [buildrobot] pdp11-aout

On Nov 26, 2013, at 11:03 AM, Joern Rennecke wrote: > On 26 November 2013 15:55, Paul Koning 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 >

Re: [buildrobot] pdp11-aout

On 11/26/13 08:55, Paul Koning wrote: On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw 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

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 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=4071

Re: [buildrobot] microblaze-elf / microblaze-linux

On Tue, 2013-11-26 08:13:12 -0800, Michael Eager 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?

Re: [buildrobot] microblaze-elf / microblaze-linux

On Tue, 2013-11-26 07:50:34 -0800, Michael Eager 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

Re: [buildrobot] pdp11-aout

P.S.: This is PR54664. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664

Re: [buildrobot] pdp11-aout

On 26 November 2013 15:55, Paul Koning 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_

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 micr

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, wh

Re: [buildrobot] pdp11-aout

On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw 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 > -

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-lis

Re: [buildrobot] microblaze-elf / microblaze-linux

On Tue, 2013-11-26 15:21:12 +, Joern Rennecke wrote: > On 26 November 2013 14:51, Jan-Benedict Glaw wrote: > > On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill > > wrote: > > > Was microblaze-rtems attempted? I would have expected a failure > > > like these if so. > > > > No, it wasn't. I

Re: [buildrobot] microblaze-elf / microblaze-linux

On 26 November 2013 14:51, Jan-Benedict Glaw wrote: > On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill > 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 w

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 fa

Re: [buildrobot] First results of running contrib/config-list.mk

On Mon, Nov 25, 2013 at 7:20 PM, Jan-Benedict Glaw 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 h

Re: [buildrobot] microblaze-elf / microblaze-linux

On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill wrote: > 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

Re: [buildrobot] avr-rtems

On Tue, 2013-11-26 06:31:44 -0600, Joel Sherrill wrote: > Jan-Benedict Glaw 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

Re: [buildrobot] microblaze-elf / microblaze-linux

Was microblaze-rtems attempted? I would have expected a failure like these if so. --joel 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

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 wrote: Hi! Build log is available at http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38764 . g++ -c -DIN_GCC_FRONTEND -D

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 bre

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 t

Re: [buildrobot] alpha64-dec-vms / alpha-dec-vms

On 26 Nov 2013, at 04:23, Jan-Benedict Glaw 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

Re: [buildrobot] avr-rtems

On Tue, 2013-11-26 04:28:41 +0100, Jan-Benedict Glaw 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.wedd