http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Chris Jones changed:
What|Removed |Added
CC||chris_s_jones at yahoo dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892
Paolo Carlini changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56973
Paolo Carlini changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57109
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|2013-04-29 00:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 57827, which changed state.
Bug 57827 Summary: compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827
What|Removed |Added
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731
Ramana Radhakrishnan changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Version|unkn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
--- Comment #4 from harper at msor dot vuw.ac.nz ---
The reason I sent that bug report is that I had read the manual and
found that -freal-4-real-16 makes the available real kinds 8, 10, 16.
The Fortran standard says selected_real_kind(1) must give
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879
--- Comment #1 from Dmitry Gorbachev ---
GCC 20130526 (r199345) - works:
08048a10 :
main():
[...]
8048a62: mov$0x8048f60,%ecx
8048a67: mov$0x8048f80,%edx
8048a6c: mov$0xa1,%eax
8048a71: call 8049790
[...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879
Bug ID: 57879
Summary: GCC with -flto generates invalid code for genmddeps
program
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
--- Comment #3 from Steve Kargl ---
On Wed, Jul 10, 2013 at 05:42:03PM +, kargl at gcc dot gnu.org wrote:
> implicit none
> integer,parameter:: p1 = selected_real_kind(1)
>
> This initialization expression is requesting the type with
> sm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
--- Comment #1 from Easwaran Raman ---
Created attachment 30494
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30494&action=edit
Disassembly of the compiled r.ii
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
Bug ID: 57878
Summary: Incorrect code: live register clobbered in split2
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -Os in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O2 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57824
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57874
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57869
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57874
Bug ID: 57874
Summary: No SFINAE on ADL lookup failure
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57873
--- Comment #1 from Bernhard ---
Created attachment 30492
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30492&action=edit
Compiled assembly code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57873
Bug ID: 57873
Summary: [avr-gcc] Local variable on stack overwritten by call
instruction on target AVR
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57844
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506
--- Comment #3 from Georg-Johann Lay ---
Fixed by r200870 (trunk), r200871 (4.8.2).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987
Georg-Johann Lay changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859
--- Comment #1 from Mikael Pettersson ---
With -m64: both test cases work with gcc-3.2.3, and fail with every release
from 3.3.6 up to current trunk.
With -m32: the first test case doesn't trap with any release since 3.2.3, the
second test case t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771
Joel Sherrill changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860
Mikael Pettersson changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801
--- Comment #4 from Patrick Marlier ---
Created attachment 30490
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30490&action=edit
reduced testcase.
I am now able to reproduce the ICE even with FSF 4.7.3 (it was due to different
included head
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861
Mikael Pettersson changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Michael Matz from comment #9)that it isn't anymore ;-)
>
> Well, too bad, I guess.
I am not sure of the exact details but unless the path itself is hard-coded,
you could always put a fake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484
--- Comment #20 from Uroš Bizjak ---
(In reply to Charles L. Wilcox from comment #19)
> (In reply to Uroš Bizjak from comment #11)
> > On an x86 target using the legacy x87 instructions and the 80-bit registers,
> > a load of a 64-bit or 32-bit va
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #5 from Sebastian Huber ---
(In reply to Alan Modra from comment #4)
> Created attachment 30489 [details]
> Fix ool_adjust
>
> Please verify that this fixes the problem
Yes, your patch fixes also the problem if applied to the 4.8 hea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484
--- Comment #19 from Charles L. Wilcox ---
(In reply to Uroš Bizjak from comment #11)
> On an x86 target using the legacy x87 instructions and the 80-bit registers,
> a load of a 64-bit or 32-bit value in memory into the 80-bit registers
> counts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #4 from Alan Modra ---
Created attachment 30489
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30489&action=edit
Fix ool_adjust
Please verify that this fixes the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #3 from Sebastian Huber ---
(In reply to Alan Modra from comment #2)
> My guess is that it's this change
>
> -#define FIRST_SAVED_GP_REGNO 13
> +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13)
>
> messing with ool_adjust.
I use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
Known to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #7 from Mikael Pettersson ---
(In reply to Gaetano Mendola from comment #6)
> struct in_addr myInAddr;
> myInAddr.s_addr = theIpHeader->daddr;
>
> as not portable, where myInAddr.s_addr and theIpHeader->daddr are of the
> same typ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #6 from Gaetano Mendola ---
That's clear to me.
I'm writing in C not in assembler, what I'm trying to understand is if I have
to
threat the following code:
struct in_addr myInAddr;
myInAddr.s_addr = theIpHeader->daddr;
as not po
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #5 from Mikael Pettersson ---
Your test case contains this:
===snip===
struct iphdr
{
...
};
...
int main()
{
char thePacket[1518];
memset(thePacket, 0, 1518);
thePacket[30] = 1;
thePacket[31] = 2;
thePacket[32] = 3;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858
--- Comment #5 from vincenzo Innocente ---
I remember something similar in the past
--param max-completely-peel-times=1
sort of fix it… (why pre does not recognize that 1/(1+0) == 1 btw??
of course it is just a benchmark (and I can modify it t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
Sebastian Huber changed:
What|Removed |Added
CC||amodra at gmail dot com
Known to w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #4 from Gaetano Mendola ---
At this point I'm very puzzled. The fact I have to use memcpy instead of an
assignment for sake of portability is plain wrong.
Consider that only looking at:
struct in_addr myInAddr;
myInAddr.s_addr =
58 matches
Mail list logo