[Bug c++/36833] unexpected warning: guard 13936 owner may be used uninitialized in this function
--- Comment #3 from gcc at dpinol dot com 2008-08-11 06:33 --- (In reply to comment #2) > This warning is valid as far as I can tell as the compiler does not know > ACE_OS::mutex_lock does not throw. > Hi, then why removing any of these 3 lines from CircularBuffer's constructor causes the warning to disappear? c_pBufferStart( new int[ 10 ]), c_pBufferEnd( c_pBufferStart+10), m_pRead( (int*)c_pBufferStart ), thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36833
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #6 from Joey dot ye at intel dot com 2008-08-11 05:52 --- (In reply to comment #4) > If you remove -ffast-math, does it miscompare? Passes without -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug fortran/37077] Implement Internal Unit I/O for character KIND=4
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-08-11 05:14 --- Currently the Fortran front end does not recognize an internal unit of KIND=4. Fixing this is a follow up to the UTF-8 patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-11 05:14:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37077
[Bug fortran/37077] New: Implement Internal Unit I/O for character KIND=4
-- Summary: Implement Internal Unit I/O for character KIND=4 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37077
[Bug fortran/37076] New: Concatenation of KIND=4 strings with KIND=4 parameters fails
This program illustrates the problem. I think this is a rejects valid. At the point of failure in resolve.c, one of the operands has kind=1 for some reason. program test3 integer,parameter :: u = 4 character(1,u),parameter :: nen=char(int(z'5e74'),u) !year character(25,u) :: string string = u_"2008"//nen print *, u_"2008"//nen ! Compiles OK print *, u_"2008"//nen//u_"8" ! Rejects this. end program test3 $ gfc concat.f90 concat.f90:7.10: print *, u_"2008"//nen//u_"8" ! Rejects this. 1 Error: Operands of string concatenation operator at (1) are CHARACTER(1)/CHARACTER(4) -- Summary: Concatenation of KIND=4 strings with KIND=4 parameters fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37076
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-11 03:29 --- More info: 1. Revision 138207 introduced ICE. 2. Revision 138318 fixed ICE, but miscompiled mgrid. 3. Revision 138207 + change in revision 138318 also miscompiled mgrid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug target/36436] -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-11 02:40 --- Hmm, the attributes are being mishandled for some builtins: unit size align 64 symtab 0 alias set -1 canonical type 0x42d1e620 precision 64 pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x42d26700 arg-types chain chain readonly nothrow public external built-in decl_6 QI file line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_SCALB attributes <(null) 0x42d4a0e0> chain > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36436
[Bug target/36436] -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-11 02:35 ---
Reduced testcase:
extern unsigned char vec1[1024];
extern unsigned char vec2_char[1024];
void sse5_div_const2_uns_char ()
{
unsigned i;
for (i = 0; i < 1024; i++)
vec1[i] = vec2_char[i] / 2;
}
--- CUT ---
Compile it with -ftree-vrp -O1 -msse5 -ftree-vectorize --param ggc-min-expand=0
--param ggc-min-heapsize=0 to get a seg fault.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |target
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-08-11 02:35:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36436
[Bug tree-optimization/36436] -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 02:22 --- Reducing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36436
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #14 from tromey at gcc dot gnu dot org 2008-08-11 02:18 --- Just FYI -- I was thinking of PR 36478. I'll respond to the rest later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug middle-end/37075] gimple 003t.original dump duplicates initialisation statements
--- Comment #2 from bje at gcc dot gnu dot org 2008-08-11 02:17 --- Thanks for the clarification, Andrew. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37075
[Bug c++/36393] Copy constructor not used but required
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 02:14 --- >When binding an rvalue of class type to a reference, the copy constructor of >the class must be accessible. For instance, consider the following code: >From http://gcc.gnu.org/gcc-3.4/changes.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36393
[Bug tree-optimization/36389] [tuples] gimplify_cond_expr should be smarter
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-11 02:13 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Version|4.4.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36389
[Bug target/36358] -mvrsave / -mno-vrsave ignored
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 02:10 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-11 02:10:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36358
[Bug middle-end/37075] gimple 003t.original dump duplicates initialisation statements
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 02:08 --- This comes down to DECL_EXPR and BIND_EXPR. The BIND_EXPR is printing out the first "char * c = 0B;" while the DECL_EXPR is printing out the second one. This is expected as not all decls have a DECL_EXPR, only ones which have an initialization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37075
[Bug middle-end/37075] New: gimple 003t.original dump duplicates initialisation statements
Running gcc with -fdump-tree-all to get the gimple dumps, I see duplicate
statements in the .003t.original dump:
[bug.c]
int foo () { char *c = 0; return 0; }
[bug.c.003t.original]
;; Function foo (foo)
;; enabled by -tree-original
{
char * c = 0B;
char * c = 0B;
return 0;
}
(the fact that the second statement is misaligned is a minor nit).
--
Summary: gimple 003t.original dump duplicates initialisation
statements
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at gcc dot gnu dot org
GCC host triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37075
[Bug pch/36277] Please allow directing pch file localization/usage via direct compiler flag.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-11 02:02 --- Use -iquote for "" paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug driver/36272] Please add support for google-breakpad or build own system.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 02:00 --- (In reply to comment #1) > Redhat has patches that automatically tries to compile again and then produce > a > preprocessed source which makes this easier. I can contribute an updated patch for this too if needed. I have it working for Mac OS X, GNU/Linux and Windows too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36272
[Bug middle-end/36817] [4.3 Regression] internal compiler error: in compare_values_warnv
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Component|c |middle-end Keywords||ice-on-valid-code Known to fail||4.2.0 Known to work||4.4.0 Summary|internal compiler error: in |[4.3 Regression] internal |compare_values_warnv|compiler error: in ||compare_values_warnv Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36817
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug middle-end/36802] pop_gimplify_context ICE using openmp task construct
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:44 --- Confirmed, this worked in 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw | Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-08-11 01:44:23 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36802
[Bug bootstrap/36545] Type _uleb128_t doesn't defined properly in /gcc/unwind-dw2.c
--- Comment #2 from andry at inbox dot ru 2008-08-11 01:42 --- I don't know already. At now i have no this error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36545
[Bug target/36756] [4.4 Regression] g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:41 --- Confirmed, it is at least an user visible regression for 4.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-11 01:41:07 date|| Summary|g++.dg/tls-3.C ICE with |[4.4 Regression] g++.dg/tls- |section-anchors, unit-at-a- |3.C ICE with section- |time, no-toplevel-reorder |anchors, unit-at-a-time, no- ||toplevel-reorder Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36756
[Bug c++/36688] [4.3/4.4 Regression] Incorrect struct assignments with nested const initializers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 01:38 ---
Confirmed, target independent.
> t_foo x = init_x;
This is getting compiled down to just x = {} for some reason inside the
gimplifier.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |c++
Ever Confirmed|0 |1
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-08-11 01:38:50
date||
Summary|Incorrect struct assignments|[4.3/4.4 Regression]
|with nested const |Incorrect struct assignments
|initializers|with nested const
||initializers
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36688
[Bug target/36732] Internal compiller bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 01:33 --- This works on the trunk on x86_64-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36732
[Bug target/36733] Wery interesting compilation way (if no -Ox option)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-11 01:32 --- This is expected -O0 resulting code generation. We need it for getting good debugging information in some cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36733
[Bug rtl-optimization/36693] missed optimization for pointer access with offset on powerpc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 01:31 --- Hmm, this works on the trunk with -O2 -mtune=cell which means this is a scheduling issue: [EMAIL PROTECTED] ~]$ ~/gcc-mainline/bin/gcc -O2 -o - -S t.c -mtune=cell .file "t.c" .section".text" .align 2 .p2align 3,,7 .globl get_and_increment1 .type get_and_increment1, @function get_and_increment1: lwz 9,0(3) addi 0,9,4 stw 0,0(3) lwz 3,0(9) blr .size get_and_increment1,.-get_and_increment1 .align 2 .p2align 3,,7 .globl get_and_increment2 .type get_and_increment2, @function get_and_increment2: lwz 9,0(3) addi 0,9,4 stw 0,0(3) lwz 3,0(9) blr .size get_and_increment2,.-get_and_increment2 .ident "GCC: (GNU) 4.4.0 20080810 (experimental) [trunk revision 138922]" .section.note.GNU-stack,"",@progbits -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |rtl-optimization GCC host triplet|x86_64-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36693
[Bug target/36629] [4.4 Regression] ICE in _lshrdi3 when compiling 06/20/08 snapshot on x86_64
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:27 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||build, ice-on-valid-code Resolution||FIXED Summary|ICE in _lshrdi3 when|[4.4 Regression] ICE in |compiling 06/20/08 snapshot |_lshrdi3 when compiling |on x86_64 |06/20/08 snapshot on x86_64 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36629
[Bug target/36722] ICE with inline asm in 64bit mode because of type size
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 01:26 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|inline-asm |target Ever Confirmed|0 |1 Known to fail||4.0.1 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-08-11 01:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36722
[Bug libgcj/36640] Build gcc-4.2.1 release fails when configured with --with-xmlj using Sun's ld
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36640
[Bug rtl-optimization/34408] Invalid RTL sharing with -fsee and inline functions
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-08-11 01:22 --- *** Bug 36529 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||william dot l dot maynard at ||nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34408
[Bug rtl-optimization/36529] -fsee causes ICE
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-11 01:22 --- *** This bug has been marked as a duplicate of 34408 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
[Bug rtl-optimization/34408] Invalid RTL sharing with -fsee and inline functions
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-08-11 01:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34408
[Bug c/36556] OpenMP: incorrect 'not specified in enclosing parallel'
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:12 --- If I remove default(none), then it works. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||openmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36556
[Bug middle-end/36555] #pragma omp sections reduction-clause causes internal error
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:09 --- *** This bug has been marked as a duplicate of 36506 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36555
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-11 01:09 --- *** Bug 36555 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||david dot mcnamara at ||crescentbaysoftware dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug middle-end/36555] #pragma omp sections reduction-clause causes internal error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36555
[Bug bootstrap/36545] Type _uleb128_t doesn't defined properly in /gcc/unwind-dw2.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 01:07 --- How did you configure GCC and how did you invoke make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING GCC host triplet|i686-pc-mingw32 | GCC target triplet||i686-pc-mingw32/ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36545
[Bug c/36531] -Wno-packed appears to be disconnected/ignored
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:06 --- Can you provide a source which is able to reproduce this warning? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36531
[Bug tree-optimization/35468] [4.2/4.3/4.4 Regression] LHS of assignment can be folded to a constant causing ICE
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail||4.2.0 4.3.0 4.4.0 Known to work||4.1.0 4.0.1 Summary|LHS of assignment can be|[4.2/4.3/4.4 Regression] LHS |folded to a constant causing|of assignment can be folded |ICE |to a constant causing ICE Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-08-11 01:02 ---
This happens with the short testcase which does not need -fno-tree-dce and it
only needs -O0:
int main() {
*"c" = 'x';
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-11 01:01 --- *** Bug 36532 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||matti dot niemenmaa+gccbugs ||at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug middle-end/36532] ICE in simplify_subreg at simplify-rtx.c:4484
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 01:01 --- *** This bug has been marked as a duplicate of 35468 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36532
[Bug bootstrap/36853] Compiling gcc 4.3.1 with Ada fails with Gnat bug detection
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-11 00:56 --- >make profiledbootstrap Don't use make profiledbootstrap and that will make it through. *** This bug has been marked as a duplicate of 32581 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36853
[Bug middle-end/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-08-11 00:56 --- *** Bug 36853 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bitti at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #17 from pinskia at gcc dot gnu dot org 2008-08-11 00:54 --- Isn't this fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug fortran/36854] [meta] fortran front-end optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-11 00:53:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug web/36850] missing onlinedocs for 4.3.1
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-11 00:53:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36850
[Bug target/36831] sparc-sun-solaris2.6: Bootstrap comparison failure
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-11 00:51 --- Most likely stage1 is being miscompiled. This is hard to debug without knowing what version of GCC you are starting with. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|bootstrap |target Version|4.3.1 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36831
[Bug c/36849] IMA rejects to merge (function)decls with va_args
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:50 --- The error message is correct as the function types are not compatible. If in fact this is invalid C even though we don't currently diagnostic it without -combine. Closing as invalid as -combine is doing the correct job of rejecting this. > Ideally the __VA_ARGS__ would be dealt with as "any or none" param decl, so > the > function(s) above would be considered equal. No, that is not what the C/C++ standard says about compatible function types. Yes we could enable this and have -pedantic-error reject it but I don't see why we should allow this as it is obvious invalid C code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|middle-end |c Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36849
[Bug bootstrap/36838] [4.4 Regression] ICE: (__frame_state_for) unwind-dw2.c:1194
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-08-11 00:46 --- Does this work now? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||build, ice-on-valid-code Summary|ICE: (__frame_state_for)|[4.4 Regression] ICE: |unwind-dw2.c:1194 |(__frame_state_for) unwind- ||dw2.c:1194 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36838
[Bug c++/36833] unexpected warning: guard 13936 owner may be used uninitialized in this function
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 00:44 --- This warning is valid as far as I can tell as the compiler does not know ACE_OS::mutex_lock does not throw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36833
[Bug c/36823] Fails to warn about possibly uninitialized variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:37 --- So what is happening is that we are saying pp is another name for p so it gets optimized as that. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36823
[Bug middle-end/36938] [4.4 Regression] Revision 138140 caused FAIL: gcc.dg/20040206-1.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:30 --- Fixed by: 2008-07-29 Jan Hubicka <[EMAIL PROTECTED]> * gcc.dg/20040206-1.c: Expect frontend warning now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36938
[Bug preprocessor/36906] #pragma GNU poison index()
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 00:28 --- Let me expand on what I mean by the attribute deprecated. See http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html: deprecated The deprecated attribute results in a warning if the function is used anywhere in the source file. This is useful when identifying functions that are expected to be removed in a future version of a program. The warning also includes the location of the declaration of the deprecated function, to enable users to easily find further information about why the function is deprecated, or what they should do instead. Note that the warnings only occurs for uses: int old_fn () __attribute__ ((deprecated)); int old_fn (); int (*fn_ptr)() = old_fn; results in a warning on line 3 but not line 2. The deprecated attribute can also be used for variables and types (see Variable Attributes, see Type Attributes.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36906
[Bug tree-optimization/36891] [4.2/4.3/4.4 Regression] ICE with vector division and -ffast-math and LIM
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-11 00:26 --- Mine, this is a regression as 4.0.1 did not ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to fail||4.4.0 4.3.0 4.1.1 Known to work||4.0.1 Summary|ICE with vector division and|[4.2/4.3/4.4 Regression] ICE |-ffast-math and LIM |with vector division and - ||ffast-math and LIM Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36891
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-11 00:24 --- I don't that many folks who don't have a SSE2 compatible machine any more ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug other/36968] [4.4 regression] malloc corruption building jv-convert.exe
--- Comment #2 from aaronavay62 at aaronwl dot com 2008-08-11 00:22 --- Fixed. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug c++/37037] ICE on template class member function definition after explciit template class instantation
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 00:21 --- It compiled with 4.0.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-11 00:19 --- If you remove -ffast-math, does it miscompare? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug middle-end/36990] [4.4 Regression] -fipa-cp vs function pointers and extern template
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-11 00:18 --- This is related to PR 37046. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36990
[Bug middle-end/36990] [4.4 Regression] -fipa-cp vs extern template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-11 00:09 ---
Reduced testcase:
template class cla;
typedef cla <1> clas1;
template struct cla
{
int& f1(int& (*__pf)(const int&))
{
return __pf(1);
}
};
int& endl(const int& __os);
extern template class cla<1>;
void f ( clas1& o ) {
o.f1(endl);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.4.0
Known to work||4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-08-11 00:09:53
date||
Summary|ICE when gcc (4.4.0-|[4.4 Regression] -fipa-cp vs
|20080731) uses -fipa-cp|extern template
|with -O |
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36990
[Bug c++/37047] Missing warning for deprecated use of static
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 23:36 --- I don't think this is a good warning really as static is used all over the place. In system headers and really in almost all C++ code in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37047
[Bug c++/36971] Portability issue from gcc 2.96 to gcc 4.1.1 for c++ casting
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 23:28 --- >d *ptr = reinterpret_cast (c1); You are violating C/C++ aliasing rules as *c1 here is a c and not a d. Even though d inherits from c, this is undefined behavior still as it is not the opposite way around. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36971
[Bug other/36968] [4.4 regression] malloc corruption building jv-convert.exe
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|driver |other Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug bootstrap/36995] [4.3 Regression] cannot build combined tree from 4.3 branch + trunk binutils
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-10 23:26 --- As mentioned this is not a bug as you have to make sure that the dependent libraries are compatible. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36995
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-08-10 23:25 --- *** Bug 36600 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vapier at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug tree-optimization/36600] ICE while building e2fsprogs with -fipa-pta -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-10 23:25 --- *** This bug has been marked as a duplicate of 32305 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36600
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-10 23:24 --- *** Bug 36985 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||alexandre dot hamez at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug c++/36985] initialize_flags_in_bb, at tree-into-ssa.c:437
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-10 23:24 --- -fipa-pta is the cause, don't use that option as it does nothing to the generated code anyways. *** This bug has been marked as a duplicate of 32305 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
[Bug c++/36982] Unfolding of template function (in namesspace) using overloads (in same namespace) requires forward declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 23:21 --- This is correct behavior as MyType is not in the namespace so Read is not found after the call. If you want Read to be found, you can put it in the same namespace as MyType. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36982
[Bug c++/36979] 'sizeof' wrong when using typedef ... __attribute__((mode(*I))) in a template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 23:20 --- This was fixed with the patch that fixed PR 36662. *** This bug has been marked as a duplicate of 36662 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Resolution||DUPLICATE Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36979
[Bug c++/36662] [4.3/4.4 Regression] vector vs template
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-10 23:20 --- *** Bug 36979 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cyp561 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36662
[Bug c++/29143] address-of overloaded function does not work in function call
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-10 23:15 --- *** Bug 36975 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jens dot maurer at gmx dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143
gcc-bugs@gcc.gnu.org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 23:15 --- *** This bug has been marked as a duplicate of 29143 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36975
[Bug target/36973] ICE when compiling legal(at least compiles with 4.1.2) code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36973
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-10 23:13 --- (In reply to comment #12) > > I am not sure how that will work. How do you specify a different value of > > system_header for a single location? My understanding is that sysp is for a > > whole line_map, so you cannot just change its value for a single location. > > My understanding is that the problem is that we have a define in a system > header, like this from comment #8: > > #define _Complex_I 1.0iF > > But then we use this macro in user code, and get a warning, because we > lose track of the system-header-ness. Right now c_lex_with_flags calls > cpp_get_token_with_location. This function returns two locations for tokens > coming from a macro expansion: the original location of the token, and also > the location of the start of the expansion. Current we throw away the > former and just use the latter. But, we could be smarter about using > the former location as well. I thought as much until this point. However the issue remains on how to handle the two locations. It would require a lot of changes in both the c-parser and libcpp. The other approach that you mention (encoding the macro expansion in one single location information somehow) would probably be less intrusive. > I think there is another PR (maybe more) where this same idea would make > sense. Andrew? Any idea? > This would need some work to handle the token pasting case. [nice idea snipped] > I hope this makes sense and that I'm not missing something :) Yes. We probably do not need the whole macro expansion history, we just need to encode in a single location the current location of the token and the "original" location of the token. On the other hand, I am not sure how the macro expansion information could be used to provide nicer diagnostics. How do you decide to print the unexpanded macro, or the first expansion, or the second expansion? Furthermore, on which context: expanded macro in the context of the original macro or show the first expansion definition or...? Getting us to use one location right is proving to be difficult, doing ranges as LLVM would be nice but no one is working on it, so I thought that two locations final/original was a wild idea. A stack of macro expansions is like science fiction!! ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug tree-optimization/36956] [4.4 Regression] Revision 138207 causes some regressions
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-10 23:13 --- The matrix-*.c ones have been fixed now by: 2008-08-01 Doug Kwan <[EMAIL PROTECTED]> * matrix-reorg.c: Re-enable all code. ... bitfld-1* were fixed by: 2008-07-29 Jakub Jelinek <[EMAIL PROTECTED]> * c-format.c (check_format_types): Revert unwanted checkin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36956
[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-10 22:50 --- A patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00442.html (I miss the patch tracker!!!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35158
[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp
--- Comment #7 from danny dot dyk at tu-dortmund dot de 2008-08-10 22:49 --- Applicable to a subset of C++ doesn't equal C++ compatibility. I'm fine with OpenMP unable to successfully parallelise a majority of possible for loops. It's quite understandable. However, instead of throwing error messages it should keep these for loops singlethreaded and issue a warning. G++ is a C++ compiler, not an OpenMP compiler. The -fopenmp switch should not alter the perception of what is valid code and what not. Now, is there any part in the OpenMP standard that forces a valid implementation to bring all OpenMP directives to effect? Or is it OK to just issue warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35158
[Bug target/37029] Exception from shared library's functions or methods that return float (double, long double) value cannot be caught on HP-UX.
--- Comment #6 from danglin at gcc dot gnu dot org 2008-08-10 22:30 --- I tried this 4.1.2, 4.2.4 and 4.3.1. 4.1.2 aborts, the others don't. Also checked the test on HP-UX 11.00 with 4.3.1. As the 4.1 branch is closed, I am closing this patch as fixed. Regarding patches, I have essentially everything installed. HP has a fairly recent "gold" bundle for 11.11 on itrc.hp.com which is a good start. Then, there is a script that you can download. It creates a patch inventory. You can then submit the generated inventory using a web interface. It will generate a patch bundle of HP recommended patches. You would have to get an ITRC account to do this. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37029
[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-10 22:28 --- No idea how do you infer that from this. If you use #pragma omp for before a loop construct, there are many restrictions you need to honor to have a valid OpenMP program, this is just one of them. To list just some other is e.g. that the for condition must be present and be iter_var < lb (or <=, >, >=), while generic C/C++ for can have any expression there, there are restrictions on the increment expression as well (e.g. it has to be addition or subtraction to the iteration var, while non-OpenMP for can have any expression there, etc.). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35158
[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp
--- Comment #5 from danny dot dyk at tu-dortmund dot de 2008-08-10 22:17 --- That means - contrary to popular knowledge - that OpenMP is not C++ compatible. Fair enough! Just don't announce it as such, then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35158
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #12 from tromey at gcc dot gnu dot org 2008-08-10 22:17 --- > I am not sure how that will work. How do you specify a different value of > system_header for a single location? My understanding is that sysp is for a > whole line_map, so you cannot just change its value for a single location. My understanding is that the problem is that we have a define in a system header, like this from comment #8: #define _Complex_I 1.0iF But then we use this macro in user code, and get a warning, because we lose track of the system-header-ness. Right now c_lex_with_flags calls cpp_get_token_with_location. This function returns two locations for tokens coming from a macro expansion: the original location of the token, and also the location of the start of the expansion. Current we throw away the former and just use the latter. But, we could be smarter about using the former location as well. I think there is another PR (maybe more) where this same idea would make sense. This would need some work to handle the token pasting case. > We could handle this for each error but that is not ideal either. This would > be > trivial if tokens expanded from macros carried two locations around but I > guess > that is too expensive, isn't it? I think it would be interesting to encode the macro expansion and token pasting history into a location, the same way we encode the include history. I don't know how expensive this would be. If it is not too bad it would let us emit much nicer error messages in otherwise confusing macro-expansion cases. (In fact this would be my preferred implementation approach ... but it is much harder than just looking at the already-known second location.) I hope this makes sense and that I'm not missing something :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-10 21:46 --- This is invalid OpenMP code. See 2.5.1 (in OpenMP 3.0, similar wording is in 2.5 standard too): init-expr One of the following: var = lb integer-type var = lb random-access-iterator-type var = lb pointer-type var = lb Therefore int i(0) isn't valid init-expr. Having separate diagnostics for it rather than just reporting a generic parse error might make some sense though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35158
[Bug java/37051] Random failures running ECJ 3.4 (threading problem?)
--- Comment #2 from chewi at aura-online dot co dot uk 2008-08-10 20:57 --- Can this please be verified? They have already closed the bug on their end and I don't have the knowledge to do this myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37051
[Bug middle-end/37046] [4.4 Regression] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #7 from rguenther at suse dot de 2008-08-10 20:44 --- Subject: Re: [4.4 Regression] Inlining produces calls which gimple_call_fndecl cannot handle correctly On Sun, 10 Aug 2008, pinskia at gcc dot gnu dot org wrote: > --- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-10 20:27 > --- > Parts of it is fixed by: > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00549.html > > Or is it a full fix, I can't tell anymore :). It should fix it fully - but I'll leave it for Martin to check. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #12 from tobi at gcc dot gnu dot org 2008-08-10 20:43 --- The GFORTRAN_STDOUT_UNIT environment variable mentioned above should make your life a lot easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug ada/37038] Bogus warning from GCC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-10 20:35:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
[Bug ada/37038] Bogus warning from GCC
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-08-10 20:34 --- Oh I see it now: /* If the comparison is being folded and the operand on the LHS is being compared against a constant value that is outside of the natural range of OP0's type, then the predicate will always fold regardless of the value of OP0. If -Wtype-limits was specified, emit a warning. */ So the trick should be is set TREE_NO_WARNING on the comparison in the front-end and then have VRP check that (if it is possible to do so now after the tuples merge :( ). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
[Bug ada/37038] Bogus warning from GCC
--- Comment #6 from sam at gcc dot gnu dot org 2008-08-10 20:30 --- Subject: Re: Bogus warning from GCC >> The warning is likely to come from tree-vrp.c. > The only place which emits this warning is from c-common.c so I > think someone needs to debug this a little bit. Place a breakpoint > on warning and then look at the backtrace to figure out where the > warning is coming from. If it is truly coming from c-common.c, then > the Ada front-end is wrong to include that source at all. As I wrote, it must be coming from tree-vrp.c: the warning message is split on two lines there, which is why I didn't catch it either the first time I looked for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
[Bug middle-end/37046] [4.4 Regression] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-10 20:27 --- Parts of it is fixed by: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00549.html Or is it a full fix, I can't tell anymore :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|Inlining produces calls |[4.4 Regression] Inlining |which gimple_call_fndecl|produces calls which |cannot handle correctly |gimple_call_fndecl cannot ||handle correctly Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug middle-end/37044] Heisenbug: SVN of gcc throws internal compiler error on PPC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37044
[Bug ada/37038] Bogus warning from GCC
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-10 20:17 --- (In reply to comment #4) > The warning is likely to come from tree-vrp.c. The only place which emits this warning is from c-common.c so I think someone needs to debug this a little bit. Place a breakpoint on warning and then look at the backtrace to figure out where the warning is coming from. If it is truly coming from c-common.c, then the Ada front-end is wrong to include that source at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
[Bug testsuite/37074] gcc.dg/torture/stackalign/builtin-apply-4.c failed with SSE2
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-10 20:23 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00664.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||08/msg00664.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37074
[Bug libobjc/37054] undefined reference to `objc_exception_throw'
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 20:22 --- Mine, there are other functions missing from libobjc.def. I have to look into which ones are missing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-10 20:22:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37054
[Bug java/37051] Random failures running ECJ 3.4 (threading problem?)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-10 20:22 --- This sounds like there is a race condition inside ecj and not a bug in GCJ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37051
[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE for h264ref in |[4.4 Regression] ICE for |gather_interchange_stats|h264ref in |with -ftree-loop-linear |gather_interchange_stats ||with -ftree-loop-linear Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37031
[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||i?86-*-* Keywords||build, ice-on-valid-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37048
