[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (>30MB executable from 95byte source)
--- Comment #5 from mtrudel at gmx dot ch 2007-07-05 07:03 --- With "-Wl,-Map,/tmp/TheLinkMap.txt" you get a list of the objects that have been included from libgcj.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
[Bug tree-optimization/32589] [4.3 Regression] exp_dbug.adb:981: error: invalid array index
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-07-05 08:38 --- > FWIW, I haven't been able to bootstrap on ppc64-linux-gnu after this patch > went > in. I'm not sure I'd tried a full bootstrap before (I've only very recently > got easy access to a ppc box), but the failure is bootstrap compare in a bunch > of Ada files. It's unrelated to this patch, and apparently a PPC64-specific problem, see http://gcc.gnu.org/ml/gcc/2007-06/msg00784.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-05 08:41 --- For 4.1.x I get kernel: .LFB2: subq$8, %rsp .LCFI0: movl$1, %edi callgen_int movla(%rip), %eax movl%eax, %edx andl$3, %edx addl%edx, %eax movl%eax, a(%rip) movlb(%rip), %eax movl%eax, %edx orl $3, %edx addl%edx, %eax movl%eax, b(%rip) movla+4(%rip), %eax movl%eax, %edx andl$3, %edx addl%edx, %eax movl%eax, a+4(%rip) movlb+4(%rip), %eax movl%eax, %edx orl $3, %edx addl%edx, %eax movl%eax, b+4(%rip) addq$8, %rsp ret while with trunk we have kernel: .LFB2: subq$8, %rsp .LCFI0: movl$1, %edi callgen_int testl %eax, %eax je .L2 movla(%rip), %edx movl%edx, %eax andl$3, %eax addl%edx, %eax movlb(%rip), %edx movl%eax, a(%rip) movl%edx, %eax orl $3, %eax addl%edx, %eax movl%eax, b(%rip) .L7: movla+4(%rip), %edx movl%edx, %eax andl$3, %eax addl%edx, %eax movlb+4(%rip), %edx movl%eax, a+4(%rip) movl%edx, %eax orl $3, %eax addl%edx, %eax movl%eax, b+4(%rip) addq$8, %rsp ret .p2align 4,,10 .p2align 3 .L2: movla(%rip), %edx movl%edx, %eax andl$3, %eax addl%edx, %eax movlb(%rip), %edx movl%eax, a(%rip) movl%edx, %eax orl $3, %eax addl%edx, %eax movl%eax, b(%rip) jmp .L7 .LFE2: so, no, this is not yet fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug fortran/32630] New: [meta-bug] ISO C binding
Keep a list of ISO C binding related PRs. -- Summary: [meta-bug] ISO C binding Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org BugsThisDependsOn: 32580,32599,32600,32601,32627 OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
[Bug target/32450] -pg causes miscompilation
--- Comment #22 from jv244 at cam dot ac dot uk 2007-07-05 09:27 --- It really seems core2 specific, -march=nocona doesn't fail. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||wrong-code Known to fail||4.3.0 Summary|-pg seemingly causes|-pg causes miscompilation |miscompilation | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg causes miscompilation
--- Comment #23 from ubizjak at gmail dot com 2007-07-05 09:29 --- This is generic sched2 problem and affects all targets. The problem is that the call to mcount is emitted in final pass, so scheduler can't see it, and is free to move insns before (note 26 25 2 NOTE_INSN_PROLOGUE_END) that marks "call mcount" insertion point. It happens that on core2, scheduler moves compare before the note, and we got: .LCFI5: cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) callmcount jle .L6 Using -fno-schedule-insns2 fixes this problem. There are two ways to fix this problem: - The gcc way is to insert clobber of CC reg after the prologue end note. - The libc way is to fix _mcount to really do what it claims to do: /* We need a special version of the `mcount' function since for ix86 it must not clobber any register... and also save/restore flags reg to the stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg causes miscompilation
--- Comment #24 from ubizjak at gmail dot com 2007-07-05 09:41 --- glibc bug report at: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4744 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg causes miscompilation
--- Comment #25 from ubizjak at gmail dot com 2007-07-05 09:44 --- Also fails for 32bit builds on core2 target: __cp_log_handling_MOD_cp_add_default_logger: pushl %ebp movl%esp, %ebp subl$8, %esp cmpl$9, __cp_log_handling_MOD_stack_pointer callmcount jle .L6 call__cp_log_handling_MOD_mp_stop -- ubizjak at gmail dot com changed: What|Removed |Added GCC target triplet|x86_64-unknown-linux-gnu|i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #7 from bonzini at gnu dot org 2007-07-05 10:27 --- Using "s,g,g," or "s,^,," or even "b" as the default sed command doesn't seem to bad to me. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-05 10:27:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-07-05 10:46 --- Subject: Re: [4.0/4.1/4.2 Regression] address selection does not work correctly Yes, we should add a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug target/32450] -pg causes miscompilation
--- Comment #26 from jv244 at cam dot ac dot uk 2007-07-05 10:50 ---
adding a c testcase:
int stack_pointer=0;
void mystop()
{
abort();
}
void add()
{
if (stack_pointer+1>10)
{
mystop();
};
stack_pointer=stack_pointer+1;
}
int main()
{
add();
return stack_pointer-1 ;
}
> gcc -O2 -pg -march=native test.c
> ./a.out
Aborted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #8 from pcarlini at suse dot de 2007-07-05 10:54 --- Thanks David and Paolo. Ok, I'm sanity checking 's,g,g,' on linux... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #13 from bonzini at gnu dot org 2007-07-05 10:36 --- Can we mark it as WONTFIX for 4.0 to 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-07-05 10:43 --- > Can we mark it as WONTFIX for 4.0 to 4.2? Seems reasonable to me, but it would be nice to detect a future regression. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-05 11:01 --- fixed on trunk - thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #12 from joerg dot richter at pdv-fs dot de 2007-07-05 11:17 --- Of course, you are right. :) Just want to confirm, that all "s,g,g," and "s,^,," and "b" seem to work fine with AIX-sed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #11 from pault at gcc dot gnu dot org 2007-07-05 11:00 --- fixed on trunk - thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #9 from joerg dot richter at pdv-fs dot de 2007-07-05 11:00 --- I think the last g in 's,g,g,g' is the important one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #10 from pcarlini at suse dot de 2007-07-05 11:04 --- It isn't, as explained by Paolo off-line (by the way Paolo maintains GNU sed), essentially the same string is used in other projects to work around that AIX problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #11 from bonzini at gnu dot org 2007-07-05 11:13 --- Actually any no-op command would do, I think even "b" would be ok unless it triggers other bugs. In particular, replacing one g with a g, or all g's with g's, should not matter. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug ada/21327] gnat_ugn.texi invalid @direntry
--- Comment #1 from pixel at mandriva dot com 2007-07-05 11:20 ---
(bug still valid in trunk)
the fix is plain simple:
--- gcc/ada/gnat_ugn.texi (revision 126361)
+++ gcc/ada/gnat_ugn.texi (working copy)
@@ -101,7 +101,7 @@
@settitle @value{EDITION} User's Guide @value{PLATFORM}
@dircategory GNU Ada tools
@direntry
-* @value{EDITION} User's Guide (@value{FILE}) @value{PLATFORM}
+* @value{EDITION} User's Guide: (@value{FILE}). @value{PLATFORM}
@end direntry
@include gcc-common.texi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #15 from pcarlini at suse dot de 2007-07-05 11:46 --- Fixed for 4.2.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #13 from paolo at gcc dot gnu dot org 2007-07-05 11:45 --- Subject: Bug 31957 Author: paolo Date: Thu Jul 5 11:45:24 2007 New Revision: 126362 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126362 Log: 2007-07-05 Joerg Richter <[EMAIL PROTECTED]> PR libstdc++/31957 * include/Makefile.am: Work around an AIX sed oddity. * include/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #14 from paolo at gcc dot gnu dot org 2007-07-05 11:46 --- Subject: Bug 31957 Author: paolo Date: Thu Jul 5 11:46:00 2007 New Revision: 126363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126363 Log: 2007-07-05 Joerg Richter <[EMAIL PROTECTED]> PR libstdc++/31957 * include/Makefile.am: Work around an AIX sed oddity. * include/Makefile.in: Regenerate. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug fortran/32359] incorrect error: Threadprivate isn't SAVEd (implicit save attribute undefined)
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-05 12:52 --- Subject: Bug 32359 Author: burnus Date: Thu Jul 5 12:51:51 2007 New Revision: 126366 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126366 Log: gcc/fortran/ 2007-07-05 Daniel Franke <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32359 * gfortran.h (symbol_attribute): Change save attribute into an enum. * decl.c (add_init_expr_to_sym): Set it to SAVE_IMPLICIT. * symbol.c (gfc_add_save): Check for SAVE_EXPLICIT. * resolve.c (resolve_fl_variable): Check for SAVE_EXPLICIT. (resolve_symbol): Allow OMP threadprivate with initialization SAVEd and save_all variable. * trans-decl.c (gfc_finish_var_decl): Remove obsolete sym->value check. libgomp/ 2007-07-05 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32359 * testsuite/libgomp.fortran/pr32359.f90: New. gcc/testsuite/ 2007-07-05 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32359 * gfortran.dg/module_md5_1.f90: Update MD5 number. Added: trunk/libgomp/testsuite/libgomp.fortran/pr32359.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90 trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32359
[Bug tree-optimization/32631] New: internal compiler error: in generate_element_copy, at tree-sra.c:1801
Attached testcase ICEs when compiled with 'g++ -O2':\ messageoutput.cpp: In constructor âpov_frontend::MessageOutput::MessageOutput(void*)â: messageoutput.cpp:1090: internal compiler error: in generate_element_copy, at tree-sra.c:1801 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: in generate_element_copy, at tree-sra.c:1801 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32631
[Bug tree-optimization/32631] internal compiler error: in generate_element_copy, at tree-sra.c:1801
--- Comment #1 from ubizjak at gmail dot com 2007-07-05 13:21 --- Created an attachment (id=13849) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13849&action=view) delta reduced c++ preprocessed source g++ -O2 1520.cc: 1520.cc: In constructor âpov_frontend::MessageOutput::MessageOutput(void*)â: 1520.cc:150: internal compiler error: in generate_element_copy, at tree-sra.c:1801 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32631
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #2 from falk at debian dot org 2007-07-05 13:01 ---
I tried this patch from Andrew Pinski:
Index: gcc/config/alpha/alpha.c
===
--- gcc/config/alpha/alpha.c(revision 126053)
+++ gcc/config/alpha/alpha.c(working copy)
@@ -6111,8 +6111,8 @@
valist, offset_field, NULL_TREE);
t = make_tree (ptr_type_node, virtual_incoming_args_rtx);
- t = build2 (PLUS_EXPR, ptr_type_node, t,
- build_int_cst (NULL_TREE, offset));
+ t = build2 (POINTER_PLUS_EXPR, ptr_type_node, t,
+ size_int (offset));
t = build2 (GIMPLE_MODIFY_STMT, TREE_TYPE (base_field), base_field, t);
TREE_SIDE_EFFECTS (t) = 1;
expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL);
@@ -6172,8 +6173,8 @@
}
/* Build the final address and force that value into a temporary. */
- addr = build2 (PLUS_EXPR, ptr_type, fold_convert (ptr_type, base),
-fold_convert (ptr_type, addend));
+ addr = build2 (POINTER_PLUS_EXPR, ptr_type, fold_convert (ptr_type, base),
+fold_convert (sizetype, addend));
internal_post = NULL;
gimplify_expr (&addr, pre_p, &internal_post, is_gimple_val, fb_rvalue);
append_to_statement_list (internal_post, pre_p);
which allows bootstrap to continue, but it still fails:
checking for alphaev68-unknown-linux-gnu-gcc...
/src/gcc-2007.07.05/build/./gcc/xgcc -B/src/gcc-2007.07.05/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[2]: Leaving directory `/src/gcc-2007.07.05/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/src/gcc-2007.07.05/build'
make: *** [all] Error 2
libgcc/config.log says:
configure:2566: checking for suffix of object files
configure:2587: /src/gcc-2007.07.05/build/./gcc/xgcc
-B/src/gcc-2007.07.05/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/loc
al/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-
include -c -g -O2 conftest.c >&5
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
configure:2590: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2604: error: cannot compute suffix of object files: cannot compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug driver/32632] New: -pie won't override -shared in -shared -pie
bash-3.2$ cat x.c
#include
int
main ()
{
printf ("Hello\n");
return 0;
}
bash-3.2$ gcc -pie x.c -fpie
bash-3.2$ ./a.out
Hello
bash-3.2$ gcc -shared -pie x.c -fpie
bash-3.2$ ./a.out
bash: ./a.out: /lib/ld64.so.1: bad ELF interpreter: No such file or directory
bash-3.2$
I am expecting -pie will override -shared.
--
Summary: -pie won't override -shared in -shared -pie
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32632
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #5 from ubizjak at gmail dot com 2007-07-05 13:46 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug driver/32632] -pie won't override -shared in -shared -pie
--- Comment #1 from hjl at lucon dot org 2007-07-05 13:31 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00305.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||07/msg00305.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32632
[Bug fortran/30107] improve diagnostic of RECURSIVE LOGICAL SUBROUTINE
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-05 13:36 --- An attempt is made to match it as a variable declaration which fails because LOGICAL SUBROUTINE foo either misses th '::' or a ',' between SUBROUTINE and FOO resulting in a "Syntax error in data declaration". Matching as subroutine, as intended won't work either as subroutines must not have a type. I agree on WONTFIX. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30107
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #8 from ubizjak at gmail dot com 2007-07-05 13:45 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug testsuite/32014] new gcc failures
--- Comment #10 from ubizjak at gmail dot com 2007-07-05 14:04 --- Patch for: FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized 1 loops 1 has been committed to SVN. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug testsuite/32014] new gcc failures
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug fortran/32633] New: bogus error
MODULE test IMPLICIT NONE CHARACTER(len=1), PARAMETER :: backslash = '\\' PUBLIC :: backslash END MODULE > gfortran test.f90 test.f90:4.21: PUBLIC :: backslash 1 Error: PARAMETER attribute conflicts with SAVE attribute in 'backslash' at (1) -- Summary: bogus error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #132 from jv244 at cam dot ac dot uk 2007-07-05 14:39 --- new bogus gfortran error on CP2K : PR 32633 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-05 14:31 --- Reduced testcase: $> cat pr31320.f90 type :: a integer, allocatable :: i(:) end type a type(a) :: x, y x = a ((/1, 2, 3, 4/)) y = x end $> gfortran-svn -g -Wall pr31320.f90 $> valgrind --tool=memcheck --leak-check=full --show-reachable=yes a.out [...] ==3173== Invalid read of size 1 ==3173==at 0x4022CC1: memcpy (mc_replace_strmem.c:406) ==3173==by 0x80488AE: MAIN__ (alloc_comp_assign_2e.f90:8) ==3173==by 0x8048938: main (fmain.c:22) ==3173== Address 0x422C5C3 is 3 bytes after a block of size 16 alloc'd ==3173==at 0x40213D0: malloc (vg_replace_malloc.c:149) ==3173==by 0x8048710: MAIN__ (alloc_comp_assign_2e.f90:7) ==3173==by 0x8048938: main (fmain.c:22) [...] In addition, while reducing this, I saw different kinds of other errors, most notably unnecessary free's and leaking memory. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-05 14:31:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #2 from pcarlini at suse dot de 2007-07-05 14:37 --- Let's add Hans-Peter in CC... I suspect adding an 'else if [info exists env(RANLIB)]...' could do the job... Hans-Peter? -- pcarlini at suse dot de changed: What|Removed |Added CC||hp at bitrange dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug fortran/32633] bogus error
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-05 14:56 ---
Haven't updated yet, but ...
symbol.c(check_conflict):493:
[...]
switch (attr->flavor)
case FL_PARAMETER:
conf2 (save);
[...]
with
#define conf2(a) if (attr->a) { a2 = a; goto conflict; }
should probably be
if (attr->flavor == FL_PARAMETER && attr->save == SAVE_EXPLICIT)
instead.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-05 14:57:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug target/32605] massive moves instead of bswap{l,q}
--- Comment #1 from pluto at agmk dot net 2007-07-05 15:22 ---
it would be nice to see bswap variants instead of mov,mov,mov,...
:
mov(%rdi),%eax
bswap %eax
mov%eax,(%rdi)
retq
:
mov(%rdi),%rax
bswap %rax
mov%rax,(%rdi)
retq
and one more thing. the 4.2 produces better code than 4.3:
4.2:
void reverse(T&) [with T = size_t] (t)
{
unsigned char & __b.235;
unsigned char & __b.234;
unsigned char & __b.233;
unsigned char __tmp.232;
unsigned char __tmp.231;
unsigned char __tmp.230;
unsigned char * bytes.226;
unsigned char * bytes.225;
unsigned char * bytes.224;
unsigned char & __b;
unsigned char __tmp;
unsigned char * bytes;
:
bytes = (unsigned char *) t;
__b.233 = bytes + 8B - 1B;
__tmp.230 = *bytes;
*bytes = *__b.233;
*__b.233 = __tmp.230;
bytes.224 = bytes + 1B;
__b = __b.233 - 1B;
__tmp = *bytes.224;
*bytes.224 = *__b;
*__b = __tmp;
bytes.225 = bytes.224 + 1B;
__b.235 = __b - 1B;
__tmp.232 = *bytes.225;
*bytes.225 = *__b.235;
*__b.235 = __tmp.232;
bytes.226 = bytes.225 + 1B;
__b.234 = __b.235 - 1B;
__tmp.231 = *bytes.226;
*bytes.226 = *__b.234;
*__b.234 = __tmp.231;
return;
}
4.3:
_ForwardIterator2 std::swap_ranges(_ForwardIterator1,
_ForwardIterator1, _ForwardIterator2)
[with _ForwardIterator1 = unsigned char*,
_ForwardIterator2 = std::reverse_iterator]
(__first1, __last1, __first2)
{
long unsigned int D.25754;
struct reverse_iterator D.25507;
:
if (__first1 != __last1)
goto ;
else
goto ;
:
D.25507.current = __first2->current;
iter_swap (__first1, &D.25507);
D.25754 = (long unsigned int) __first1 + 1;
__first1 = (unsigned char *) D.25754;
__first2->current = __first2->current + 0x;
if (__first1 != __last1)
goto ;
else
goto ;
:
->current = __first2->current;
return ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32605
[Bug fortran/32633] bogus error
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-05 15:09 ---
The patch below fixes the current problem. There are other checks against
attrib->save in check_conflict() which might trigger the same problem. I'll
have a closer later this evening.
Index: symbol.c
===
--- symbol.c(revision 126369)
+++ symbol.c(working copy)
@@ -630,12 +630,17 @@
conf2 (target);
conf2 (dummy);
conf2 (in_common);
- conf2 (save);
conf2 (value);
conf2 (volatile_);
conf2 (threadprivate);
/* TODO: hmm, double check this. */
conf2 (value);
+
+ if (attr->save == SAVE_EXPLICIT)
+ {
+ a2 = save;
+ goto conflict;
+ }
break;
default:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #3 from hp at gcc dot gnu dot org 2007-07-05 15:01 --- I'm not the one adding the ranlib invocation, just the one last touching it, see for example also PR30675. Don't check for RANLIB, it's for the host and we're testing for the target. The framework in this case the toplevel, is responsible for passing a RANLIB_FOR_TARGET. There's the bug, IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug fortran/32633] bogus error
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-05 15:03 --- Testing patch ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-05 14:57:01 |2007-07-05 15:03:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #4 from pcarlini at suse dot de 2007-07-05 15:04 --- Thanks Hans-Peter. Are you willing to investigate this issue further? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-05 15:19 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib pcarlini at suse dot de writes: > Let's add Hans-Peter in CC... I suspect adding an 'else if [info exists > env(RANLIB)]...' could do the job... Hans-Peter? Unfortunately, this won't do: on IRIX 5, we have RANLIB=:, which is a shell builtin. When I tried a make check with RANLIB_FOR_TARGET=:, this failed with (I think) `command not found'. We'd have to make sure that RANLIB is set to e.g. true, i.e. an external command. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug fortran/32634] New: renamed, use associated generic interface rejected
The code below incorrectly gives the error, as reported by Salvatore Filippone: Call foo_pwrk(pr,p,f,cd,info,work=aux) 1 Error: There is no specific subroutine for the generic 'bar_pwrk' at (1) Not only does it look correct but other compilers handle it OK. module.c is not finding the "true name" symbol, even though it has been created with the "use name" symtree. A quick inspection of the .mod file reveals that the interface is given the true name, which simply is not findable by read_module. Paul module foo_base_mod type foo_dmt real(kind(1.d0)), allocatable :: rv(:) integer, allocatable :: iv1(:), iv2(:) end type foo_dmt type foo_zmt complex(kind(1.d0)), allocatable :: rv(:) integer, allocatable :: iv1(:), iv2(:) end type foo_zmt type foo_cdt integer, allocatable :: md(:) integer, allocatable :: hi(:), ei(:) end type foo_cdt end module foo_base_mod module bar_prt use foo_base_mod, only : foo_dmt, foo_zmt, foo_cdt type bar_dbprt type(foo_dmt), allocatable :: av(:) real(kind(1.d0)), allocatable :: d(:) type(foo_cdt):: cd end type bar_dbprt type bar_dprt type(bar_dbprt), allocatable :: bpv(:) end type bar_dprt type bar_zbprt type(foo_zmt), allocatable :: av(:) complex(kind(1.d0)), allocatable :: d(:) type(foo_cdt):: cd end type bar_zbprt type bar_zprt type(bar_zbprt), allocatable :: bpv(:) end type bar_zprt end module bar_prt module bar_pr_mod use bar_prt interface bar_pwrk subroutine bar_dppwrk(pr,x,y,cd,info,trans,work) use foo_base_mod use bar_prt type(foo_cdt),intent(in):: cd type(bar_dprt), intent(in) :: pr real(kind(0.d0)),intent(inout):: x(:), y(:) integer, intent(out) :: info character(len=1), optional:: trans real(kind(0.d0)),intent(inout), optional, target :: work(:) end subroutine bar_dppwrk subroutine bar_zppwrk(pr,x,y,cd,info,trans,work) use foo_base_mod use bar_prt type(foo_cdt),intent(in):: cd type(bar_zprt), intent(in) :: pr complex(kind(0.d0)),intent(inout) :: x(:), y(:) integer, intent(out) :: info character(len=1), optional:: trans complex(kind(0.d0)),intent(inout), optional, target :: work(:) end subroutine bar_zppwrk end interface end module bar_pr_mod module foo_pr_mod use bar_prt, & & foo_dbprt => bar_dbprt,& & foo_zbprt => bar_zbprt,& & foo_dprt => bar_dprt,& & foo_zprt => bar_zprt use bar_pr_mod, & & foo_pwrk => bar_pwrk end module foo_pr_mod Subroutine foo_sub(a,pr,b,x,eps,cd,info) use foo_base_mod use foo_pr_mod Implicit None !!$ parameters Type(foo_dmt), Intent(in) :: a Type(foo_dprt), Intent(in) :: pr Type(foo_cdt), Intent(in):: cd Real(Kind(1.d0)), Intent(in) :: b(:) Real(Kind(1.d0)), Intent(inout):: x(:) Real(Kind(1.d0)), Intent(in) :: eps integer, intent(out) :: info !!$ Local data Real(Kind(1.d0)), allocatable, target :: aux(:),wwrk(:,:) Real(Kind(1.d0)), allocatable :: p(:), f(:) info = 0 Call foo_pwrk(pr,p,f,cd,info,work=aux) return End Subroutine foo_sub -- Summary: renamed, use associated generic interface rejected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32634
[Bug fortran/32634] renamed, use associated generic interface rejected
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-05 15:24 ---
This fixes it but is, as yet, unregtested:
Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(revision 126317)
--- gcc/fortran/module.c(working copy)
*** write_operator (gfc_user_op *uop)
*** 3943,3948
--- 3943,3951
static void
write_generic (gfc_symbol *sym)
{
+ const char *p;
+ int nuse, j;
+
if (sym->generic == NULL
|| !gfc_check_access (sym->attr.access, sym->ns->default_access))
return;
*** write_generic (gfc_symbol *sym)
*** 3950,3956
if (sym->module == NULL)
sym->module = gfc_get_string (module_name);
! mio_symbol_interface (&sym->name, &sym->module, &sym->generic);
}
--- 3953,3971
if (sym->module == NULL)
sym->module = gfc_get_string (module_name);
! /* See how many use names there are. If none, go through the start
!of the loop at least once. */
! nuse = number_use_names (sym->name);
! if (nuse == 0)
! nuse = 1;
!
! for (j = 1; j <= nuse; j++)
! {
! /* Get the jth local name for this symbol. */
! p = find_use_name_n (sym->name, &j);
!
! mio_symbol_interface (&p, &sym->module, &sym->generic);
! }
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32634
[Bug fortran/32635] New: gfortran - internal compiler error: verify_ssa failed
This error poped up while trying to recompile one of my programs. I have reduced it about as much as I could - change almost anything and the error goes away - [dranta:~/junk] dir% gfortran -c -O2 aled7.F aled7.F: In function 'aled7': aled7.F:1: error: definition in block 6 follows the use for SSA_NAME: D.1023_61 in statement: D.1017_52 = D.1023_61; aled7.F:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [dranta:~/junk] dir% cat aled7.F subroutine aled7(ix,ib,itable,ip,ip2,imat,nummat, 1 mx0,k,numnp,numel,iadj) implicit double precision (a-h,o-z)dp common/cale6/fst(16,4),ist(256,14) c dimension ib(*),itable(*),ip(3,*),ip2(*),ix(6,*),imat(nummat+1,*) c c ipnt=1 do 20 i=1,numel if (imat(ix(5,i),mx0).ne.1) go to 20 20 continue c k=0 kflg=0 25 do 30 i=1,ipnt if (ip(1,i).eq.0) go to 30 ii=i go to 40 30 continue c 40 k=k+1 iel=ip(3,ii) ib(k+iadj)=i1 if (kflg.eq.1) ip(1,ii)=0 kflg=1 c isum=0 do 50 i=1,ipnt if (ip(1,i).eq.0) isum=isum+1 if (ip(1,i).eq.0.or.ip(1,i).ne.i2) go to 50 ii=i if (ip(3,i).eq.iel) go to 40 50 continue c if (ip(1,ii).eq.i2) go to 40 kflg=0 if (isum.ne.ipnt) go to 25 c return end [dranta:~/junk] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070705 (experimental) [dranta:~/junk] dir% -- Summary: gfortran - internal compiler error: verify_ssa failed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: Darwin 8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32635
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2007-07-05 15:42 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib hp at gcc dot gnu dot org writes: > I'm not the one adding the ranlib invocation, just the one last touching it, Indeed: I found that Benjamin first introduced libtestc++.a and the ranlib invokation. > see for example also PR30675. Don't check for RANLIB, it's for the host and > we're testing for the target. I think this is wrong: the toplevel Makefile has, in BASE_TARGET_EXPORTS, RANLIB="$(RANLIB_FOR_TARGET)", so it seems we should check for RANLIB instead of RANLIB_FOR_TARGET. > The framework in this case the toplevel, is responsible for passing a > RANLIB_FOR_TARGET. There's the bug, IMHO. The other problem is that the fallback of : for RANLIB_FOR_TARGET doesn't work with local_exec "$ranlibcommand", while using true is ok. This should be fixed in the toplevel configure.ac (NCN_STRICT_CHECK_TOOLS, ACX_CHECK_INSTALLED_TARGET_TOOL). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug pch/32636] New: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
My autotester flags the following failure as introduced between revisions 126197 and 126206 (people with gcc/ChangeLog entries in this range are CCed; no suspect cp or libstdc++-v3 changes): Running /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 25_algorithms/search_n/iterator.cc (test for excess errors) with this in libstdc++.log: /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h: In function '_ForwardIterator std::__search_n(_ForwardIterator, _ForwardIterator, _Integer, const _Tp&, std::forward_iterator_tag) [with _ForwardIterator = __gnu_test::forward_iterator_wrapper, _Integer = int, _Tp = int]':^M /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h:763: error: definition in block 22 does not dominate use in block 25^M for SSA_NAME: __i$D47460$SharedInfo_40 in statement:^M if (__i$D47460$SharedInfo_40 != D.52134_317)^M /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h:763: internal compiler error: verify_ssa failed^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M The target and host combination is significant; I haven't been able to reproduce this on a x86 system, neither with x86_64-unknown-linux-gnu native. At first sight the bug is generic, but apparently hidden for other combinations. A iterator.ii is (to be) attached, but is likely not as helpful as it's supposed to be, not more than avoiding the "make check" part, as it does not contain the complete context for debugging cc1plus. It instead contains #pragma GCC pch_preprocess "/tmp/hptestregress/obj/cris-elf/libstdc++-v3/include/cris-elf/bits/stdc++.h.gch/O2g.gch" and when configuring with --disable-libstdcxx-pch, the bug is not exposed. With a complete built tree and edited file path on the pch_preprocess line, "cc1plus -melf -fpreprocessed /tmp/iterator.ii -g -O2 -o iterator.s" is sufficient to reproduce the bug. (Actually the -g seems optional which it shouldn't be, but I think that's a separate bug.) Due to the PCH-ness and lack of debug context in iterator.ii, the steps to reproduce are a bit involved, but trivial and the usual ones for a variant of cross-testing: 1. Check out, build and install targetted binutils somewhere: /path/to/src/configure --target=cris-elf --prefix=/where/ever && make all && make install 2. Check out and combine newlib and gcc, for example as per gcc.gnu.org/simtest-howto.html, and make sure gmp and mpfr are accessible (in-tree or installed on the host) 3. Include /where/ever/bin in your PATH 4, Do /path/to/gccandnewlib/configure --target=cris-elf --prefix=/where/ever --enable-languages=c++ 5. Build; "make all" 6. You now have sufficient PCH context; edit the attached iterator.ii adjusting the file path to the just-built O2g.gch and run the cc1plus line as above. -- Summary: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug fortran/32633] bogus error
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-05 16:11 --- (In reply to comment #3) > The patch below fixes the current problem. There are other checks against > attrib->save in check_conflict() which might trigger the same problem. I'll > have a closer later this evening. This patch is OK to commit. Please review all other uses of attr->save (in check_conflict() and possibly in other functions and files) for this type of error. I'm sorry that I wasn't able to spot that possible issue during my review of your patch :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #1 from hp at gcc dot gnu dot org 2007-07-05 16:08 --- Created an attachment (id=13850) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13850&action=view) preprocessed test-case (with significant parts of context missing due to pch) See PR description for the cc1plus command-line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #2 from hp at gcc dot gnu dot org 2007-07-05 16:16 --- There are ready-to-use tarballs (binutils+sim, gcc+newlib+gmp+mpfr) on gcc12:/home/hp for those inclined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug c++/32637] Swedish translation error
--- Comment #1 from ext at sidvind dot com 2007-07-05 16:36 --- Created an attachment (id=13851) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13851&action=view) Translation fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-05 16:32 --- Tobias, good catch :) It seems to be another off-by-one issue. Comparing the tree dumps from different assignments as shown in comment #4, one learns (copied only the relevant lines, between any two adjacent lines any amount of other code was removed): struct a a.0; struct array1_int4 parm.2; parm.2.dim[0].ubound = 3; a.0.i = (struct array1_int4) parm.2; /* ubound == 3 */ a.0.i.dim[0].ubound = a.0.i.dim[0].ubound + 1; /* ubound == 4 (!) */ x = a.0; Adding print *, ubound(x%i, 1), ubound(y%i, 1) to the source gives 4/4 instead of 3/3 as one would expect from the initalizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug c++/32637] New: Swedish translation error
By changing the parameters of the operator delete of a class, the following warning is issued when compiling: include/elpis.h:80: error: 'operator delete' takes type 'void*' as first parameter With LC_ALL set to "sv_SE": include/elpis.h:80: fel: "operator new" tar typen "void*" som första parameter This is just a translation error. First found this in GCC-4.1.2 but this translation is still in trunk. I'll attach a patch that corrects this. -- Summary: Swedish translation error Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ext at sidvind dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #3 from ubizjak at gmail dot com 2007-07-05 17:19 --- (In reply to comment #0) > My autotester flags the following failure as introduced between revisions > 126197 and 126206 (people with gcc/ChangeLog entries in this range are CCed; > no > suspect cp or libstdc++-v3 changes): As -ftree-vectorize is not enabled for this test, I think that r126206 (mine) wasn't the cause for failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug target/32450] -pg causes miscompilation
--- Comment #27 from ubizjak at gmail dot com 2007-07-05 17:11 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00460.html. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||07/msg00460.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug java/32638] New: Wrong selection of field in inner class when outer class and super class have a relevant filed named the same
The following program should print true, but prints false when compiled with
gcj -C because the wrong field o is selected in the anonymous inner class (the
protected field named o in the super class is more specific than the field o in
the enclosing method).
public class t
{
static abstract class a
{
protected Object o = new Object();
abstract void print(Object input);
}
static class b
{
void m()
{
final Object o = new Object();
a x = new a()
{
void print(Object input)
{
System.out.println(o != input);
}
};
x.print(o);
}
}
public static void main(String[] args)
{
new b().m();
}
}
Since this is pretty hard to see why this code works/doesn't work in the first
place (the super class could be in a completely different file and the field in
the outer class certainly looks like it would be the one that is used in the
inner class) a warning for this kind of usage would be nice.
gcj (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
--
Summary: Wrong selection of field in inner class when outer class
and super class have a relevant filed named the same
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32638
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-05 17:51 --- This is related to the gimplifier verifying call expression types to disable inlining. In this case the argument type list says we need struct _Bind, but the actual argument is struct _Bind*. Oh well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug target/32450] -pg causes miscompilation
--- Comment #30 from jv244 at cam dot ac dot uk 2007-07-05 17:52 --- (In reply to comment #29) > (In reply to comment #28) > > > without knowing C to well, don't you need to initialize stack_pointer in the > > testcase you've added to the patch? > > No, written this way it is zero by default. > :-) you might have noticed from my bug reports I'm not a real C programmer... thanks for fixing this bug quickly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug tree-optimization/32635] [4.3 Regression] gfortran - internal compiler error: verify_ssa failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Component|fortran |tree-optimization Keywords||ice-on-valid-code Summary|gfortran - internal compiler|[4.3 Regression] gfortran - |error: verify_ssa failed|internal compiler error: ||verify_ssa failed Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32635
[Bug libgomp/32538] All libgomp tests fail to link on IRIX 6: copysignl undefined
--- Comment #2 from ro at gcc dot gnu dot org 2007-07-05 17:50 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-05 17:50:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug target/32450] -pg causes miscompilation
--- Comment #29 from ubizjak at gmail dot com 2007-07-05 17:42 --- (In reply to comment #28) > without knowing C to well, don't you need to initialize stack_pointer in the > testcase you've added to the patch? No, written this way it is zero by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg causes miscompilation
--- Comment #28 from jv244 at cam dot ac dot uk 2007-07-05 17:35 --- (In reply to comment #27) > Patch at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00460.html. > without knowing C to well, don't you need to initialize stack_pointer in the testcase you've added to the patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2007-07-05 17:31 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib hp at gcc dot gnu dot org writes: > and you'll have to fix the ":" problem separately. > Unless you prefer a 'set ranlib "$env(SHELL) -c $env(RANLIB)"' but that looks > a little bit too gross. Indeed, setting RANLIB to true seems far simpler. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug java/32638] Wrong selection of field in inner class when outer class and super class have a relevant filed named the same
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-05 17:31 --- I tried this with svn trunk and got 'false'. If there is a bug here it is in ecj, not gcj. I'm not sure I agree with your interpretation here. I don't see how specificity applies. Isn't that term only used for overload resolution? It's been a while since I was completely familiar with the JLS, though ... where are you reading? IMO the JLS could be clearer here, but I believe the local 'o' shadows the field a.o. See: http://java.sun.com/docs/books/jls/third_edition/html/names.html#34133 Anyway, I suggest filing against ecj or perhaps the JDK for resolution. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32638
[Bug c++/32639] New: ptrmem1.C now ICE's on mainline
As of this morning (7/5/07), I now get the following ICE from the C++ testsuite of mainline. Note that this test PASSed yesterday (7/4/07). Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20070705/gcc/testsuite/g++/../ ../g++ -B/u01/var/tmp/gcc_trunk_svn/gcc_20070705/gcc/testsuite/g++/../../ /u01/v ar/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C -nostdinc++ -I/u01/ var/tmp/gcc_trunk_svn/gcc_20070705/i386-pc-solaris2.11/libstdc++-v3/include/i386 -pc-solaris2.11 -I/u01/var/tmp/gcc_trunk_svn/gcc_20070705/i386-pc-solaris2.11/li bstdc++-v3/include -I/u01/var/tmp/gcc_trunk_svn/gcc/libstdc++-v3/libsupc++ -I/u0 1/var/tmp/gcc_trunk_svn/gcc/libstdc++-v3/include/backward -I/u01/var/tmp/gcc_tru nk_svn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -S -o ptrmem1.s (timeout = 300) /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C: In function ' void f()': /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C:10: internal c ompiler error: in generate_element_copy, at tree-sra.c:1801 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C: In function ' void f()': /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C:10: internal c ompiler error: in generate_element_copy, at tree-sra.c:1801 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: g++.dg/opt/ptrmem1.C (internal compiler error) FAIL: g++.dg/opt/ptrmem1.C (test for excess errors) Excess errors: /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/g++.dg/opt/ptrmem1.C:10: internal c ompiler error: in generate_element_copy, at tree-sra.c:1801 Brett Albertson -- Summary: ptrmem1.C now ICE's on mainline Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #7 from pluto at agmk dot net 2007-07-05 17:35 --- (In reply to comment #6) > Fixed. Richard, there's a recent regresion in 4.3/r126266: _ZSt9transformIPlS0_NSt3tr15_BindIFSt4plusIlEllT0_T_S8_S7_T1_: cmpq%rsi, %rdi je .L2 addq$8, %rdi movq%rdx, %r9 movq%rdi, %r8 .p2align 4,,10 .p2align 3 .L3: movq8(%rcx), %rax addq16(%rcx), %rax addq$8, %r8 movq%rax, (%r9) leaq-8(%r8), %rax addq$8, %r9 cmpq%rax, %rsi jne .L3 subq%rdi, %rsi shrq$3, %rsi leaq8(%rdx,%rsi,8), %rdx .L2: movq%rdx, %rax ret _Z6assignRll: subq$40, %rsp movq%rdi, %rdx movq%rsi, 8(%rsp) leaq8(%rdi), %rsi movq%rsp, %rcx movq$0, 16(%rsp) call _ZSt9transformIPlS0_NSt3tr15_BindIFSt4plusIlEllT0_T_S8_S7_T1_ addq$40, %rsp ret _Z6assignPll: subq$40, %rsp movq%rdi, %rdx movq%rsi, 8(%rsp) leaq8(%rdi), %rsi movq%rsp, %rcx movq$0, 16(%rsp) call _ZSt9transformIPlS0_NSt3tr15_BindIFSt4plusIlEllT0_T_S8_S7_T1_ addq$40, %rsp ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug libgcj/28190] [4.2/4.3 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-05 18:07 --- This patch works around this problem: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00475.html -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-05 18:07:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28190
[Bug bootstrap/3456] bootstrapping gcc-3.0 with threadmodel=posix fails on IRIX64 6.5
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-05 18:17 --- Working on a patch. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2005-10-02 20:50:58 |2007-07-05 18:17:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3456
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #9 from pluto at agmk dot net 2007-07-05 18:21 --- (In reply to comment #8) > This is related to the gimplifier verifying call expression types to disable > inlining. In this case the argument type list says we need struct _Bind, but > the actual argument is struct _Bind*. Oh well. should i fill a separated PR for this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug fortran/32359] incorrect error: Threadprivate isn't SAVEd (implicit save attribute undefined)
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-05 18:23 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32359
[Bug ada/32640] New: Binding for pthread_sigmask not same as other ports
The Ada run-time has changed its expectation for the prototype of pthread_sigmask. The RTEMS specific file does not compile. This small patch fixes it. 2007-07-05 Joel Sherrill <[EMAIL PROTECTED]> * s-osinte-rtems.ads: Correct prototype of pthread_sigmask. -- Summary: Binding for pthread_sigmask not same as other ports Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at oarcorp dot com GCC build triplet: any GCC host triplet: any GCC target triplet: *-*-*rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug libgomp/32538] All libgomp tests fail to link on IRIX 6: copysignl undefined
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-05 18:00 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00473.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug translation/32637] Swedish translation error
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-05 17:59 --- Translation fixes goto the translation team which is not part of the GCC team really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |translation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #10 from rguenther at suse dot de 2007-07-05 18:29 --- Subject: Re: Fails to tree-combine conditions in COND_EXPRs On Thu, 5 Jul 2007, pluto at agmk dot net wrote: > > > --- Comment #9 from pluto at agmk dot net 2007-07-05 18:21 --- > (In reply to comment #8) > > This is related to the gimplifier verifying call expression types to disable > > inlining. In this case the argument type list says we need struct _Bind, > > but > > the actual argument is struct _Bind*. Oh well. > > should i fill a separated PR for this issue? Yes, that would be nice. richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug java/32638] Wrong selection of field in inner class when outer class and super class have a relevant filed named the same
--- Comment #2 from mark at gcc dot gnu dot org 2007-07-05 18:34 --- Subject: Re: Wrong selection of field in inner class when outer class and super class have a relevant filed named the same > --- Comment #1 from tromey at gcc dot gnu dot org 2007-07-05 17:31 > --- > I tried this with svn trunk and got 'false'. > If there is a bug here it is in ecj, not gcj. Wow, that is interesting. Which ecj version are you using? v_686_R32x, 3.2.2 release gives "true". > I'm not sure I agree with your interpretation here. > I don't see how specificity applies. Isn't that term only used > for overload resolution? It's been a while since I was completely > familiar with the JLS, though ... where are you reading? I am using the completely wrong terms, sorry about that. I got the idea from JLS second edition 8.3 Field Declarations (but admit to not have had it handy when I filed the bug report, it actually took me some time to find it back): http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#40898 If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in superclasses, and superinterfaces of the class. The field declaration also shadows (§6.3.1) declarations of any accessible fields in enclosing classes or interfaces, and any local variables, formal method parameters, and exception handler parameters with the same name in any enclosing blocks. If a field declaration hides the declaration of another field, the two fields need not have the same type. A class inherits from its direct superclass and direct superinterfaces all the non-private fields of the superclass and superinterfaces that are both accessible to code in the class and not hidden by a declaration in the class. Since it mentions that the field declaration shadows the local variables of the enclosing block (the method) and not the enclosing class and that it inherits the fields (which I take to mean also shadows) I believe my interpretation is correct. > IMO the JLS could be clearer here, but I believe the local 'o' > shadows the field a.o. See: > > http://java.sun.com/docs/books/jls/third_edition/html/names.html#34133 > > Anyway, I suggest filing against ecj or perhaps the JDK for resolution. Yeah, it certainly is confusing. I need all my language lawyer skills to even defend my bug report :) All I really want is a big fat warning from the compiler for this type of usage because it clearly is something that takes a long debate to even see who is right and why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32638
[Bug ada/32640] Binding for pthread_sigmask not same as other ports
--- Comment #1 from joel at oarcorp dot com 2007-07-05 18:30 --- Created an attachment (id=13853) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13853&action=view) Patch to make this file compile With this patch, I have been able to successfully compile GNAT for 7 target architectures supported by RTEMS, run the ACATS on two of them and an Ada hello world on most of them. Could someone please apply this to the head and 4.2 branch before 4.2.1 freezes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug libgcj/28190] [4.2/4.3 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-05 18:43 --- Subject: Bug 28190 Author: ro Date: Thu Jul 5 18:43:16 2007 New Revision: 126377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126377 Log: PR libgcj/28190 * inclhack.def (irix_stdint_c99): New fix. * fixincl.x: Regenerate. * tests/base/stdint.h: New test. Added: trunk/fixincludes/tests/base/stdint.h Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28190
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-05 18:48 --- >:0: error: nonnull argument references non-pointer operand (argument >1, operand 1) That means we are miscompiling some part of cc1 somewhere. Which I doubt is a pointer plus issue because I have gotten no bug reports of wrong code yet. It might be a df issue. Can roll back, right before pointer plus and try bootstrapping there? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||build, wrong-code Last reconfirmed|-00-00 00:00:00 |2007-07-05 18:48:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug tree-optimization/32631] internal compiler error: in generate_element_copy, at tree-sra.c:1801
--- Comment #2 from ubizjak at gmail dot com 2007-07-05 18:55 --- Duplicate of 32639. *** This bug has been marked as a duplicate of 32639 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32631
[Bug c++/32639] ptrmem1.C now ICE's on mainline
--- Comment #2 from ubizjak at gmail dot com 2007-07-05 18:55 --- *** Bug 32631 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug c++/32639] ptrmem1.C now ICE's on mainline
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-05 18:50 --- Confirmed. This is caused by r126326, somehow I didn't notice this during testing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-05 18:50:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-05 19:02 ---
This patch works for me:
Index: fold-const.c
===
--- fold-const.c(revision 126338)
+++ fold-const.c(working copy)
@@ -282,14 +282,8 @@
HOST_WIDE_INT high, int overflowable,
bool overflowed)
{
- int sign_extended_type;
bool overflow;
- /* Size types *are* sign extended. */
- sign_extended_type = (!TYPE_UNSIGNED (type)
- || (TREE_CODE (type) == INTEGER_TYPE
- && TYPE_IS_SIZETYPE (type)));
-
overflow = fit_double_type (low, high, &low, &high, type);
/* If we need to set overflow flags, return a new unshared node. */
@@ -297,7 +291,7 @@
{
if (overflowed
|| overflowable < 0
- || (overflowable > 0 && sign_extended_type))
+ || (overflowable > 0 && !TYPE_UNSIGNED (type)))
{
tree t = make_node (INTEGER_CST);
TREE_INT_CST_LOW (t) = low;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
[Bug c++/32639] ptrmem1.C now ICE's on mainline
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-05 19:06 --- We compare two pointer-to-method types that "look" the same: Breakpoint 3, useless_type_conversion_p (outer_type=0xb7d869b4, inner_type=0xb7d866c0) at /home/richard/src/trunk2/gcc/tree-ssa.c:917 917 inner_type = TYPE_MAIN_VARIANT (inner_type); QWidget:: * QWidget:: * (gdb) call debug_tree (outer_type) > QI size unit size align 8 symtab 0 alias set -1 canonical type 0xb7d86438 method basetype arg-types chain value chain >>> pointer_to_this > unsigned SI size constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 canonical type 0xb7d866c0> (gdb) call debug_tree (inner_type) > QI size unit size align 8 symtab 0 alias set -1 canonical type 0xb7d86438 method basetype arg-types chain chain >>> pointer_to_this > sizes-gimplified unsigned SI size constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 canonical type 0xb7d866c0> (note they have the same canonical types, for both the pointer and the pointed-to type. note they both have their alias set not computed.) Now at the point we verify if those pointer types are compatible we check /* Do not lose casts between pointers with different TYPE_REF_CAN_ALIAS_ALL setting or alias sets. */ if ((TYPE_REF_CAN_ALIAS_ALL (inner_type) != TYPE_REF_CAN_ALIAS_ALL (outer_type)) || (get_alias_set (TREE_TYPE (inner_type)) != get_alias_set (TREE_TYPE (outer_type return false; which calls get_alias_set on both pointed-to types which (surprisingly?) returns 2 for one and 3 for the other one. Because, while we specialize FUNCTION_TYPE /* There are no objects of FUNCTION_TYPE, so there's no point in using up an alias set for them. (There are, of course, pointers and references to functions, but that's different.) */ else if (TREE_CODE (t) == FUNCTION_TYPE) set = 0; we do not so for METHOD_TYPE, which looks like an omission. Also it looks like in useless_type_conversion_p we can move the canonical types check to the top and use it for all types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug libstdc++/31906] "-Xcompiler" is inserted after "-Xlinker" when building libstdc++
--- Comment #6 from prj-bugzilla-gcc at multivac dot cwru dot edu 2007-07-05 19:23 --- I've found the problem. The libtool-ldflags script inserts -Xcompiler for any argument starting with "-f" or "--", even if that argument was already quoted with -Xlinker/-Xcompiler/-Xpreprocessor. I'll work on a patch tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug libstdc++/31906] "-Xcompiler" is inserted after "-Xlinker" when building libstdc++
--- Comment #7 from pcarlini at suse dot de 2007-07-05 19:46 --- Great. Thanks a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #8 from bonzini at gnu dot org 2007-07-05 20:03 --- Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile Sebastian Pop wrote: > Hi, > > here is a fix for PR32622 that I've bootstrapped and tested on > i686-linux with "configure BOOT_CFLAGS=-O2" that made the bootstrap > stage2 and stage3 use "-O2 -fomit-frame-pointer" instead of "-O2 -g > -fomit-frame-pointer". Okay for trunk? Ok. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug c++/31992] [4.1/4.2/4.3 regression] ICE initializing static variable of template class
--- Comment #1 from brolley at redhat dot com 2007-07-05 20:05 --- I've worked on this a bit and just realized that it's assigned to Mark Mitchell. However, here's what I've learned, in case it helps... The segfault occurs in convert_for_initialization because the TREE_TYPE of rhs is NULL_TREE. This is because the tree is a SCOPE_REF referring to A and i. The TREE_TYPE was set to NULL_TREE because A is a dependent type. Now, it's documented in build_qualified_name in cp/tree.c that a SCOPE_REF has NULL type in the event that the expression represents a dependent type. However, since i does not depend on any of the template parameters of A, I think that A::i is not a dependent type and that the TREE_TYPE should have been set to the type of i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #22 from bonzini at gnu dot org 2007-07-05 20:11 --- The patch does not fix this one, which also works in 3.3 and fails in 4.1. I'm not sure it's 100% the same bug. Still, I committed the patch to fix the testcase from PR21291. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-07-05 20:25 --- I have a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #9 from spop at gcc dot gnu dot org 2007-07-05 20:26 --- Subject: Bug 32622 Author: spop Date: Thu Jul 5 20:26:10 2007 New Revision: 126386 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126386 Log: PR bootstrap/32622 * config/mh-x86omitfp (BOOT_CFLAGS): Add -fomit-frame-pointer, don't reset its value. Modified: trunk/ChangeLog trunk/config/mh-x86omitfp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug ada/32640] [Ada] [4.2 Regression] Binding for pthread_sigmask not same as other ports
--- Comment #2 from laurent at guerby dot net 2007-07-05 20:36 --- This was working with 4.1 -- laurent at guerby dot net changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org, charlet at gcc dot gnu ||dot org Summary|Binding for pthread_sigmask |[Ada] [4.2 Regression] |not same as other ports |Binding for pthread_sigmask ||not same as other ports http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #10 from spop at gcc dot gnu dot org 2007-07-05 20:55 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug fortran/32633] bogus error
--- Comment #5 from patchapp at dberlin dot org 2007-07-05 21:15 --- Subject: Bug number PR32633 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00511.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32633
[Bug c++/32639] ptrmem1.C now ICE's on mainline
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-05 21:21 --- Subject: Bug 32639 Author: rguenth Date: Thu Jul 5 21:21:10 2007 New Revision: 126389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126389 Log: 2007-07-05 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/32639 * alias.c (get_alias_set): Tread METHOD_TYPE the same as FUNCTION_TYPE. * tree-ssa.c (useless_type_conversion_p): Check canonical types early. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug c++/32639] ptrmem1.C now ICE's on mainline
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-05 21:21 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32639
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-05 21:57 --- > This patch works for me: Well, that sizetypes are sign-extended is assumed in other places too. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
