https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I added the test case which is at least freed from a lot of docu and
the heavy autotools/libtool setup. The makefile compiles the code and
creates a binary seg_prod. Run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839
Bug ID: 61839
Summary: More optimize opportunity
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #11 from Jürgen Reuter juergen.reuter at desy dot de ---
Sorry, wrong makefile logic. I will send a working and more reduced case later
this afternoon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
Bug ID: 61840
Summary: [4.9 regression] sync/atomic FAILs on
x86_64-unknown-linux-gnu
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr ---
After grabbing the missing *.c and *.f files, I end up ta
gfortran signal_interface.o sprintf_interface.o iso_varying_string.o
system_dependencies.o kinds.o limits.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #13 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33140
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33140action=edit
Abridged and hopefully working test case.
In the middle of reducing the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #14 from Jürgen Reuter juergen.reuter at desy dot de ---
By the way, the -fcheck=all triggered other problems with definitely valid
code, so I guess there is another compiler bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414
Andre Vehreschild vehre at gmx dot de changed:
What|Removed |Added
CC||vehre at gmx dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414
--- Comment #3 from Andre Vehreschild vehre at gmx dot de ---
Hi,
this is my first attempt on a patch. Please comment, when something is missing.
The error occurs in the translation phase, but I tracked its source to the
parse phase where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Damien Buhl (daminetreg) from comment #40)
I can also confirm the crash with gcc-4.8.1 for an arm platform.
You'll have to provide more information about your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61841
Bug ID: 61841
Summary: broken std::thread on Hurd
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr ---
By the way, the -fcheck=all triggered other problems with definitely valid
code, so I guess there is another compiler bug.
Is it new (as in you don't see them with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr ---
From the files in the attachment in comment 8, the files that are affected by
this PR are beams.f90, models.f90, and process_libraries.f90:
beams.f90: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr ---
In comment 16 I have forgotten to list commands.f90
commands.f90: In function 'create_auto_decays':
commands.f90:3695:0: internal compiler error: in gfc_conv_expr_reference,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #18 from Jürgen Reuter juergen.reuter at desy dot de ---
I didn't get an ICE (yet) but it must in the auto_components part of the code.
I'll try to reduce the case a little further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842
Bug ID: 61842
Summary: [4.10 Regression]: Firefox start-up SEGFAULT with LTO
and O3
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #1 from Stefan kdevel at vogtner dot de ---
After configuring with --with-arch-32=i686 I get
PASS: runtime/pprof
Aborted
testing.tRunner
[redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:392
goroutine 1 [chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I didn't get an ICE (yet) but it must in the auto_components part of the code.
You are not supposed to get the ICEs mentioned in comments 16 and 17, they are
due to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
Please see [1] for the explanation of this problem. Your system doesn't support
.cfi directives and the referred patch doesn't handle this situation.
Since EBX register is marked as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #20 from Jürgen Reuter juergen.reuter at desy dot de ---
Ok, Dominique, you mean: compile everything with 4.9.1, then recompile
commands.f90 with 4.9.0 and build the executable with 4.9.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Ok, Dominique, you mean: compile everything with 4.9.1, then recompile
commands.f90 with 4.9.0
Yes
and build the executable with 4.9.0?
At this point 4.9.0 or 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843
Bug ID: 61843
Summary: Segmentation Fault on with avr-ld when linking with
AVR C++ Linker
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843
--- Comment #1 from peter petermilani at qfr dot net.au ---
version number:
$ avr-ld -v
GNU ld (GNU Binutils) 2.20.1.20100303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #19 from dhowells at redhat dot com dhowells at redhat dot com ---
This seems to have done the trick, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #2 from Ian Lance Taylor ian at airs dot com ---
Please tell us what kind of system you are running on and precisely how you ran
configure.
The error report doesn't make sense; it seems incomplete. I don't see how the
test could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #3 from Ian Lance Taylor ian at airs dot com ---
On the other bug Uros Bizjak suggests that perhaps the fix is
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00309.html
but that that patch does not work for you because your system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842
--- Comment #1 from Martin Liška mliska at suse dot cz ---
I've just double checked that I have the same issue with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61841
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
Bug ID: 61844
Summary: ICE when building libgcc for sh64 cross-compiler
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com ---
System compiler being used:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com ---
Created attachment 33144
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33144action=edit
Old, no-longer functional patch to libgcc
I was given the attached patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #3 from dhowells at redhat dot com dhowells at redhat dot com ---
The compiler is configured thusly:
AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #4 from dhowells at redhat dot com dhowells at redhat dot com ---
This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0
compiler tarball and no extra patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #5 from dhowells at redhat dot com dhowells at redhat dot com ---
Note that I also see a number of warnings like:
/usr/bin/sh64-linux-gnu-nm: _sdivsi3_s.o: File format is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #7)
Please see [1] for the explanation of this problem. Your system doesn't
support .cfi directives and the referred patch doesn't handle this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
This problem is also seen on CentOS 5, where CFI directives are not supported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #4 from Stefan kdevel at vogtner dot de ---
Thanks for the comments. I had an old as (binutils 2.19) on the system. After
replacing with binutils 2.22 GCC passes the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #20 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
Unfortunately, at the face of it, I think the only factors common with PR61844
are rot at the RTL level and building libgcc. (My own involvement with
SH64 is too far in the past
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Fri Jul 18 15:56:00 2014
New Revision: 212822
URL: https://gcc.gnu.org/viewcvs?rev=212822root=gccview=rev
Log:
PR libstdc++/61835
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #21 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
(In reply to Hans-Peter Nilsson from comment #20)
Unfortunately, at the face of it, I think the only factors common with
PR61844 are rot at the RTL level and building libgcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #22 from dhowells at redhat dot com dhowells at redhat dot com ---
That's a shame. It's just that the error messages look very similar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 18 16:13:45 2014
New Revision: 212824
URL: https://gcc.gnu.org/viewcvs?rev=212824root=gccview=rev
Log:
PR target/61794
* config/i386/sse.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 18 16:18:02 2014
New Revision: 212825
URL: https://gcc.gnu.org/viewcvs?rev=212825root=gccview=rev
Log:
Backport from mainline
2014-07-18 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
Attachment #33138|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61461
--- Comment #1 from edlinger at gcc dot gnu.org ---
Author: edlinger
Date: Fri Jul 18 18:11:53 2014
New Revision: 212829
URL: https://gcc.gnu.org/viewcvs?rev=212829root=gccview=rev
Log:
2014-07-18 Bernd Edlinger bernd.edlin...@hotmail.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
Mariano Bessone mariano.bessone at tallertechnologies dot com changed:
What|Removed |Added
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Could you test the following patch?
--- ../_clean/gcc/fortran/trans-expr.c2014-07-07 22:48:04.0 +0200
+++ gcc/fortran/trans-expr.c2014-07-18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
Bug ID: 61846
Summary: gcc assumes errno might be negative and issues
unnecessary warning
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
--- Comment #1 from Zbigniew Jędrzejewski-Szmek zbyszek at in dot waw.pl ---
Created attachment 33150
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33150action=edit
compilation logs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
--- Comment #2 from Zbigniew Jędrzejewski-Szmek zbyszek at in dot waw.pl ---
Created attachment 33151
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33151action=edit
processed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
Zbigniew Jędrzejewski-Szmek zbyszek at in dot waw.pl changed:
What|Removed |Added
Attachment #33148|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org ---
C99 also has this requirement. But C89 did not.
Values for errno are now required to be distinct positive values rather than
non-zero values. This change is for alignment with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #24 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33153
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153action=edit
Further cutting down the example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Bug ID: 61847
Summary: bug in gfortran runtime on OSX: digits cut off when
reading floating point number
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
Jerry DeLisle jvdelisle at gcc dot gnu.org changed:
What|Removed |Added
Attachment #33114|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843
--- Comment #2 from peter petermilani at qfr dot net.au ---
Possibly the same bug as:
http://www.avrfreaks.net/index.php?name=PNphpBB2file=printviewt=136763start=0
segmentation fault goes away if I remove the -mrelax linker flag.
, -Og we get:
.filet.c
.text
.globlf
.typef, @function
f:
.LFB0:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE0:
.sizef, .-f
.identGCC: (GNU) 4.10.0 20140718 (experimental)
.section.note.GNU-stack,,@progbits
While at -O2 and above (including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61849
Bug ID: 61849
Summary: exp(NaN+0_i) returns wrong value
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Jerry DeLisle jvdelisle at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61849
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
Most likely caused by:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=738a6bdaaa22a526fae65016127c229d99f377b4
There is this comment in c-decl.c:
/* Copy the assembler name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
The documentation does not say it has to be only in the declaration:
section (section-name)
Normally, the compiler places the code it generates in the text section.
Sometimes,
68 matches
Mail list logo
