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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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.
P.S.: This is PR54664.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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.
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
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
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
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
*
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
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
*
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290
--- Comment #6 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|arm |arm-*-*
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
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
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
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:
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:
1 - 100 of 302 matches
Mail list logo
