[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-24 07:03 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #6 from steven at gcc dot gnu dot org 2007-08-24 07:10 --- Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on gcc-patches and in this PR when I've made it pretty damn clear that I don't want to work on gcc anymore... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-24 07:40 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug middle-end/32946] [4.3 Regression] ICE with -fpredictive-commoning in build_classic_dist_vector_1
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-24 07:42 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32946
[Bug tree-optimization/32733] [4.3 regression] error: definition in block 11 does not dominate use in block 12
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-08-24 08:48 --- As per comment #6. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-24 09:23 --- MIPS-linux uses elf which has weak support. So I don't see why you think GTHREAD_USE_WEAK should not be defined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug inline-asm/33171] GCC outputs invalid assembly when using -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-24 09:02 ---
No, the inline-asm is just wrong, you need to use a different thing for
including non indexed load/stores.
The inline-asm function should be written as:
static inline unsigned long
load_acquire(volatile unsigned long *addr)
{
unsigned long result;
__asm__ __volatile__ (
"lwz%X1 %0,%1\n"
"cmpw cr7,%0,%0\n"
"bne- cr7,1f\n"
"1: isync\n"
: "=r" (result)
: "m"(*addr) : "memory", "cc");
return result;
}
Though I will make a mention this is not really atomic at all. You need to use
lwarx/stwcx to be atomic. Also lwsync should be used instead of isync (IIRC).
--
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=33171
[Bug web/16024] Document use of relative path to ${srcdir}/configure when using MSYS
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-24 10:20
---
Since this one seems to be a documentation issue, I'll take it. I intend to
write a *-*-mingw32 entry to the target-specific installation notes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|SUSPENDED |ASSIGNED
Component|bootstrap |web
GCC target triplet|i386-pc-elf |
Keywords||documentation
Last reconfirmed|2005-07-15 22:33:02 |2007-08-24 10:20:53
date||
Summary|gengtype crashes with mingw |Document use of relative
|and c++ extension |path to ${srcdir}/configure
||when using MSYS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16024
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #8 from uros at gcc dot gnu dot org 2007-08-24 10:58 --- Subject: Bug 33157 Author: uros Date: Fri Aug 24 10:58:12 2007 New Revision: 127766 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127766 Log: PR middle-end/33157 * ifcvt.c (noce_find_if_block): Do not clear if_info.cond_earliest field when initializing if_info structure. Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #7 from ubizjak at gmail dot com 2007-08-24 10:42 --- Sometimes it is neccessary to check where you clear a structure. Attached patch fixes this PR. Index: ifcvt.c === --- ifcvt.c (revision 127761) +++ ifcvt.c (working copy) @@ -2650,6 +2650,7 @@ noce_find_if_block (basic_block test_bb, basic_block then_bb, else_bb, join_bb; bool then_else_reversed = false; rtx jump, cond; + rtx cond_earliest; struct noce_if_info if_info; /* We only ever should get here before reload. */ @@ -2725,7 +2726,7 @@ noce_find_if_block (basic_block test_bb, /* If this is not a standard conditional jump, we can't parse it. */ cond = noce_get_condition (jump, -&if_info.cond_earliest, +&cond_earliest, then_else_reversed); if (!cond) return FALSE; @@ -2741,6 +2742,7 @@ noce_find_if_block (basic_block test_bb, if_info.else_bb = else_bb; if_info.join_bb = join_bb; if_info.cond = cond; + if_info.cond_earliest = cond_earliest; if_info.jump = jump; if_info.then_else_reversed = then_else_reversed; -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-23 10:28:09 |2007-08-24 10:42:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #9 from ubizjak at gmail dot com 2007-08-24 11:06 --- (In reply to comment #6) > Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on > gcc-patches and in this PR when I've made it pretty damn clear that I don't > want to work on gcc anymore... Sorry to hear this. Anyway, I have fixed this for you. Uros. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug rtl-optimization/33172] New: Optimizer fails to elid away unreferenced static function
Background:
===
In the Linux kernel one often sees the following idiom:
static void foo_func(void)
{
}
static struct foo_type foo_struct = {
.foo_call = foo_func,
};
some_init_func(...)
{
register_foo(&foo_struct);
}
some_exit_func(...)
{
unregister_foo(&foo_struct);
}
The point is that {un}register_foo() may be a configuration-dependent
functions that may either be externally-implemented-in-another-module
or, if that configuration item is turned off, resolve to empty stubs
defined in a header itself. [ The empty stubs may be do-nothing macros,
or often static inline functions with empty bodies. ]
The expectation is that, when defined as empty stubs, because there is
effectively no reference left to the static foo_struct and, transitively,
to the static foo_func, the optimizer must just optimize them away
completely.
Problem:
The expectation holds true, when the empty stubs are defined as empty
do {} while (0); macros, but not if defined as empty "static inline
int ... {return 0;}" functions.
Testcase:
=
I think the below (with given commentary) is self-explanatory:
/* gcc -Wall -Os -S */
struct abc {
void (*abc_call)(void);
};
/*
* Use only any one of the three definitions below at a time:
*
* 1. nothing optimized away. Good.
* 2. call_func() _not_ optimized away, but struct xyz is. gcc disappoints.
* 3. both call_func() and struct xyz optimized away. Nice.
*/
/* 1 */
/*extern int do_register(struct abc *xyz);*/
/* 2 */
static inline int do_register(struct abc *xyz)
{
return 0;
}
/* 3 */
/*#define do_register(xyz) do { (void)(xyz); } while (0)*/
static void call_func(void)
{
}
static struct abc xyz = {
.abc_call = call_func,
};
void func(void)
{
do_register(&xyz);
}
Assembler for problematic case:
===
.file "xyz.c"
.text
.type call_func, @function
call_func:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size call_func, .-call_func
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size func, .-func
.ident "GCC: (GNU) 4.1.1 20070105 (Red Hat 4.1.1-51)"
.section.note.GNU-stack,"",@progbits
As you can see, there is nobody referencing the static call_func()
in this object file, and being static, there can be none in others
either. Why did we fail to just elid it away completely?
[ Interestingly, the equally-unreferenced static struct xyz _did_
get elided away. But not so the static function. ]
--
Summary: Optimizer fails to elid away unreferenced static
function
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyam at infradead dot org
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33172
[Bug tree-optimization/33173] New: [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704
I see the following error with trunk from 20070820: (sid)28233:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O -c tor-test.c tor-test.c: In function 'test_dir_format': tor-test.c:16: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4704 Please submit a full bug report, -- Summary: [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa- structalias.c:4704 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704
--- Comment #1 from tbm at cyrius dot com 2007-08-24 12:22 --- Created an attachment (id=14100) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14100&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704
--- Comment #2 from tbm at cyrius dot com 2007-08-24 12:24 --- Works with 20070811. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
[Bug target/18353] ICE with "movaps" in inline asm when using -masm=intel
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:43 --- ICE still there, not mingw specific. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 |i386 Keywords||ice-on-invalid-code Known to fail||3.3.3 3.4.3 4.0.0 4.1.0 ||4.2.0 4.3.0 Last reconfirmed|2006-02-26 19:13:03 |2007-08-24 12:43:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18353
[Bug tree-optimization/33158] missed store sinking opportunity
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 12:44 --- It also naturally would fit in the phiopt framework given the structure of virtual operands: # SMT.4_26 = VDEF *D.2016_7 = D.2019_13; if (D.2019_13 == 3) goto ; else goto ; : goto ; : # SMT.4_27 = VDEF *D.2016_7 = 1; : # SMT.4_22 = PHI -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33158
[Bug libfortran/23138] [mingw32] real(16) values are printed incorrectly
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:46 --- Fixed on mainline. -- fxcoudert 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=23138
[Bug fortran/33174] Testsuite: unexpected failures
--- Comment #1 from dir at lanl dot gov 2007-08-24 12:46 --- Created an attachment (id=14101) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14101&action=view) testsuite output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug fortran/33175] New: Testsuite: unexpected failures
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were found - === gcc Summary === # of expected passes47388 # of unexpected failures60 # of unexpected successes 1 # of expected failures 140 # of unresolved testcases 2 # of untested testcases 42 # of unsupported tests 433 === gfortran Summary === # of expected passes19496 # of unexpected failures1 # of expected failures 9 # of unsupported tests 86 -- Summary: Testsuite: unexpected failures Product: gcc Version: 4.2.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: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33175
[Bug target/28629] [4.1] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:53 --- Also works on mainline (4.3). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 4.3.0 Summary|Segfault with --|[4.1] Segfault with -- |march=pentium-m -O2 when|march=pentium-m -O2 when |compiling faac |compiling faac http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug target/26401] [4.1] x264 revision 439 make fprofiled fails
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:31 --- This is still working fine. mingw development is focusing on 4.3, so this bug probably stands little chance of being fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 GCC build triplet|gcc-4.2-20060218|i686-pc-mingw32 GCC host triplet|windows xp win32/mingw |i686-pc-mingw32 GCC target triplet|win32 |i686-pc-mingw32 Known to work|4.3.0 |4.3.0 4.0.1 Last reconfirmed|-00-00 00:00:00 |2007-08-24 12:31:02 date|| Summary|x264 revision 439 make |[4.1] x264 revision 439 make |fprofiled fails |fprofiled fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26401
[Bug fortran/33174] New: Testsuite: unexpected failures
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were found - === gcc Summary === # of expected passes47388 # of unexpected failures60 # of unexpected successes 1 # of expected failures 140 # of unresolved testcases 2 # of untested testcases 42 # of unsupported tests 433 === gfortran Summary === # of expected passes19496 # of unexpected failures1 # of expected failures 9 # of unsupported tests 86 -- Summary: Testsuite: unexpected failures Product: gcc Version: 4.2.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: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug other/27043] building Ada rts does not find 'as'
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:56 --- Same kind of thing happens for ld, see PR24382. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24382 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27043
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-08-24
13:28 ---
Created an attachment (id=14102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14102&action=view)
Another testcase displaying the said behaviour
IMHO, the code generated for the following can benefit from Strength reduction.
It will be possible to generate post_inc due to strength reduction.
for (dp = i = 0; i < c; i++) {
dp += a[i] * b[i];
}
The RTL code generated for the loop is of the form ( numbers represent pseudo
reg numbers)
137 and 136 hold the base addresses of the two arrays before entry into the
loop.
132 = 0 ; #i,
133 = 132 ; #dp
Label:
139 = *(137 + 132)
140 = *(136 + 132)
141 = 140 * 139
133 += 141 ;#dp
132 += 2
conditional_jump back to Label.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug debug/33044] Local variables in C++ constructor not visible for debugging
--- Comment #5 from nikolay at totalviewtech dot com 2007-08-24 13:15 --- This is not fixed neither in 4.1.0 nor in any later version. The problem is that DIE for static foofoo was indeed produced, but produced in wrong place. <2><260>: Abbrev Number: 7 (DW_TAG_subprogram) --- Constructor declaration DW_AT_external: 1 DW_AT_name: A DW_AT_decl_file : 1 DW_AT_decl_line : 16 DW_AT_declaration : 1 <1><27f>: Abbrev Number: 10 (DW_TAG_subprogram) --- Broken declaration DW_AT_sibling : <2bc> DW_AT_specification: <260> DW_AT_decl_line : 22 DW_AT_inline : 0 (not inlined) . <2><2a7>: Abbrev Number: 13 (DW_TAG_variable)- this is where foofoo was emited DW_AT_name: foofoo DW_AT_decl_file : 1 DW_AT_decl_line : 28 DW_AT_type: <3a1> DW_AT_location: 5 byte block: 3 c0 86 4 8 (DW_OP_addr: 80486c0) <1><2c1>: Abbrev Number: 15 (DW_TAG_subprogram) -- real constructor declaration DW_AT_sibling : <2fd> DW_AT_abstract_origin: <27f> DW_AT_low_pc : 0x8048474 DW_AT_high_pc : 0x80484ed DW_AT_frame_base : 0 (location list) <2><2ee>: Abbrev Number: 17 (DW_TAG_lexical_block) -- this is the scope, where foo and all other variables should be defined. DW_AT_low_pc : 0x8048495 DW_AT_high_pc : 0x80484eb <3><2f7>: Abbrev Number: 18 (DW_TAG_variable) --- this is supposed to be "iii" DW_AT_location: 2 byte block: 91 74(DW_OP_fbreg: -12) - So dwarf producer is clearly confused and emits static foofoo in wrong broken subprogram declaration. Instead it should emit it inside lexical block <2ee> -- nikolay at totalviewtech dot com changed: What|Removed |Added CC||nikolay at totalviewtech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug target/31636] [4.2] ICE in GCC 4.2 with dllimport attribute returns
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 13:07 --- As indicated in PR29826, this bug was fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.0 Resolution||FIXED Summary|ICE in GCC 4.2 with |[4.2] ICE in GCC 4.2 with |dllimport attribute returns |dllimport attribute returns Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-24 13:11 ---
Shorter testcase, fails at -O:
static void ConvertAddr (char *saddr, void **addr)
{
*addr = (void *) &saddr;
}
void DefineSelf (char *addr)
{
ConvertAddr (addr, (void **) &addr);
if (addr[0] == 127 && addr[3] == 1)
;
}
this is a type problem. Before forwprop2 we have
char * saddr;
char D.2013;
:
addr_1 = addr_7(D);
saddr = addr_1;
addr_10 = &saddr;
addr_2 = addr_10;
D.2013_3 = *addr_2;
return;
note that
addr_10 = &saddr;
misses a cast. It's an assignment from char** to char*.
--
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|NEW |ASSIGNED
Last reconfirmed|2007-08-23 20:59:20 |2007-08-24 13:11:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug c++/33176] New: strange diagnostic
The code:
template
bool confirm(T t, int i) { return t == i; }
int main() {
int i = 0, j = 1, k = 2;
if (i == j) && confirm(j, k) ) { i = 2; }
return 0;
}
gets you:
~/ootbc/sim/src$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: expected `;' before '(' token
foo.cc:5: error: label 'confirm' used but not defined
The actual problem is an extra ")" after "i == j", with nary a label anywhere.
--
Summary: strange diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-24 13:59 --- I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug debug/33044] Local static variable in C++ constructor not visible for debugging
--- Comment #6 from seppo at totalviewtech dot com 2007-08-24 13:52 --- Hi Andrew, Reopened the bug (see comment above). Do also notice that the (due to the above) static foofoo inside constructor is still not visible to either TV or gdb. I have changed the title of the bug to reflect that we are only concerned of static variable in this bug report (the gzz-bug #27574 covers the non-static case). Thanks, Seppo -- seppo at totalviewtech dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Summary|Local variables in C++ |Local static variable in C++ |constructor not visible for |constructor not visible for |debugging |debugging http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-24 14:14 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-24 14:14:11 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
[Bug rtl-optimization/33172] Optimizer fails to elid away unreferenced static function
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 14:13 --- Confirmed. Only after early inlining we know enough to do this, but the decision is already made before it seems. Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-08-24 14:13:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33172
[Bug tree-optimization/33158] missed store sinking opportunity
--- Comment #2 from paolo dot bonzini at lu dot unisi dot ch 2007-08-24 14:53 --- Subject: Re: missed store sinking opportunity Danny said he knows how to fix it (I guess in store sinking though he didn't say). From knowing him, there might be additional less obvious cases that this fix might optimize, and that would not be optimized by phiopt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33158
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #4 from patchapp at dberlin dot org 2007-08-24 14:46 --- Subject: Bug number PR33139 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-08/msg01651.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 14:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|ia64-linux-gnu | GCC target triplet||ia64-linux-gnu Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-08-24 14:37:01 date|| Summary|Runtime failure in SPEC |[4.3 Regression] Runtime |CPU2000 benchmark fma3d and |failure in SPEC CPU2000 |applu |benchmark fma3d and applu Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-24 15:03 --- FIXED for gfortran 4.3.0. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-22 11:23:33 |2007-08-24 15:03:54 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04 --- I said: 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=33139
[Bug fortran/33175] Testsuite: unexpected failures
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-24 15:05 --- *** This bug has been marked as a duplicate of 33174 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33175
[Bug fortran/33174] Testsuite: unexpected failures
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-24 15:05 --- *** Bug 33175 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-24 15:09 --- Subject: Bug 33166 Author: rguenth Date: Fri Aug 24 15:09:10 2007 New Revision: 127771 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127771 Log: 2007-08-24 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/33166 * tree-ssa.c (useless_type_conversion_p): Split into a recursive and a non-recursive part. (useless_type_conversion_p_1): New function. * tree-ssa-ccp.c (fold_stmt_r): Make sure that the result from maybe_fold_offset_to_reference is trivially convertible to the desired type before doing the simplification. * gcc.c-torture/compile/pr33166.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr33166.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-24 15:18 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-24 15:01 --- Subject: Bug 33139 Author: burnus Date: Fri Aug 24 15:00:59 2007 New Revision: 127770 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127770 Log: 2007-08-24 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33139 * trans-array.c (gfc_conv_expr_descriptor): Copy bounds for whole-array pointer assignments. 2007-08-24 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33139 * gfortran.dg/pointer_assign_4.f90: New. * gfortran.dg/shape_2.f90: Fix test case. * gfortran.dg/char_result_4.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_4.f90 trunk/gcc/testsuite/gfortran.dg/shape_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #20 from jakub at gcc dot gnu dot org 2007-08-24 15:38 ---
Created an attachment (id=14103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
gcc43-pr33136.patch
Here is what I have been playing with.
But I'd really like to see some testcases where the
ipa_type_escape_field_does_not_clobber_p is supposed to help.
I tried to write:
/* PR tree-optimization/33136 */
/* { dg-do compile } */
/* { dg-options "-O2" } */
struct S
{
void *a;
int b;
float f;
};
static struct S s;
static int *
__attribute__((noinline, const))
foo (void)
{
return &s.b;
}
float
__attribute__((noinline))
bar (float *f)
{
s.f = 1.0;
*f = 4.0;
return s.f;
}
int
__attribute__((noinline))
baz (int *x)
{
s.b = 1;
*x = 4;
return s.b;
}
int
t (void)
{
float f = 8.0;
return bar (&f) + baz (foo ());
}
My understanding would be this is a perfect example where this optimization
should help, ipa-type-escape-var analysis says
ipa_type_escape_field_does_not_clobber_p (, ) == 1
ipa_type_escape_field_does_not_clobber_p (, ) == 0
ipa_type_escape_field_does_not_clobber_p (, ) == 1
which is IMHO correct. In the baz function, we aren't supposed to optimize
out the read from s.b, as x may point to it (and in the testcase actually
does).
In bar on the other side, I believe we can optimize this to
float
__attribute__((noinline))
bar (float *f)
{
s.f = 1.0;
*f = 4.0;
return 1.0;
}
because as ipa-type-escap analysis found nothing ever takes address of any
float field in struct S, so f can't point to it.
But may_alias_p in that case is not called with var with struct S type (nor any
pointer thereof), so ipa_type_escape_star_count_of_interesting_type will
always return -1. It is called just with STRUCT_FIELD_TAGs with float or int
or void * type or f var_decl in function t.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #21 from dberlin at gcc dot gnu dot org 2007-08-24 15:42
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 24 Aug 2007 15:38:58 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #20 from jakub at gcc dot gnu dot org 2007-08-24 15:38
> ---
> Created an attachment (id=14103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
> gcc43-pr33136.patch
>
> Here is what I have been playing with.
> But I'd really like to see some testcases where the
> ipa_type_escape_field_does_not_clobber_p is supposed to help.
>
> I tried to write:
>
> /* PR tree-optimization/33136 */
> /* { dg-do compile } */
> /* { dg-options "-O2" } */
>
> struct S
> {
> void *a;
> int b;
> float f;
> };
>
> static struct S s;
>
> static int *
> __attribute__((noinline, const))
> foo (void)
> {
> return &s.b;
> }
>
> float
> __attribute__((noinline))
> bar (float *f)
> {
> s.f = 1.0;
> *f = 4.0;
> return s.f;
> }
>
> int
> __attribute__((noinline))
> baz (int *x)
> {
> s.b = 1;
> *x = 4;
> return s.b;
> }
>
> int
> t (void)
> {
> float f = 8.0;
> return bar (&f) + baz (foo ());
> }
> My understanding would be this is a perfect example where this optimization
> should help, ipa-type-escape-var analysis says
> ipa_type_escape_field_does_not_clobber_p (, ) == 1
> ipa_type_escape_field_does_not_clobber_p (, ) == 0
> ipa_type_escape_field_does_not_clobber_p (, ) == 1
> which is IMHO correct. In the baz function, we aren't supposed to optimize
> out the read from s.b, as x may point to it (and in the testcase actually
> does).
> In bar on the other side, I believe we can optimize this to
> float
> __attribute__((noinline))
> bar (float *f)
> {
> s.f = 1.0;
> *f = 4.0;
> return 1.0;
> }
> because as ipa-type-escap analysis found nothing ever takes address of any
> float field in struct S, so f can't point to it.
> But may_alias_p in that case is not called with var with struct S type (nor
> any
> pointer thereof), so ipa_type_escape_star_count_of_interesting_type will
> always return -1. It is called just with STRUCT_FIELD_TAGs with float or int
> or void * type or f var_decl in function t.
The call to field_not_clobber_p needs to be in the call clobbering
functions (set_initial_properties and mark_aliases_clobbered) and
access_can_touch_variable to have any real effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug fortran/33177] New: Wrong result from nint() on Cygwin
With the following test case, nint gives wrong result.
svn Revision: 127756
! Program to test the real->integer conversion routines.
program intrinsic_integer
implicit none
real :: val
integer :: i
val = 0.7
i = nint(val)
print *, val, i
val = -0.7
i = nint(val)
print *, val, i
end program
This gives:
$ ./a
0.700 0
-0.700 0
$ cat nint_test.f90.003t.original
MAIN__ ()
{
int4 i;
real4 val;
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) &options.0);
val = 6.9988079071044921875e-1;
i = (int4) __builtin_lroundf (val);
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = &"nint_test.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 8;
dt_parm.1.common.flags = 128;
dt_parm.1.common.unit = 6;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_real (&dt_parm.1, &val, 4);
_gfortran_transfer_integer (&dt_parm.1, &i, 4);
_gfortran_st_write_done (&dt_parm.1);
}
val = -6.9988079071044921875e-1;
i = (int4) __builtin_lroundf (val);
{
struct __st_parameter_dt dt_parm.2;
dt_parm.2.common.filename = &"nint_test.f90"[1]{lb: 1 sz: 1};
dt_parm.2.common.line = 11;
dt_parm.2.common.flags = 128;
dt_parm.2.common.unit = 6;
_gfortran_st_write (&dt_parm.2);
_gfortran_transfer_real (&dt_parm.2, &val, 4);
_gfortran_transfer_integer (&dt_parm.2, &i, 4);
_gfortran_st_write_done (&dt_parm.2);
}
}
--
Summary: Wrong result from nint() on Cygwin
Product: gcc
Version: 4.3.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
GCC host triplet: i686-pc-Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33177
[Bug other/22368] [meta-bug] mis-match types in GCC
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-08-24 15:57 --- "Finished", so unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #3 from atgraham at gmail dot com 2007-08-24 16:00 ---
Here is a smaller bit of code for reproducing this problem. This doesn't
depend on any C++.
#include "pthread.h"
static __typeof(pthread_mutex_lock) __gthrw_pthread_mutex_lock __attribute__
((__weakref__("pthread_mutex_lock")));
int main() {
__gthrw_pthread_mutex_lock(0);
pthread_mutex_lock(0);
}
This (mipsel-linux-gcc -Os) generates the following object code:
:
0: 3c1clui gp,0x0
0: R_MIPS_HI16 _gp_disp
4: 279caddiu gp,gp,0
4: R_MIPS_LO16 _gp_disp
8: 0399e021addugp,gp,t9
c: 27bdffe0addiu sp,sp,-32
10: afbf0018sw ra,24(sp)
14: afbc0010sw gp,16(sp)
18: 8f99lw t9,0(gp)
18: R_MIPS_GOT16pthread_mutex_lock
1c: 2739addiu t9,t9,0
1c: R_MIPS_LO16 pthread_mutex_lock
20: 0320f809jalrt9
24: 2021movea0,zero
28: 8fbc0010lw gp,16(sp)
2c: 8f99lw t9,0(gp)
2c: R_MIPS_CALL16 pthread_mutex_lock
30: 0320f809jalrt9
34: 2021movea0,zero
38: 8fbc0010lw gp,16(sp)
3c: 8fbf0018lw ra,24(sp)
40: 1021movev0,zero
44: 03e8jr ra
48: 27bd0020addiu sp,sp,32
4c: nop
Which gets linked (using binutils 2.17) to this:
00400750 :
400750: 3c1c0005lui gp,0x5
400754: 279c8290addiu gp,gp,-32112
400758: 0399e021addugp,gp,t9
40075c: 27bdffe0addiu sp,sp,-32
400760: afbf0018sw ra,24(sp)
400764: afbc0010sw gp,16(sp)
400768: 8f998058lw t9,-32680(gp)
40076c: 27393c60addiu t9,t9,15456 <-- adds offset to GOT
400770: 0320f809jalrt9
400774: 2021movea0,zero
400778: 8fbc0010lw gp,16(sp)
40077c: 8f998058lw t9,-32680(gp)
400780: 0320f809jalrt9 <-- no additional offset
400784: 2021movea0,zero
400788: 8fbc0010lw gp,16(sp)
40078c: 8fbf0018lw ra,24(sp)
400790: 1021movev0,zero
400794: 03e8jr ra
400798: 27bd0020addiu sp,sp,32
40079c: nop
The "fix" that I mentioned previously, disabling weak support, is only a
workaround for my particular instance of the problem. Using a weak symbol
appears to force the compiler to generate a GOT16 reloc. In any case, it seems
that the linker should be able to "work around" the problem by simply setting
the LO16 offset to 0. So I don't know if this is really a bug in the compiler
or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug fortran/33178] New: -std=f95: SIGN with integer arguments rejected as initialization expression
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0019cb490586ed91/ SIGN with INTEGER arguments is allowed for initialization expressions in Fortran 95; using REAL arguments it is only allowed for Fortran 2003. gfortran -std=f95 prints the wrong error message for: integer :: a = sign(1,1) 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) For the following: real :: a = sign(1.,1.) 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) I would have expected "Error: Fortran 2003:". >From the Fortran 95 standard: "An initialization expression is a constant expression in which the exponentiation operation is permitted only with an integer power, and each primary is [...] (4) An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character," >From the Fortran 2003 standard: "An initialization expression is an expression [...] in which each operation is intrinsic, and each primary is [...] (4) A reference to an elemental standard intrinsic function, where each argument is an initialization expression [...] 13.7.109 SIGN (A, B) [...] Class. Elemental function." -- Summary: -std=f95: SIGN with integer arguments rejected as initialization expression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 16:03 --- None of the testcases in comment #3 fail on the mainline configured with --enable-checking=yes,types. So either this bug is fixed or the patches from Andrew did some slightly different checking. Or both ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug c/33167] Hex constant characters with \x escape not parsing correctly
--- Comment #2 from weston at computer dot org 2007-08-24 16:04 --- Yep, looks like you are right from the standard. That sucks then. I wish it were the other way because I don't see a way to enter a literal single character in hex followed a by single character [A-Z0-9] without escape sequences. Thanks for the quick response. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
[Bug fortran/33178] -std=f95: SIGN with integer arguments rejected as initialization expression
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-08-24 16:04 --- Might (or might not) be induced by my changes in this area. I'm currently in no position to do anything about it, sorry :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
[Bug objc/22474] Objc produces mis-match (non compatible) types in EQ_EXPR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:06 --- The testcase is fine with mainline and --enable-checking=yes,types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22474
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-24 16:06 --- So what is happening is that you are using the function directly and also via a weakref. Can you give the output of GCC (that is the -S file)? This might be really a binutils bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:07 --- The testcase is fixed with mainline and --enable-checking=yes,types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
[Bug debug/33044] Local static variable in C++ constructor not visible for debugging
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-24 16:14 --- This all comes down to cloning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-08-24 16:14 --- Subject: Re: [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704 Accidently reversed test in tree-ssa-alias.c: find_used_portions Testing fix now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #22 from jakub at gcc dot gnu dot org 2007-08-24 16:16 ---
Not sure how, could I pass the buck to you then?
My thought was just that may_alias_p could for STRUCT_FIELD_TAG call
ipa_type_escape_field_does_not_clobber (TREE_TYPE (SFT_PARENT_VAR (var)),
TREE_TYPE (var)) (i.e. don't care about PTRs type, just say if that field's
address wasn't ever taken that it can't alias. That would be similar to how
alias.c uses this function (again, doesn't use the pointer type at all).
Anyway, I found that current GCC 4.2 miscompiles following modified testcase
(works with 4.1 and the trunk, though neither 4.1 nor 4.3 actually optimize bar
function as they could). 4.2 optimizes bar and misoptimizes baz, by assuming
*x = 4; will not clobber s.b.
/* { dg-do run } */
/* { dg-options "-O2" } */
extern void abort (void);
struct S
{
struct S *a;
int b;
float f;
};
static struct S s;
static int *
__attribute__((noinline, const))
foo (void)
{
return &s.b;
}
float
__attribute__((noinline))
bar (float *f)
{
s.f = 1.0;
*f = 4.0;
return s.f;
}
int
__attribute__((noinline))
baz (int *x)
{
s.b = 1;
*x = 4;
return s.b;
}
int
t (void)
{
float f = 8.0;
return bar (&f) + baz (foo ());
}
int
main (void)
{
if (t () != 5)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug libfortran/32972] performance of pack/unpack
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-08-24 16:16 --- Subject: Bug 32972 Author: tkoenig Date: Fri Aug 24 16:16:16 2007 New Revision: 127774 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127774 Log: 2007-08-24 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32972 * iresolve.c: Don't convert array masks. 2007-08-24 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32972 * libgfortran.h: Remove GFOR_POINTER_L8_TO_L4 macro. Add GFOR_POINTER_TO_L1 macro. * m4/iforeach.m4(`m'name`'rtype_qual`_'atype_code): Change argument 'mask' to gfc_array_l1. Adjust prototype. Change mask pointer to GFC_LOGICAL_1. Multiply strides by kind of mask * m4/ifunction.m4: Likewise. * intrinsics/pack_generic.c(pack_internal): Likewise. * intrinsics/unpack_generic.c(unpack_internal): Likewise. * m4/matmull.m4: Switch to GFC_LOGICAL_1. Multiply strides by kind of logical arguments a and b. * generated/matmul_l16.c: Regenerated. * generated/matmul_l4.c: Regenerated. * generated/matmul_l8.c: Regenerated. * generated/maxloc0_16_i1.c: Regenerated. * generated/maxloc0_16_i16.c: Regenerated. * generated/maxloc0_16_i2.c: Regenerated. * generated/maxloc0_16_i4.c: Regenerated. * generated/maxloc0_16_i8.c: Regenerated. * generated/maxloc0_16_r10.c: Regenerated. * generated/maxloc0_16_r16.c: Regenerated. * generated/maxloc0_16_r4.c: Regenerated. * generated/maxloc0_16_r8.c: Regenerated. * generated/maxloc0_4_i1.c: Regenerated. * generated/maxloc0_4_i16.c: Regenerated. * generated/maxloc0_4_i2.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r10.c: Regenerated. * generated/maxloc0_4_r16.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_8_i1.c: Regenerated. * generated/maxloc0_8_i16.c: Regenerated. * generated/maxloc0_8_i2.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r10.c: Regenerated. * generated/maxloc0_8_r16.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc0_16_i1.c: Regenerated. * generated/minloc0_16_i16.c: Regenerated. * generated/minloc0_16_i2.c: Regenerated. * generated/minloc0_16_i4.c: Regenerated. * generated/minloc0_16_i8.c: Regenerated. * generated/minloc0_16_r10.c: Regenerated. * generated/minloc0_16_r16.c: Regenerated. * generated/minloc0_16_r4.c: Regenerated. * generated/minloc0_16_r8.c: Regenerated. * generated/minloc0_4_i1.c: Regenerated. * generated/minloc0_4_i16.c: Regenerated. * generated/minloc0_4_i2.c: Regenerated. * generated/minloc0_4_i4.c: Regenerated. * generated/minloc0_4_i8.c: Regenerated. * generated/minloc0_4
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-24 16:16 --- So one goes the GOT (the weakref) while the other does not (straight call). I am guess this is really a bug in binutils if a bug at all. Though two different relocs for the same symbol should be ok. >and thusly changes its object-modification behavior for *all* invocations of >the function. This is a bug in the linker. You should report this to binutils (http://sourceware.org/bugzilla/ ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug target/33177] Wrong result from nint() on Cygwin
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:17
---
This is a cygwin bug:
$ cat a.c
#include
#include
int main (void) {
float x = 0.7;
int i = (int) lroundf (x);
printf ("%d\n", i);
}
$ gcc a.c && ./a.exe
0
I you replace lroundf() with lround(), it works. Bugreport sent to the
appropriate cygwin mailing-list:
http://cygwin.com/ml/cygwin/2007-08/msg00641.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|fortran |target
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33177
[Bug fortran/33174] Testsuite: unexpected failures
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:24 --- cygwin or msys? What is the host, what is the target? As far as I see, there is only one gfortran failure: FAIL: gfortran.fortran-torture/compile/pr32417.f90, "-O" (internal compiler error) I don't see it on a fresh mingw native compiler (rev 127394M). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #5 from atgraham at gmail dot com 2007-08-24 16:12 --- Created an attachment (id=14104) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14104&action=view) Output of "mipsel-linux-gcc -Os -s tworelocs.c" gcc output attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-08-24 16:21 --- Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop On 24 Aug 2007 16:16:44 -, jakub at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #22 from jakub at gcc dot gnu dot org 2007-08-24 16:16 > --- > Not sure how, could I pass the buck to you then? > > My thought was just that may_alias_p could for STRUCT_FIELD_TAG call > ipa_type_escape_field_does_not_clobber (TREE_TYPE (SFT_PARENT_VAR (var)), > TREE_TYPE (var)) (i.e. don't care about PTRs type, just say if that field's > address wasn't ever taken that it can't alias. That would be similar to how > alias.c uses this function (again, doesn't use the pointer type at all). > This would work too. I will take care of it in about a week if you don't get their first. > Anyway, I found that current GCC 4.2 miscompiles following modified testcase > (works with 4.1 and the trunk, though neither 4.1 nor 4.3 actually optimize > bar > function as they could). 4.2 optimizes bar and misoptimizes baz, by assuming > *x = 4; will not clobber s.b. For 4.2, the safest thing to do is just remove the call from may_alias_p. I serously doubt this will have any real effect on performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #8 from dpgrote at lbl dot gov 2007-08-24 16:29 --- Subject: Re: array pointer assignment gives incorrect dimensions Great! Thanks for fixing this! Dave burnus at gcc dot gnu dot org wrote: > --- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04 > --- > I said: FIXED. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #17 from jakub at gcc dot gnu dot org 2007-08-24 16:33 ---
Does this make sense to do this for POINTER_TYPE_P in 4.1/4.2, which
reassociate
in many other places?
I belive in 4.3 that changed with POINTER_PLUS_EXPR stuff.
struct A { int i; int v[1]; };
int *foo (struct A *a, int x)
{
return &a->v[x - 2147483646];
}
in 4.2/4.1 gives:
foo (a, x)
{
:
return &a->v[0] - 4294967288B + (int *) ((unsigned int) x * 4);
}
so it will overflow (well, underflow).
E.g. on Linux kernel code this commit causes some stack size usage regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug target/33169] Compiler generates two different relocs for the same symbol
--- Comment #7 from atgraham at gmail dot com 2007-08-24 16:34 --- binutils bug created: http://sourceware.org/bugzilla/show_bug.cgi?id=4959 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-24 16:40
---
Maybe - I was just conservative here to not possibly introduce new overflow
with the re-association as elsewhere we may rely on the undefinedness of
overflow.
Another way to fix this particular regression is to disable the decomposing
of &a->v[x - 2147483646] to pointer arithmetic in the C frontend here:
/* For &x[y], return x+y */
if (TREE_CODE (arg) == ARRAY_REF)
{
tree op0 = TREE_OPERAND (arg, 0);
if (!c_mark_addressable (op0))
return error_mark_node;
return build_binary_op (PLUS_EXPR,
(TREE_CODE (TREE_TYPE (op0)) == ARRAY_TYPE
? array_to_pointer_conversion (op0)
: op0),
TREE_OPERAND (arg, 1), 1);
}
like I tried a couple of times.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug debug/33044] Local static variable in C++ constructor not visible for debugging
--- Comment #8 from nikolay at totalviewtech dot com 2007-08-24 16:45 --- (In reply to comment #7) > This all comes down to cloning. > What do you mean? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
Re: [Bug debug/33044] Local static variable in C++ constructor not visible for debugging
On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com <[EMAIL PROTECTED]> wrote: > What do you mean? The IA64 C++ ABI requires two (or three) versions of constructor. So GCC "clones" functions to deal with that. And we emit the context of the local static variable part of the original function, not part of any of its clones. -- Pinski
[Bug debug/33044] Local static variable in C++ constructor not visible for debugging
--- Comment #9 from pinskia at gmail dot com 2007-08-24 16:51 --- Subject: Re: Local static variable in C++ constructor not visible for debugging On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com <[EMAIL PROTECTED]> wrote: > What do you mean? The IA64 C++ ABI requires two (or three) versions of constructor. So GCC "clones" functions to deal with that. And we emit the context of the local static variable part of the original function, not part of any of its clones. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #24 from jakub at gcc dot gnu dot org 2007-08-24 16:36 --- Removing that call in 4.1/4.2 would indeed cure c#8 testcase. c#22 would be still broken (ipa_type_escape_field_does_not_clobber_p isn't called at all on that testcase, neither in 4.1, nor 4.2, nor 4.3. Guess c#22 testcase should go as a separate bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:07 --- Subject: Bug 32610 Author: jakub Date: Fri Aug 24 17:06:59 2007 New Revision: 127776 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127776 Log: PR debug/32610 * dwarf2out.c (gen_decl_die): Don't call gen_tagged_type_instantiation_die if decl doesn't have tagged type. * gcc.dg/debug/pr32610.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/debug/pr32610.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/dwarf2out.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:10 --- Subject: Bug 32898 Author: jakub Date: Fri Aug 24 17:09:50 2007 New Revision: 12 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=12 Log: PR c++/32898 * name-lookup.c (set_decl_namespace): lookup_qualified_name failure is error_mark_node rather than NULL_TREE. * pt.c (check_explicit_specialization): Likewise. * g++.dg/lookup/ns3.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/ns3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/name-lookup.c branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug middle-end/32912] [4.3 Regression] ICE with vector code
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:16 --- Subject: Bug 32912 Author: jakub Date: Fri Aug 24 17:15:51 2007 New Revision: 127779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127779 Log: PR middle-end/32912 * fold-const.c (fold_binary): Only optimize X | ~X and X ^ ~X for integral types. * gcc.dg/pr32912-1.c: New test. * gcc.dg/pr32912-2.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr32912-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr32912-2.c Modified: branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
[Bug middle-end/32912] [4.3 Regression] ICE with vector code
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:22 --- Subject: Bug 32912 Author: jakub Date: Fri Aug 24 17:21:42 2007 New Revision: 127781 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127781 Log: PR middle-end/32912 * fold-const.c (fold_binary): Only optimize X | ~X and X ^ ~X for integral types. * gcc.dg/pr32912-1.c: New test. * gcc.dg/pr32912-2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/crash37.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
[Bug middle-end/32912] [4.3 Regression] ICE with vector code
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-24 17:24 --- Subject: Bug 32912 Author: jakub Date: Fri Aug 24 17:23:43 2007 New Revision: 127783 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127783 Log: PR middle-end/32912 * fold-const.c (fold_binary): Only optimize X | ~X and X ^ ~X for integral types. * gcc.dg/pr32912-1.c: New test. * gcc.dg/pr32912-2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr32912-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr32912-2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug middle-end/32912] [4.3 Regression] ICE with vector code
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-24 17:29 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
[Bug c++/31941] [4.1/4.2/4.3 Regression] "confused by earlier errors" message without earlier error message
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:13 --- Subject: Bug 31941 Author: jakub Date: Fri Aug 24 17:12:41 2007 New Revision: 127778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127778 Log: PR c++/31941 * error.c (resolve_virtual_fun_from_obj_type_ref): Handle TARGET_VTABLE_USES_DESCRIPTORS targets properly. * g++.dg/parse/crash37.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/crash37.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/error.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
[Bug target/33147] ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -mhard-float -O
--- Comment #2 from martinwguy at yahoo dot it 2007-08-24 17:34 --- Also present using -mfloat-abi=softfp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33147
[Bug c++/31941] [4.1/4.2/4.3 Regression] "confused by earlier errors" message without earlier error message
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-24 17:28 --- Fixed. On 4.1 branch with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127781 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
[Bug fortran/33178] -std=f95: SIGN with integer arguments rejected as initialization expression
--- Comment #2 from patchapp at dberlin dot org 2007-08-24 18:40 --- Subject: Bug number PR33178 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-08/msg01675.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
[Bug fortran/33174] Testsuite: unexpected failures
--- Comment #4 from dir at lanl dot gov 2007-08-24 18:40 --- The Host and the Target was cygwin. There 60 unexpected failures in the gcc testsuite and one in the fortran testsuite. I have the latest version of gcc (3.4.4) that the cygwin site gives out. Is that the "fresh mingw native compiler" ? The gcc and gfortran are version 4.3.0 20070723 from svn, built on the cygwin system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug libstdc++/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-24 18:44 --- http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01566.html Broke this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-24 18:44:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- Comment #4 from wvangulik at xs4all dot nl 2007-08-24 18:52 --- Created an attachment (id=14105) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14105&action=view) Assembler output of testcase using 4.1.2 This is the requested assembler output that Eric asked for -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug libstdc++/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-24 18:43 --- I get this too: /home/apinski/src/local/gcc/libstdc++-v3/src/system_error.cc:67: error: std::system_category causes a section type conflict -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker GCC build triplet|powerpc-linux | GCC host triplet|powerpc-linux | GCC target triplet|powerpc-linux |powerpc*-linux Keywords||build Summary|GCC Boot failure, building |[4.3 Regression] GCC Boot |libstc++|failure, building libstc++ Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug fortran/33179] New: gfortran doesn't emit type information for allocatable arrays
It looks like gfortran is using a descriptors to display allocatable arrays in f90, but I could never figure what is the type of the array: <1><202>: Abbrev Number: 2 (DW_TAG_structure_type) DW_AT_name: array_descriptor2 <2><21c>: Abbrev Number: 3 (DW_TAG_member) DW_AT_name: data <2><22b>: Abbrev Number: 3 (DW_TAG_member) DW_AT_name: offset <2><23c>: Abbrev Number: 3 (DW_TAG_member) DW_AT_name: dtype DW_AT_type: <1fa> Any idea how I can get a type from that? -- Summary: gfortran doesn't emit type information for allocatable arrays Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nikolay at totalviewtech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33179
[Bug fortran/33178] -std=f95: SIGN with integer arguments rejected as initialization expression
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-24 19:26 --- Subject: Bug 33178 Author: burnus Date: Fri Aug 24 19:26:42 2007 New Revision: 127786 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127786 Log: 2007-08-24 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33178 * intrinsic.c (gfc_intrinsic_func_interface): Fix initialization expression check. 2007-08-24 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33178 * gfortran.dg/initialization_4.f90: Update dg-error. * gfortran.dg/initialization_13.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
[Bug fortran/33174] Testsuite: unexpected failures
--- Comment #5 from dir at lanl dot gov 2007-08-24 19:27 --- > gfortran --v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc/configure --disable-bootstrap --enable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/usr/local/lib --with-mpfr=/usr/local/lib Thread model: single gcc version 4.3.0 20070723 (experimental) > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
[Bug fortran/33178] -std=f95: SIGN with integer arguments rejected as initialization expression
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-24 19:28 --- Fixed. Was a regression and kind of a typo. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.0 Known to work||4.2.2 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
[Bug libffi/21229] LibFFI can't handle Longs
--- Comment #9 from daney at gcc dot gnu dot org 2007-08-24 19:34 --- Currently both libffi.call/return_sl.c and libffi.call/return_ul.c pass. These cover all the cases in the ffitarget.c attached to the bug. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21229
[Bug target/33050] [avr] unnessary register save
--- Comment #3 from wvangulik at xs4all dot nl 2007-08-24 19:36 ---
(In reply to comment #2)
> 4.3.0 20070817 snapshot generates this for the testcase:
>
Well at least the extra clr r25 is gone...
I just tried some simpler code:
extern unsigned char foo();
unsigned char test(unsigned char input) {
return input += foo();
}
The result is:
/* prologue: frame size=0 */
push r17
/* prologue end (size=1) */
mov r17,r24
call foo
add r17,r24
[Bug c/33167] Hex constant characters with \x escape not parsing correctly
--- Comment #3 from raeburn at raeburn dot org 2007-08-24 19:45 --- (In reply to comment #2) > Yep, looks like you are right from the standard. That sucks then. I wish it > were the other way because I don't see a way to enter a literal single > character in hex followed a by single character [A-Z0-9] without escape > sequences. char *string = "\x01\x02\x03" "Bob"; should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
[Bug fortran/33180] New: Cannot IMPORT symbols later defined in the module
The following program might be invalid as all compilers I tried (gfortran, g95, ifort, NAG f95, ifort) reject it with: IMPORT-name must be the name of an entity in the host scoping unit Error: 't' name in IMPORT statement does not exist in a host program unit Error: Cannot IMPORT 't' from host scoping unit at (1) - does not exist. Cannot IMPORT T from host M - it does not exist But I could not find anything in the standard which prohibits it (PLEASE CHECK). This is especially useful if one wants to use PROCEDURE(name_of_module_procedure) :: dummy_var_in_interface Example: module m implicit none interface subroutine ddd(b) import :: t type(t) :: b end subroutine end interface type t integer :: x end type t end module m -- Summary: Cannot IMPORT symbols later defined in the module Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33180
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg01681.html Status|NEW |ASSIGNED Last reconfirmed|2007-06-21 17:10:20 |2007-08-24 20:23:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- Comment #5 from eweddington at cso dot atmel dot com 2007-08-24 20:25 --- Created an attachment (id=14106) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14106&action=view) Correct assembler output of test case for 4.1.2. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Attachment #14105|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- Comment #6 from eweddington at cso dot atmel dot com 2007-08-24 20:30 --- Created an attachment (id=14107) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14107&action=view) Test case assembler output for 4.2.1. Not really any better than 4.1.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- Comment #7 from eweddington at cso dot atmel dot com 2007-08-24 20:35 --- Created an attachment (id=14108) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14108&action=view) Test case assembler output for 4.3.0 20070817 snapshot. Again, only marginally better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
