[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #16 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-02-21 08:25:51 UTC --- Dear Mikael, snip Actually none of the gfc_compare_type/gfc_TK_compatible changes are absolutely necessary to fix this bug. It is just I found it odd that gfc_compare_type was calling gfc_type_compatible (compatible types are not necessary equal/equivalent), so I changed it so that gfc_type_compatible calls gfc_compare_type instead. And then the new gfc_TK_compatible function to not upset the testsuite. Maybe I just don't understand what compare types means. :-( snip Hem, yes, who wrote this? ( I hope it's not me ;-) ). There have been a number of contributors over the years. Therein lies the problem. Quick fix has been piled on quick fix and the result is something of a mess. It is just I found it odd that gfc_compare_type was calling gfc_type_compatible (compatible types are not necessary equal/equivalent), so I changed it so that gfc_type_compatible calls gfc_compare_type instead. That was indeed very peculiar. I know who the culprit was but I am not telling :-) If you have time to put this right I, for one, would be very pleased. A Paul
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 08:29:03 UTC --- Undefined behavior means anything can happen, so wondering why undefined behavior doesn't always behave the same doesn't make any sense. And, both gcc 4.4.5 and 4.5.2 do warn about this with -Wstrict-aliasing=1 -O2: pr47796.c:25: warning: dereferencing type-punned pointer might break strict-aliasing rules pr47796.c:31: warning: dereferencing type-punned pointer might break strict-aliasing rules Please stop reopening this.
[Bug preprocessor/39029] #pragma once is not exported from the precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #3 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21
09:37:03 UTC ---
g++ -o b.h.gch a.h
g++ c.cpp
a.h:
#pragma once // a.h:1:9: warning: #pragma once in main file
c.cpp:
#include b.h
#include b.h // c.cpp:2:15: error: b.h: No such file or directory
int main()
{
}
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 09:37:55 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.3.5, 4.4.5, 4.5.2, 4.6.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 09:37:55 UTC --- Confirmed. In Fortran 2003 such a code would be valid ... (In reply to comment #0) There are two errors For those having - like me - problems to spot the second error: static long double prechalf = nexafterl (0.5L, LDBL_MAX); long double prechalf = nextafterl (0.5L, LDBL_MAX);
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 09:44:34 UTC --- (In reply to comment #11) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 09:45:21 UTC --- (In reply to comment #5) It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. So The list in the manual already. is false. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists. I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #12 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:15 UTC --- Created attachment 23418 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23418 Test case (requires msp430 back end) Sorry, I don't speak dejagnu well enough yet to put target test conditionals into the code; this test lives in the gcc.target/msp430 directory in my environment.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #13 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:52 UTC --- Created attachment 23419 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23419 Generated code before patch applied
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #14 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:46:30 UTC --- Created attachment 23420 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23420 Generated code after patch applied
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 09:48:08 UTC --- (In reply to comment #9) Yep, that would have worked. Thanks for the clue. Is there any update on this issue? (Cf. also bug 47716 comment 6 and http://www.mailinglistarchive.com/fort...@gcc.gnu.org/msg17593.html )
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #15 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:48:23 UTC --- Created attachment 23421 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23421 Fixes problem
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #16 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:50:00 UTC --- I've now taken over the msp430 back end and created the attached patch and test case. This is relative to the gcc trunk as of a couple weeks ago; still present in all releases up to that point. Sorry it doesn't show up with any other back end, but perhaps an appeal to inspection could work while we get the msp430 target ready for integration: This is the only conditional of four in the same block that does not check for data.reverse before doing its thing. It's definitely wrong.
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:51:24 UTC --- Created attachment 23422 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23422 Fixes problem (resubmit, lost due to collision)
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 Peter A. Bigot bigotp at acm dot org changed: What|Removed |Added CC||bigotp at acm dot org --- Comment #2 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:53:10 UTC --- (In reply to comment #1) Created attachment 23422 [details] Fixes problem (resubmit, lost due to collision) Sorry, bugzilla confused me, this attachment was intended for 42722.
[Bug target/47831] New: avoid if-convertion if the conditional instructions and following conditional branch has the same condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47831
Summary: avoid if-convertion if the conditional instructions
and following conditional branch has the same
condition
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi
Created attachment 23423
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23423
testcase
Compile the attached source code with options -march=armv7-a -mthumb -Os, GCC
4.6 generates
ras_validate:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r4, r5, r6, lr}
addr4, sp, #4
movsr2, #4
movr1, r4
movr5, r0
blfoo
cmpr0, #0
itge// A
movger6, r0// B
bge.L3 // C
b.L7 // D
.L4:
addsr3, r6, r4
movr0, r5
subsr6, r6, #1
ldrbr1, [r3, #-1]@ zero_extendqisi2
blbar
addsr3, r0, #1
beq.L2
.L3:
cmpr6, #0
bne.L4
movr0, r6
b.L2
.L7:
movr0, #-1
.L2:
pop{r2, r3, r4, r5, r6, pc}
Instruction sequence ABCD can be replaced with
blt.L7
movr6, r0
b .L3
In both cases (lt or ge) the executed instructions is not longer than original
code. So it's shorter and faster.
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-21 10:03:36 UTC --- (In reply to comment #15) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4. Unfortunately it does not fix the problem on ppc.
[Bug objc/47832] New: [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
Summary: [4.6 Regression] ObjC errors on structures with
flexible data members
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: nic...@gcc.gnu.org, ia...@gcc.gnu.org
struct S
{
int s;
unsigned char *t[];
};
@interface T
{
struct S *u;
};
@end
@implementation T
{
};
@end
used to compile just fine in 4.5, but 4.6 rejects this
rh678928.m:14:1: error: instance variable has unknown size
I don't know ObjC enough to say whether this is intentional or not (and whether
ObjC standard actually talks about flexible array members at all). If flexible
array members should be allowed, then it would just need to make sure the
element type is complete, rather than the array type.
This breaks build of raidem, for original testcase see
http://bugzilla.redhat.com/678928
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2011-02-21 10:08:51 UTC --- there was no intention to create a hack (or any other form of expedient work); ... if it is wrong, then it is likely a mistake on my part when importing the original implementation from the 4.3-era branch. -- I have applied the patch @ comment #8 to r170338 on i686-darwin9 and powerpc-darwin9. It works on i686 ... ... but it does not work on powerpc. (both as comment #8 is written and with RS6000_BUILTIN_CFSTRING as the argument to darwin_init_cfstring_builtins) -- checking in gdb for cc1obj and lto1 -- darwin_init_cfstring_builtins () is being called for both (and with the same index value in each case). The routine appears be initializing the built-in correctly in both cases. (the same reported error is also present for a simple CFString c program, so not likely an objc problem). the programs compile and execute correctly without lto. .. any hints as to what additional steps are required for ppc would be appreciated.
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 10:33:10 Ever Confirmed|0 |1 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-21 10:33:10 UTC --- Any plan to backport the fix in revision 170317?
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:37:10
UTC ---
Hi Jakub,
@interface T
{
struct S *u;
};
@end
struct S * is a pointer, right ? So it's always the size of a pointer ?
In that case, I don't see any reason why it shouldn't be possible to use
it as an instance variable - it's a bug in the compiler if this is not
allowed. :-)
I think the new check in GCC 4.6 was supposed to catch the case
struct S
{
int s;
unsigned char *t[];
};
@interface T
{
struct S u;
};
@end
@implementation T
{
};
@end
this shouldn't be allowed. The reason is easy to understand:
* the list of instance variables in a class (inside @interface T { ... } @end)
is compiled into a struct in the end ;-)
* but, if the class is subclassed, the subclass instance variables are added
at the end of the superclass's struct
* so, if the list of instance variables ends with a flexible array member,
you get in trouble when you subclass the class, because the subclass
instance
variable struct will have a flexible array member *inside* (not at the end)
of the struct. ;-)
So, flexible array members should not be allowed as instance variables
anywhere.
This is what GCC 4.6 is trying to prevent.
But, in the testcase you show, the instance variable is not a flexible
array member; it's a pointer to a flexible array member. You can have
pointers to anything you want as instance variables. ;-)
I hope this helps with the Objective-C side.
Looking at the code, the check in encode_array() is not good enough. When the
instance variable type is encoded, the compiler will follow the pointer and
encode a description of the struct. The check in encode_array() will then
abort because the struct contains a flexible array member, without realizing
it is part of the struct pointed to.
I guess the fix should remove the check from encode_array() and move it higher
up when instance variables are added.
I can do the fix myself tonight (ie, in the next 12/24 hours) if you want.
Thanks
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #2 from Kai-Uwe Eckhardt kuehro at gmx dot de 2011-02-21 10:38:16 UTC --- Hi, There are two errors For those having - like me - problems to spot the second error: static long double prechalf = nexafterl (0.5L, LDBL_MAX); long double prechalf = nextafterl (0.5L, LDBL_MAX); well besides the typo nexfaterl declaring a variable static in block scope is evaluated as a const qualifier which cannot be assigned using a function. At least the default compiler on NetBSD gcc-4.1.3 tells me so. I tried to look it up in the C99 standard, if this is a compiler error or not. Mabey it would be cleaner to put the declaration at the beginning of the function roundl. Kai-Uwe Eckhardt
[Bug target/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
Status|RESOLVED|REOPENED
Last reconfirmed||2011.02.21 10:40:58
CC||hjl at gcc dot gnu.org
Component|c |target
Resolution|INVALID |
Ever Confirmed|0 |1
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21
10:40:58 UTC ---
The issue is that maskarray is initialized as array of ints but then you
load it as array of floats, the scheduler re-orders those so you see
a load from uninitialized stack:
test_setelement:
.LFB546:
subq$40, %rsp
.LCFI0:
movaps 16(%rsp), %xmm0
movl$0, 16(%rsp)
movl$0, 20(%rsp)
movaps %xmm0, %xmm1
andnps .LC1(%rip), %xmm0
movl$0, 24(%rsp)
movl$-1, 28(%rsp)
...
what is a bit inconsistent is that for mm_load_pd we use a type that
allows aliasing:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
...
/* Load two DPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_pd (double const *__P)
{
return *(__m128d *)__P;
}
but for mm_load_ps we don't:
/* Internal data types for implementing the intrinsics. */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
...
/* Load four SPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_ps (float const *__P)
{
return (__m128) *(__v4sf *)__P;
}
re-opening to investigate that. HJ, are the SSE1 intrinsics not
aliasing in the Intel API? The above snippets are from trunk.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 10:42:14 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:42:14 UTC --- Yes, confirmed. Good testcase. Thanks
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 10:44:03 UTC --- (In reply to comment #16) (In reply to comment #15) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4. Unfortunately it does not fix the problem on ppc. Of course, the patch doesn't touch rs6000 which has exactly the same problem.
[Bug bootstrap/47827] gcc fails to bootstrap on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47827 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 10:44:59 UTC --- Fixed.
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 11:19:33 UTC --- (In reply to comment #2) well besides the typo nexfaterl Well, that was actually the problem I had - my brain magically added the t ;-) (For NetBSD there is also PR 39570, which is about cabsf warnings.)
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21
12:02:58 UTC ---
As I said, I don't know ObjC, so if you could fix it, I'd appreciate it.
That said, ISO C99 allows:
struct A { int a; char b[]; };
struct A a; // Here sizeof (a) will be offsetof (struct A, b[0])
but doesn't allow:
struct B { struct A a; int i; };
So, for ObjC I guess it depends if in @interface there are variables (then
variables with flexible array members in theory could be treated there like ISO
C99 treats variables), or they are treated as struct fields, in which cases
fields with flex array members should be rejected. And you're right that it is
weird to reject there pointers to structs with flexible array members, unless
ObjC somehow encodes all the types each pointer points to, transitively.
[Bug c++/47833] New: ICE during GC in gt_ggc_mx_pending_template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47833
Summary: ICE during GC in gt_ggc_mx_pending_template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
template int int
foo () throw ()
{
return 0;
}
int
foo ()
{
if (false)
{
#define A(N) fooN ();
#define B(N) A(N##0) A(N##1) A(N##2) A(N##3) A(N##4) A(N##5) A(N##6) A(N##7)
A(N##8) A(N##9)
#define C(N) B(N##0) B(N##1) B(N##2) B(N##3) B(N##4) B(N##5) B(N##6) B(N##7)
B(N##8) B(N##9)
#define D(N) C(N##0) C(N##1) C(N##2) C(N##3) C(N##4) C(N##5) C(N##6) C(N##7)
C(N##8) C(N##9)
#define E(N) D(N##0) D(N##1) D(N##2) D(N##3) D(N##4) D(N##5) D(N##6) D(N##7)
D(N##8) D(N##9)
#define F(N) E(N##0) E(N##1) E(N##2) E(N##3) E(N##4) E(N##5) E(N##6) E(N##7)
E(N##8) E(N##9)
#define G(N) F(N##0) F(N##1) F(N##2) F(N##3) F(N##4) F(N##5) F(N##6) F(N##7)
F(N##8) F(N##9)
G(1)
}
return 0;
}
ICEs in 4.5/4.6, because the pending_templates list is too long and GC recurses
on it.
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2011-02-21 12:06:42 UTC --- (In reply to comment #7) Any plan to backport the fix in revision 170317? I had not planned so to do but would respond positively to popular pressure how far back would you want to go? Paul
[Bug c++/47833] ICE during GC in gt_ggc_mx_pending_template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47833 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.21 12:07:27 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:07:27 UTC --- Created attachment 23424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23424 gcc46-pr47833.patch Untested fix. The testcase takes over a minute to compile at -O0 on a fast box, so is not suitable for regression testing.
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 12:10:03 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Alan Modra amodra at gmail dot com 2011-02-21 12:10:03 UTC --- This is just a lack of else if (strcmp (language_string, GNU Go) == 0) i = mumble;
[Bug c++/47834] New: Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47834 Summary: Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: stene...@gmail.com Created attachment 23425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23425 Complete program needed for the bug triggering Dear Sirs, I have different result of executing program if I compile it with -On (n=1,2,3) optimization flag relative to compilation without optimizations. It seems that -On flag forces -funsafe-math-optimizations and/or -fassociative-math and/or -freciprocal-math without possibility to disable it. It effects in g++ including MinGW. I send you program based on the floating point arithmetic rounding properties in the attachment. The only correct result of the executing this code based on the Shewchuk's summation algorithm is 0. This is realy result of the program compiled by the command line g++ shewchuk.cpp but if I compile it by any of the command lines g++ -O3 shewchuk.cpp g++ -O3 -fno-unsafe-math-optimizations -fno-associative-math -fno-reciprocal-math shewchuk.cpp I obtain the result different than zero. Best regards
[Bug middle-end/35797] Compiler does not recognize faulty warnings starting with -Wno-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35797 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||WORKSFORME --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-02-21 12:22:37 UTC --- This is working as desired.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-02-21 12:30:27 UTC --- (In reply to comment #6) I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report. Feel free to create a patch http://gcc.gnu.org/contribute.html and submit it for review to gcc-patches. I think the general consensus among GCC devs is that such an option is not wanted, but if you still think is good, discussing it without a patch that defines exactly which options should be enabled is pointless. There are literally thousands of bugs that GCC devs would like to see fixed (search for NEW or REOPENED bugs) and several other thousands UNCONFIRMED bugs that need to be reviewed and confirmed. Keeping this one open forever is just distracting and a waste of time and effort! I am not going to close it again. If I have convinced you of the negative impact, please close this as DUPLICATED as Andrew did, or at least put it in WAITING. Otherwise, I guess in a few years you will have forgotten about this, and some GCC dev after stumbling into it for the nth time will close it forever.
[Bug c++/47834] Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47834 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 12:35:53 UTC --- You are running into PR323, use -ffloat-store or -mpc32 or use SSE and -mfpmath=sse. *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/323] optimized code gives strange floating point results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||stenedjo at gmail dot com --- Comment #180 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 12:35:53 UTC --- *** Bug 47834 has been marked as a duplicate of this bug. ***
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-21 12:39:28 UTC --- (In reply to comment #6) (In reply to comment #5) It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. So The list in the manual already. is false. The information is in the manual, even if not as an explicit list. I expect adding an explicit list would soon get out of date as it just increases the burden on contributors when adding new options. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists. I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report. The fact you don't agree doesn't change the fact this is a duplicate of that report, marking it as such helps keep the discussion in one place. Please don't reopen this report. If you want a new one for the documentation issue please open a new PR.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #9 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 12:47:24 UTC --- So The list in the manual already. is false. The information is in the manual, even if not as an explicit list. That's true, but not what was said. I expect adding an explicit list would soon get out of date as it just increases the burden on contributors when adding new options. Adding options that can't be easily enabled / found doesn't seem very useful. The fact you don't agree doesn't change the fact this is a duplicate of that report, marking it as such helps keep the discussion in one place. Please don't reopen this report. How do I reopen the other report? If you want a new one for the documentation issue please open a new PR. Why? Seems easier to use this one for it.
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #23 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-21 12:53:30 UTC --- (In reply to comment #22) What is the performance with 4.3 -O2? 4.3: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.373 4.6: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.347 so, same performance. Given that vectorization only happens at -O3, it is an important optimization level for numerical codes. Nevertheless, I would propose to remove the regression tag, and instead refocus the bug on the what current trunk does at -O3 vs -O2 -ftree-vectorize as noted in comment #21 gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:2.694 gfortran -O3 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:4.536
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:55:51 UTC --- Dup. *** This bug has been marked as a duplicate of bug 31573 ***
[Bug c++/31573] -Wall-all to enable all warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:55:51 UTC --- *** Bug 47824 has been marked as a duplicate of this bug. ***
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org 2011-02-21 12:57:31 UTC --- (In reply to comment #11) I don't know whether it fixes comment 0 or comment 4 Sorry, I forgot to precise. It fixes neither. More precisely for comments 0 and 4, it does fix a read of freed memory: ==82785== Invalid read of size 8 ==82785==at 0x400F21: __mod_all_MOD_add (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x4023D9: MAIN__ (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x402703: main (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785== Address 0x14be678 is 8 bytes inside a block of size 112 free'd but doesn't fix a double free affecting comments 0, 4 and 8: ==82785== Invalid free() / delete / delete[] ==82785==at 0x25A37E: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==82785==by 0x402609: MAIN__ (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x402703: main (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785== Address 0x14be3d0 is 0 bytes inside a block of size 8 free'd Comment 8 is not affected by the invalid read as the containing entity is not allocatable, hence not explicitly freed at the end. Thus, components release can't happen before containing entity's release. For the remaining double free, the temporary for the array constructor is filled using simple copies, and thus has components pointing to the original array. Those components are freed by the temporary array cleanup, and again during the final release of all allocatables. One could fix it by not freeing the temporary's components (no deep/nested free), but I have the feeling (haven't completely made my mind about it) that the proper fix, in the general case, is to create nested temporaries and do deep copies. And yes, that would be horribly expensive :-(.
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org 2011-02-21 13:01:23 UTC --- Comment 5 is not affected by the double free as the allocatable components are never allocated during the program, only the containing entity is.
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
--- Comment #7 from qihua.dai at intel dot com 2011-02-21 13:02:41 UTC ---
Hi,
I used -Wall -O2. But no warning for this situation.
gcc will print strict-aliasing related warning.
struct tmp1_s tmp;
tmp.a = 0xc; // this code line is removed unexpected after -O2 optimization
tmp.d = 0x1; // this code line is removed unexpected after -O2 optimization
data = *((unsigned int *)pTmp);
But, below code can fix above this warning. But this code might be removed by
gcc �CO2 in the situation of this bug.
struct tmp1_s tmp;
unsigned int *pData;
tmp.a = 0xc; // this code line is removed unexpected after -O2 optimization
tmp.d = 0x1; // this code line is removed unexpected after -O2 optimization
pData = (unsigned int *)pTmp;
data = *pData;
In addition, if cannot access bit field structure using an unsigned int, how to
share different bit field structure? For example,
void func(unsigned int data)
data can be bit field structure tmp1_s, or tmp2_s according to bit[31] (0 is
tmp1_s, 1 is tmp2_s)
struct tmp1_s {
unsigned int a : 12;
unsigned int b : 12;
unsigned int c : 7;
unsigned int d : 1;
}
struct tmp2_s {
unsigned int a : 1;
unsigned int b : 12;
unsigned int c : 12;
unsigned int d : 6;
unsigned int e : 1;
}
- Qihua
-Original Message-
From: jakub at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
Sent: 2011年2月21日 16:29
To: Dai, Qihua
Subject: [Bug c/47796] The code to write to a bit_field data strucuture will be
removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||INVALID
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21
08:29:03 UTC ---
Undefined behavior means anything can happen, so wondering why undefined
behavior doesn't always behave the same doesn't make any sense. And, both gcc
4.4.5 and 4.5.2 do warn about this with -Wstrict-aliasing=1 -O2:
pr47796.c:25: warning: dereferencing type-punned pointer might break
strict-aliasing rules
pr47796.c:31: warning: dereferencing type-punned pointer might break
strict-aliasing rules
Please stop reopening this.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #11 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 13:11:04 UTC --- Dup. No kidding?
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #20 from Thomas Henlich thenlich at users dot sourceforge.net 2011-02-21 13:22:59 UTC --- print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = 0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = 0 I think it's still wrong: It is not possible for any value to fit into a field of width w, but not into w+1. Either 1) For the special case of a zero, we consider the minus sign and the decimal symbol optional (which I think does not conform to the standard), then the result should be: print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = -0 (or 0. or 0) print (F1.0), -0.0 ! = 0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = -0 (or .0 or 0) print (F1.1), -0.0 ! = 0 or 2) We never consider the minus sign nor the decimal symbol optional (which I think is required by the standard), then the result should be: print (F0.0), -0.0 ! = -0. print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = * print (F0.1), -0.0 ! = -.0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = *
[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47820 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 13:38:54 UTC --- Author: rguenth Date: Mon Feb 21 13:38:48 2011 New Revision: 170359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170359 Log: 2011-02-21 Richard Guenther rguent...@suse.de PR lto/47820 * lto-streamer-in.c (lto_input_ts_decl_common_tree_pointers): Do not stream DECL_INITIAL for TRANSLATION_UNIT_DECLs. (lto_input_ts_block_tree_pointers): Hook a BLOCK into the TUs context. * lto-streamer-out.c (lto_output_ts_decl_common_tree_pointers): Do not stream DECL_INITIAL for TRANSLATION_UNIT_DECLs. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c
[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47820 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 13:42:36 UTC --- Fixed.
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #16 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 13:44:58 UTC --- Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/debug /pr47106.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v 3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib stdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc /libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util - fmessage-length=0 -gstabs1 -O -fpartial-inlining -flto -fconserve-stack -fcompar e-debug -S -o pr47106.s(timeout = 300) cc1plus: error: LTO support has not been enabled in this configuration compiler exited with status 1 output is: cc1plus: error: LTO support has not been enabled in this configuration FAIL: g++.dg/debug/pr47106.C -gstabs1 (test for excess errors) Excess errors: cc1plus: error: LTO support has not been enabled in this configuration
[Bug target/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com,
||ubizjak at gmail dot com
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-02-21 13:53:02
UTC ---
(In reply to comment #5)
/* Load four SPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_ps (float const *__P)
{
return (__m128) *(__v4sf *)__P;
}
re-opening to investigate that. HJ, are the SSE1 intrinsics not
aliasing in the Intel API? The above snippets are from trunk.
It is a bug and should be fixed.
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:22:51 UTC --- OK, can you tell I am time slicing this one. ;)
[Bug c++/47199] [4.6 Regression] [C++0x] ICE: expected class 'type', have 'declaration' (function_decl) in same_type_ignoring_top_level_qualifiers_p, at cp/typeck.c:1407 with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47199 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 14:26:06 UTC --- Fixed.
[Bug tree-optimization/47835] New: FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Summary: FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr46909.c -O2 -fdump-tree-ifcombine -S -o pr46909.s(timeout = 300) PASS: gcc.dg/pr46909.c (test for excess errors) FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4 See `!= 6' in tree dump.
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #22 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:32:14 UTC --- On my system I get with: print *, -- print (F0.0), -0.0 ! = -0. print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = * print *, -- print (F0.1), -0.0 ! = -.0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = * This. The difference being my signature zero. -- -0. -0. ** 0 -- -.0 -.0 ** 0 I confess, it does not look consistent. Next time slice, I will update it. ;)
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 14:33:14 UTC --- for ObjC I guess it depends if in @interface there are variables (then variables with flexible array members in theory could be treated there like ISO C99 treats variables), or they are treated as struct fields, in which cases fields with flex array members should be rejected I see your point. They are struct fields. Thanks
[Bug tree-optimization/42108] [4.4/4.5/4.6 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2009-11-19 16:49:51 |2011-02-21 16:49:51 --- Comment #51 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 14:33:16 UTC --- Re-confirmed. The PR42131 fix didn't improve the situation.
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:35:20 UTC --- Status update. I have more or less isolated the problem in list-read.c. I do not have an exact solution yet, but I am able to get the test case to work. I just need now to find the right place to make the tweak.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 14:37:14 UTC --- Created attachment 23426 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23426 Tree dump.
[Bug regression/47836] New: Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 Summary: Some Cross Compiler can't build target-libiberty or target-zlib Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: th.r.kl...@web.de With upcoming 4.6 building of target-libiberty and target-zlib is enabled (at most platforms) per default. It should be possible to disable this behavior e.g. with switches like: --without-target-libiberty --without-target-zlib Previous versions did not try to build these libraries for cross compilers. Index: configure.ac === --- configure.ac(revision 170359) +++ configure.ac(working copy) @@ -262,6 +262,16 @@ skipdirs= # Noconfigdirs are removed loudly. noconfigdirs= +# Make sure we don't let target-libiberty be added if we didn't want it. +if test x$with_target_libiberty = xno ; then + noconfigdirs=$noconfigdirs target-libiberty +fi + +# Make sure we don't let target-zlib be added if we didn't want it. +if test x$with_target_zlib = xno ; then + noconfigdirs=$noconfigdirs target-zlib +fi + use_gnu_ld= # Make sure we don't let GNU ld be added if we didn't want it. if test x$with_gnu_ld = xno ; then Index: configure === --- configure (revision 170359) +++ configure (working copy) @@ -2801,6 +2801,16 @@ skipdirs= # Noconfigdirs are removed loudly. noconfigdirs= +# Make sure we don't let target-libiberty be added if we didn't want it. +if test x$with_target_libiberty = xno ; then + noconfigdirs=$noconfigdirs target-libiberty +fi + +# Make sure we don't let target-zlib be added if we didn't want it. +if test x$with_target_zlib = xno ; then + noconfigdirs=$noconfigdirs target-zlib +fi + use_gnu_ld= # Make sure we don't let GNU ld be added if we didn't want it. if test x$with_gnu_ld = xno ; then
[Bug c/47837] New: FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47837 Summary: FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c -Wuninitialized -O2 -S -o uninit-pred-7_a.s(timeout = 300) /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo':/xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:26:11: warning: 'v' may be used uninitialized in this function [-Wuninitialized] /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo_2': /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:48:12: warning: 'v' may be used uninitialized in this function [-Wuninitialized] output is: /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo':/xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:26:11: warning: 'v' may be used uninitialized in this function [-Wuninitialized] /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo_2': /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:48:12: warning: 'v' may be used uninitialized in this function [-Wuninitialized] PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 20) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 23) FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 42) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 45) PASS: gcc.dg/uninit-pred-7_a.c warning (test for warnings, line 48) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 51) PASS: gcc.dg/uninit-pred-7_a.c (test for excess errors)
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487
--- Comment #3 from Peter Bergner bergner at gcc dot gnu.org 2011-02-21
15:02:40 UTC ---
I don't recall anyone adding GO support for powerpc{,64}-linux, so I'm guessing
such a patch should be added when that is submitted?
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #2 from janus at gcc dot gnu.org 2011-02-21 15:06:10 UTC --- (In reply to comment #1) Note: There are four cases where a polymorphic deallocate is needed - though some might end up in the same code path: - explicit DEALLOCATE (cf. comment 0) - implicit deallocate at the end of the scope - implicit deallocate via INTENT(OUT) (cf. PR 47637) - implicit deallocate when doing polymorphic reallocate on assignment (PR 43366) Some more things we need to consider: * explicit deallocation with STAT or ERRMSG * deallocation of allocatable components (explicit/implicit)
[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 15:11:14 UTC --- Mine.
[Bug tree-optimization/47838] New: FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 Summary: FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/foldconst-2.c -O2 -fdump-tree-optimi zed -S -o foldconst-2.s(timeout = 300) PASS: gcc.dg/tree-ssa/foldconst-2.c (test for excess errors) FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals.0
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 15:12:18 UTC --- Created attachment 23427 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23427 Tree dump.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-02-21 15:14:06 UTC --- I see the same pr46909 failure on powerpc64-linux too, with every weekly trunk snapshot since 2010-12-18.
[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 15:35:52 UTC --- Author: jason Date: Mon Feb 21 15:35:44 2011 New Revision: 170365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170365 Log: PR c++/47207 * decl2.c (decl_constant_var_p): A constexpr var needs an initializer to be constant. * semantics.c (cxx_eval_constant_expression): Complain about constexpr var used in its own initializer. * call.c (set_up_extended_ref_temp): Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl2.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 15:51:59 UTC --- Still fails on hppa1.1-hp-hpux10.20 with 4.6.0 revision 170207.
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 15:53:54 UTC --- Author: jakub Date: Mon Feb 21 15:53:49 2011 New Revision: 170366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170366 Log: PR debug/47106 * g++.dg/debug/pr47106.C: Require effective target lto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/pr47106.C
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.0 |4.7.0
[Bug fortran/47839] New: ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 Summary: ICE in dwarf2out.c:add_AT_specification Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Building 459.GemsFDTD (and 416.gamess) with -O3 -ffast-math -flto -g ICEs because the Fortran frontend seemingly puts imported variables in the BLOCK tree of the imported function and does not mark them external. The variable in question is huy_param from huygens_mod, imported from nft_store SUBROUTINE NFT_Store(Ex,Ey,Ez,Hx,Hy,Hz,t,ts) USE excite_mod, ONLY : excitation USE huygens_mod, ONLY : Huy_param, HuyPulseType and MODULE Huygens_mod ... real(kind=rfp), dimension(excite_max_no_param), PUBLIC :: Huy_param I tried to create a small testcase but failed sofar. It doesn't ICE with -flto-partition=none but it does with -flto-partition=1to1. With partially linking 459.GemsFDTD I get the ICE with /abuild/rguenther/install-trunk/usr/local/bin/gfortran globalvar.f90 PEC.f90 -o GemsFDTD -flto -flto-partition=none -r -nostdlib -O -g which is then obviously related to a different variable. Trying to reduce the sources now.
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 16:19:20 UTC --- --- a.f90 MODULE globalvar_mod integer:: xstart, ystart, zstart, xstop, ystop, zstop CONTAINS END MODULE globalvar_mod --- b.f90 MODULE PEC_mod CONTAINS SUBROUTINE PECapply(Ex,Ey,Ez) USE globalvar_mod, ONLY : xstart, ystart, zstart, xstop, ystop, zstop real(kind=8), dimension(xstart:xstop+1,ystart:ystop+1,zstart:zstop+1), intent(inout) :: Ex, Ey, Ez END SUBROUTINE PECapply END MODULE PEC_mod gfortran a.f90 b.f90 -flto -flto-partition=none -r -nostdlib -g lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:7558 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/47772] warnings from -Wmissing-field-initializers contradict documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772
Jonathan 'Sky' Squirawski webmas...@sky-siteweb.com changed:
What|Removed |Added
CC||webmas...@sky-siteweb.com
--- Comment #2 from Jonathan 'Sky' Squirawski webmas...@sky-siteweb.com
2011-02-21 16:55:39 UTC ---
I've the same problem with gcc 4.5.2.
Here another test case:
/*==*/
typedef struct bar_t {
int a;
int b;
} bar_t;
typedef struct foo_ok_t {
int bar;
bar_t foo;
} foo_ok_t;
typedef struct foo_nok_t {
bar_t bar;
bar_t foo;
} foo_nok_t;
int main(void) {
foo_ok_t foo_ok;
foo_nok_t foo_nok;
foo_ok = (foo_ok_t){
.bar = 32,
};
foo_nok = (foo_nok_t){
.bar = (bar_t){ .a = 32, .b = 42 },
};
return 0;
}
/*==*/
The first assignment doesn't trigger any warning, but the second one gives:
test.c:29:5: warning: missing initializer
test.c:29:5: warning: (near initialization for ‘(anonymous).foo’)
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-02-21 16:56:18 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/11 13:56, dave at hiauly1 dot hia.nrc.ca wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 20:56:54 UTC --- Is there no way to get a posix compliant ctime? Alternatively, we'll need autoconf magic to detect the extra arg. I know at one time it was relatively common, so autoconf magic might be around somewhere. Assuming it is you just have to do something like #if defined (oddballctime) *date = ctime_r (now, cbuf, CSZ); #else *date = ctime_r (now, cbuf); #endif Using ctime_r is a bit of a can of worms. The GNU autoconf manual recommends not using ctime_r unless the inputs are known to be within certain limits. Correct. The problem is some implementations can trigger buffer overflows for bad input. Certain implementations pass in a buffer size parameter to deal with that problem, others (glibc) presumably do some checking before dumping results into the user supplied buffer to make sure they don't exceed the 26 bytes or whatever the minimum size of hte buffer is supposed to be. Even for checking versions like glibc, if the wrong sized buffer is passed in, then it'll probably break. I guess the question we need to ask is how important are these routines and should we be issuing warnings when they are used, much like is done with gets. If we don't need them, I'd much prefer to see them go away as they're a rats nest of security issues. Just a quick glance at the code in libgfortran/ctime.c and I'm pretty sure it's vulnerable to a buffer overflow attack. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNYpkoAAoJEBRtltQi2kC7HwcH/3IEgG2sh265kwu9kKQQ87gf um1qKykJo4/Ph3W4UF7q1G26mw5luemVE6ga4+4nEzpivH0hzgsxWADDPXjQzq26 tqUXwh0nKi5665O1rcW88EZpej5J0MDLtUBTQXv1DipQWDBa/YjDqrmO4IRkw+MK QlkgPvCqosS1wvlbVJ9xKpTn2XY8tVTPdLlAMI3iBbbtDcsWMdKxaG5mpnhh8P4i HkVepfpRr5RtpuVN3SJ6AWhqR0PQgS1e2PB2WbbY8bvNy5ev1GggJZj/3j101jza /QseJ16lj3CqOMHCppHOhXGL8bxMFW17AWv/hL74+gTn9rZCH/JUjOQ+YzRgs0A= =SpA9 -END PGP SIGNATURE-
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-02-21 17:03:34 UTC --- I see the foldconst-2 failure also on powerpc64-linux, ever since the 20100904 trunk snapshot.
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.21 17:04:46
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21
17:04:46 UTC ---
We merge the decls during symtab merging. The prevailing one looks for example
like
(gdb) call debug_tree (prevailing-decl)
var_decl 0x75b3b0a0 zstart
type integer_type 0x77ee3498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee3498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef03f0
used public static SI file mod.f90 line 2 col 0 size integer_cst
0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32 context namespace_decl 0x75b31678 globalvar_mod
while the non-prevailing one is
var_decl 0x75b3b640 zstart
type integer_type 0x77ee3498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee3498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef03f0
used public ignored external SI file t.f90 line 4 col 0 size integer_cst
0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32
note that it is public and external and has a NULL DECL_CONTEXT.
The C frontend for a local extern declaration has
var_decl 0x75b481e0 i
type integer_type 0x77ee6498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee6498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef7540
used public external common SI defer-output file t.c line 8 col 15 size
integer_cst 0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32 context function_decl 0x75b49000 foo
thus puts it into function context. This decl is solely used for the BLOCK
tree, in the function a public external global var is used (which is
then merged with the static one from the other TU).
void foo (void)
{
extern int i;
i = 0;
}
---
int i;
Simplified Fortran testcase:
MODULE globalvar_mod
integer:: xstop
CONTAINS
END MODULE globalvar_mod
---
MODULE PEC_mod
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
END SUBROUTINE PECapply
END MODULE PEC_mod
it's important that PECapply is inside a module.
The decl is built by gfc_get_symbol_decl and put into the function via
gfc_add_decl_to_function - which is I think in general bogus for
imported decls. Its context is later cleared in pushdecl, but the
variable isn't removed from BLOCK_VARS.
I think we want to avoid gfc_add_decl_to_function in the first place.
[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-21 17:07:37 UTC --- Fixed.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 17:14:10 UTC --- So, I've tried a few linkers from various RHEL/Fedora distros, and narrowed it down to the fact that 20071102 ld still fails, while 20080208 ld already works. There have been pretty big --gc-sections changes in between, starting with: http://sources.redhat.com/ml/binutils/2007-12/msg0.html series and then its follow-ups BZ#5526 and BZ#5604.
[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-21 17:20:53 UTC --- Fixed.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 17:23:02 UTC --- Created attachment 23428 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23428 gcc46-pr46790-configury.patch Completely untested draft of a configury patch (still no code changes to actually revert Honza's changes ifdef HAVE_GLD_GC_BUG). I think writing a testcase that wouldn't use date strings would be quite entertaining (it would need to be written in assembler, but in a way that it assembles and does the right thing on all targets).
[Bug c++/44737] ICE in instantiate_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Known to fail|| --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-21 17:24:32 UTC --- Fixed. *** This bug has been marked as a duplicate of bug 44118 ***
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-21 17:24:32 UTC --- *** Bug 44737 has been marked as a duplicate of this bug. ***
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2011-02-21 17:30:00 UTC --- Testing datestamp seems resonable to me. I can do the changes needed to avoid .text subsections then (basically the elf implementation should then return NULL) Honza
[Bug c++/47833] ICE during GC in gt_ggc_mx_pending_template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47833 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 17:32:22 UTC --- Different testcase at https://bugzilla.redhat.com/attachment.cgi?id=479920
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21
17:41:20 UTC ---
Well, we don't want to use ctime because it is not thread-safe.
glibc ctime_r implementation should be safe if the passed buffer is at least 26
bytes long, it calls internally asctime, which is:
/* Like asctime, but write result to the user supplied buffer. The
buffer is only guaranteed to be 26 bytes in length. */
char *
__asctime_r (const struct tm *tp, char *buf)
{
return asctime_internal (tp, buf, 26);
}
and asctime_internal uses the passed buflen as second argument to snprintf.
[Bug rtl-optimization/46178] gcc.target/i386/(u)divmod-[58].c FAIL: ICE: in dec_register_pressure, at ira-lives.c:215 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46178 --- Comment #2 from Jeffrey A. Law law at gcc dot gnu.org 2011-02-21 17:43:18 UTC --- Author: law Date: Mon Feb 21 17:43:15 2011 New Revision: 170370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170370 Log: PR rtl-optimization/46178 * gcc.target/i386/pr46178.c: New test. PR rtl-optimization/46002 * gcc.c-torture/compile/pr46002.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr46002.c trunk/gcc/testsuite/gcc.target/i386/pr46178.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46002] ICE: in update_copy_costs, at ira-color.c:319 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46002 --- Comment #2 from Jeffrey A. Law law at gcc dot gnu.org 2011-02-21 17:43:18 UTC --- Author: law Date: Mon Feb 21 17:43:15 2011 New Revision: 170370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170370 Log: PR rtl-optimization/46178 * gcc.target/i386/pr46178.c: New test. PR rtl-optimization/46002 * gcc.c-torture/compile/pr46002.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr46002.c trunk/gcc/testsuite/gcc.target/i386/pr46178.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46178] gcc.target/i386/(u)divmod-[58].c FAIL: ICE: in dec_register_pressure, at ira-lives.c:215 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46178 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|4.6.0 | --- Comment #3 from Jeffrey A. Law law at redhat dot com 2011-02-21 17:44:27 UTC --- Fixed.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2011-02-21 17:47:14 UTC --- (In reply to comment #7) Interesting, I didn't know that :-) Do you have an example?
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 17:51:00 UTC --- HAVE_GAS_HIDDEN and HAVE_COMDAT_GROUP checks use ld --version date too.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 18:08:13 UTC --- (In reply to comment #6) Certain implementations pass in a buffer size parameter to deal with that problem, others (glibc) presumably do some checking before dumping results into the user supplied buffer to make sure they don't exceed the 26 bytes or whatever the minimum size of hte buffer is supposed to be. Baring implementation bugs I would claim that all two-argument ctime_r implementations should work with 26 byte arguments as POSIX has been defined as such: The ctime_r() function shall convert the calendar time pointed to by clock to local time in exactly the same form as ctime() and put the string into the array pointed to by buf (which shall be at least 26 bytes in size) and return buf. Unlike ctime(), the thread-safe version ctime_r() is not required to set tzname. http://pubs.opengroup.org/onlinepubs/009695399/functions/ctime.html The definition goes back to POSIX (SUSv2) of February 1997 - and IEEE Std 1003.1c-1995. One should assume that within the last 15 years they vendors managed to get the 26-byte buffer issue correct ... (How to deal with a three-argument version is a separate question; different vendors have probably different arguments, though buflen could be a more common choice.) I guess the question we need to ask is how important are these routines From he non-normative part of POSIX: The ctime_r() function is thread-safe and shall return values in a user-supplied buffer instead of possibly using a static data area that may be overwritten by each call.
[Bug target/47840] New: incorrect _mm256_insert_epi{32,64} implementations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47840
Summary: incorrect _mm256_insert_epi{32,64} implementations
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org
see avxintrin.h:
_mm256_insert_epi32 and _mm256_insert_epi64 use _mm_insert_epi16 internally
if __OPTIMIZE__ is not defined they use _mm_insert_epi32/64 internally - as I
would have expected.
I also checked 4.5 and 4.4, and it seems the bug was not noticed in any branch
yet.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #9 from Jeffrey A. Law law at redhat dot com 2011-02-21 18:49:02 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/11 10:41, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 17:41:20 UTC --- Well, we don't want to use ctime because it is not thread-safe. Right. glibc ctime_r implementation should be safe if the passed buffer is at least 26 bytes long, it calls internally asctime, which is: I'm aware that glibc's variant is safe from bogus input causing a buffer overrun. The problem is not every vendor's implementation is safe with regards to buffer overruns due to bogus input. Furthermore, I don't think any of the implementations are safe if the user supplied buffer is less than 26 bytes. So if an idiot programmer called ctime_r with too small a buffer, then we've got a buffer overrun and a vector for a security attack. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNYrOUAAoJEBRtltQi2kC7KPMH/25knyvBbLrN5lHbuBHJ9sh3 eGFMuym9/5yXRn/oAesxoPA/PqakfULGUgecF7168H+N+ECoHhn53D/clY5ea7Ti 6yuLb0a2rFMtZpn+BxB4JFzW3hdDXKjj8nIZiT5PuZX7yjLfIYlQZiVBpVG0IpfU wGGFXHUnGM1j4YDB0tStZnzU+4/rkXml2pmjBzApjGGDrMRXarrrCD4cEffBGZOc xnVLfcarKQ/wnltrEs3PCogG8zwpu4Gp6jJLnZDYNF4Rk8K4RhsvmeRzFND0n0ZM 3w9dBEQXF3AqmrWVBX08krgXornXN1n7zwj3bZdM6o6jH6iW5NY4vsyx4SRtZ7Q= =JcEq -END PGP SIGNATURE-
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #10 from Jeffrey A. Law law at redhat dot com 2011-02-21 18:51:09 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/11 11:09, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 18:08:13 UTC --- (In reply to comment #6) Certain implementations pass in a buffer size parameter to deal with that problem, others (glibc) presumably do some checking before dumping results into the user supplied buffer to make sure they don't exceed the 26 bytes or whatever the minimum size of hte buffer is supposed to be. Baring implementation bugs I would claim that all two-argument ctime_r implementations should work with 26 byte arguments as POSIX has been defined as such: The ctime_r() function shall convert the calendar time pointed to by clock to local time in exactly the same form as ctime() and put the string into the array pointed to by buf (which shall be at least 26 bytes in size) and return buf. Unlike ctime(), the thread-safe version ctime_r() is not required to set tzname. http://pubs.opengroup.org/onlinepubs/009695399/functions/ctime.html The problem is some vendors mucked up their implementations and don't stay within the 26 byte limit for bogus input values. And just because their implementations are correct *today* doesn't mean that they're correct on the systems which might be running this code. There's people still running very old systems out there. Furthermore, no implementation I'm aware of can catch teh case where the user supplied buffer is less than 26 bytes. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNYrQNAAoJEBRtltQi2kC7f28IAJdrRtgUiAewCofhz6jWNcZN DRBjZLybLfNx0sHX6czLql/1q1MNmJdtc0Vwmp6VnGHkoZtepY+HRwyu/6Y/5nAi cLaNHSkeOAKwR+JElzOqczRKxli/YBzYtgcTAJFD2nNTB0gK5h53hhR/Pup2JLmC PSddl3cDUdYdl9KRydRJpU0Z8hOC03fd70MMIxO//H12HTzpHXDsjCA8PrZTcY0l hEwyKRgw81zwB0+LHt0E14v9XhMm9t3U81FCngo1W/EKtEqAsGFHaMiZXl+ums0H 9LSIE53e10Tq5R6V4LpJhOa3Tpk7G/hbGraojdbq6w6unt/7nfVoZB4G4+yq9J8= =cpqO -END PGP SIGNATURE-
[Bug lto/47841] New: [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 Summary: [4.6 Regression] New guality test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 170359 gave FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 43 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto -flto-partition=none line 43 a.j == 14 FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 sizeof (a) == 6 Revision 170354 is OK.
[Bug lto/47841] [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-02-21 18:53:15 UTC --- It may be caused by revision 170359: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00904.html
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 18:58:27 UTC --- In libgfortran it is not the user, but libgfortran implementation, so it makes sure it always passes buffer of at least 26 bytes. If there are OSes where we can't trust ctime_r, we could either blacklist them (or whitelist the known good ones), or on some of them try to supply larger buffer (is there any implementation that would overflow say 256 or 1024 bytes)?
[Bug lto/47841] [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 19:02:10 UTC --- Saying these are regressions is weird, -flto has pretty much broken -g support and lots of guality tests don't FAIL just because of being flagged as UNSUPPORTED (as the tests conservatively assume some of the errors might be gdb bugs).
[Bug bootstrap/47806] Failure to build cross-combiner to powerpc-ibm-aix6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47806 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2011-02-21 19:09:57 UTC --- .
