https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #10 from Dominique d'Humieres ---
> 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 this as ./seg_prod input
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 ---
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 ---
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 file_utils.o diagnostics.o mrst20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #13 from Jürgen Reuter ---
Created attachment 33140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33140&action=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 ---
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 changed:
What|Removed |Added
CC||vehre at gmx dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414
--- Comment #3 from Andre Vehreschild ---
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 parameter matching is don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #41 from Jonathan Wakely ---
(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 compilation, see
http://gcc.g
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++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #15 from Dominique d'Humieres ---
> 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 gfortran 4.9.0)? What are the
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #16 from Dominique d'Humieres ---
>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 'beam_data_write':
beams.f90:144:0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #17 from Dominique d'Humieres ---
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, at
fortran/trans-expr.c:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #18 from Jürgen Reuter ---
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 ---
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 receive]:
testing.RunTests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #19 from Dominique d'Humieres ---
> 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 build I am using to track do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #7 from Uroš Bizjak ---
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 fixed, there is nothing we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #20 from Jürgen Reuter ---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #21 from Dominique d'Humieres ---
> 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 should not matter. So if
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 ---
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 ---
This seems to have done the trick, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #2 from Ian Lance Taylor ---
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 fail without printing o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840
--- Comment #3 from Ian Lance Taylor ---
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 does not support
CFI d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842
--- Comment #1 from Martin Liška ---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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 ---
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: x86_64-redhat-linux
Configured with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #2 from dhowells at redhat dot com ---
Created attachment 33144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33144&action=edit
Old, no-longer functional patch to libgcc
I was given the attached patch when I was on gcc-4.7 but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #3 from 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 \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #4 from 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 ---
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 ---
(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 situation.
>
> Since EBX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #9 from Uroš Bizjak ---
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 ---
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 ---
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 and then only perip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Fri Jul 18 15:56:00 2014
New Revision: 212822
URL: https://gcc.gnu.org/viewcvs?rev=212822&root=gcc&view=rev
Log:
PR libstdc++/61835
* python/libstdcxx/v6/printers.py (TemplateTyp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #21 from Hans-Peter Nilsson ---
(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".
Apparently also "w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #22 from 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=212824&root=gcc&view=rev
Log:
PR target/61794
* config/i386/sse.md (avx512f_vextract32x4
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=212825&root=gcc&view=rev
Log:
Backport from mainline
2014-07-18 Uros Bizjak
PR t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
Jürgen Reuter changed:
What|Removed |Added
Attachment #33138|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=212829&root=gcc&view=rev
Log:
2014-07-18 Bernd Edlinger
PR rtl-optimization/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835
Mariano Bessone changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #3 from Mariano B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #23 from Dominique d'Humieres ---
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 21:28:24.0 +0200
@@ -6512,7 +6512,
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 ---
Created attachment 33150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33150&action=edit
compilation logs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
--- Comment #2 from Zbigniew Jędrzejewski-Szmek ---
Created attachment 33151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33151&action=edit
processed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
Zbigniew Jędrzejewski-Szmek changed:
What|Removed |Added
Attachment #33148|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
--- Comment #4 from Andrew Pinski ---
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 the ISO/IEC 9899:1999
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #24 from Jürgen Reuter ---
Created attachment 33153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153&action=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
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
Jerry DeLisle changed:
What|Removed |Added
Attachment #33114|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843
--- Comment #2 from peter ---
Possibly the same bug as:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=136763&start=0
segmentation fault goes away if I remove the -mrelax linker flag.
t -O1, -O0, -Og we get:
.file"t.c"
.text
.globlf
.typef, @function
f:
.LFB0:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE0:
.sizef, .-f
.ident "GCC: (GNU) 4.10.0 20140718 (experimental)"
.section.note.GNU-stack,"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61849
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #2 from Andrew Pinski ---
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.
Currently, it can only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #3 from Andrew Pinski ---
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, however, you need additional s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #4 from Andrew Pinski ---
I think we are merging the decls incorrectly. We are only merging the section
name one way and both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #2 from Jerry DeLisle ---
Please see PR36857 for some background.
gfortran uses the glibc strtod functions to convert the string to real. I think
in your C code you need to do something like this:
setlocale(LC_ALL, "C");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #6 from Andrew Pinski ---
Created attachment 33156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33156&action=edit
Patch which I am testing
Patch to the C front-end which merges the section name both directions and not
just fr
71 matches
Mail list logo
