[Bug tree-optimization/23475] Frequences are not updated for empty loop removal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:01 --- I should note I found this while looking into PR 23358. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23475
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:01 --- Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-19 06:01:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libgcj/23431] abstract method resolve error in gij
--- Additional Comments From snambi at gmail dot com 2005-08-19 06:17
---
some more analysis of the problem.
looks like this bug has been introduced in gcj 4.0.1
it works correctly in gcj 3.3.3 and javac 1.4.2, ie it gives an error while
compiling. please look below, to see the messages. but gij fails to run. it
should give an compile time error message.
hope it helps.
matrix:/home/snambi/src/java/abs_classes
$gcj -C --classpath .:./jms.jar B.java C.java
B.java:9: error: Class `B' must override `B.onMessage(javax.jms.Message)' with a
public method in order to implement interface `javax.jms.MessageListener'.
abstract void onMessage( javax.jms.Message message );
^
1 error
matrix:/home/snambi/src/java/abs_classes
$export JAVA_HOME=/otp/software/java/j2sdk1.4.2_08/
matrix:/home/snambi/src/java/abs_classes
$export PATH=$PATH:$JAVA_HOME/bin
matrix:/home/snambi/src/java/abs_classes
$javac -classpath .:./jms.jar B.java C.java
B.java:9: onMessage(javax.jms.Message) in B cannot implement
onMessage(javax.jms.Message) in javax.jms.MessageListener; attempting to assign
weaker access privileges; was public
abstract void onMessage( javax.jms.Message message );
^
C.java:8: onMessage(javax.jms.Message) in C cannot implement
onMessage(javax.jms.Message) in javax.jms.MessageListener; attempting to assign
weaker access privileges; was public
void onMessage(javax.jms.Message message)
^
2 errors
matrix:/home/snambi/src/java/abs_classes
$/otp/software/gcc/4.0.1/bin/gcj -C --classpath .:./jms.jar B.java C.java
matrix:/home/snambi/src/java/abs_classes
$/otp/software/gcc/4.0.1/bin/gcj -C --classpath .:./jms.jar B.java C.java A.java
matrix:/home/snambi/src/java/abs_classes
$/otp/software/gcc/4.0.1/bin/gij --classpath .:./jms.jar A
A is getting instantiated
Exception in thread main java.lang.IllegalAccessError: C.onMessage
(Ljavax.jms.Message;)V
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
at java.lang.Class.initializeClass()
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
at A.A() (Unknown Source)
at A.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main()
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
(In reply to comment #0)
there is an abstract class, class B which implements an interface. the method
defined by the interface, is the abstract method. Another class C extends B
and
implements the method. it compiles in gcj -C.
while executing in gij, it throws an IllegalAccessError from
VMClassLoader.resolveClass.
below is the sequence.
$cat B.java
abstract class B implements javax.jms.MessageListener
{
public B()
{
System.out.println(Class B instantiated);
}
abstract void onMessage( javax.jms.Message message );
}
matrix:~/src/java/abs_classes
$cat C.java
class C extends B
{
public C()
{
System.out.println(Class C instantiated);
}
void onMessage(javax.jms.Message message)
{
System.out.println(abstract method test implemented);
}
}
$cat A.java
class A
{
private C c = null;
public A()
{
System.out.println(A is getting instantiated);
c = new C();
}
public static void main( String[] args )
{
A a = new A();
}
}
matrix:~/src/java/abs_classes
$gcj --classpath=.:jms.jar -C *.java
there is a jms.jar file in the current directry.
matrix:~/src/java/abs_classes
$gij --cp .:jms.jar A
A is getting instantiated
Exception in thread main java.lang.IllegalAccessError: C.onMessage
(Ljavax.jms.Message;)V
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
at java.lang.Class.initializeClass()
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
at A.A() (Unknown Source)
at A.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main()
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run()
(/otp/software/gcc/4.0.1/lib/libgcj.so.6.0.0)
sorry for pasting the source code. it is too difficult to explain it
otherwise.
gcj -v --help
.
.
.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/otp/software/gcc/4.0.1
Thread model: posix
gcc version 4.0.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug tree-optimization/23476] New: [4.1 Regression] ICE in VRP, remove_range_assertions
Testcase:
int h(int);
static inline int f(int t, const int i)
{
_Bool a = i t;
if (a)
return h(t);
return 9;
}
int g(int t)
{
return f(t, 0x7FFF);
}
Compile with -O2 -fno-tree-copy-prop, and you will get an ICE:
t.c: In function g:
t.c:12: internal compiler error: in remove_range_assertions, at tree-vrp.c:2767
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
This most likely can be produced with a much larger source but I cannot find it
right now as copy-prop
does nothing interesting except for calling fold on all the statements which is
just a waste of time.
--
Summary: [4.1 Regression] ICE in VRP, remove_range_assertions
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:19 --- Honza and Diego, this is the VRP bug which Honza was talking about which he found working on his SSA based inliner. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
06:24 ---
Ignore the comment about fold, copy prop is doing its job.
Also here is a testcase which can be repduced with a simple -O2 so this is
definitely a regression now
and not just a latent bug waiting to be exposed by other changes:
int h(int);
int t;
static inline int f(const int i)
{
int tt = i;
_Bool a = i t;
if (a)
return h(t);
return 9;
}
int g(void)
{
return f(0x7FFF);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 09:05 --- Subject: Bug 23065 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 09:05:03 Modified files: gcc/fortran: ChangeLog gfortran.h module.c scanner.c Log message: 2005-08-19 Steven G. Kargl [EMAIL PROTECTED] PR fortran/23065 * gfortran.h: Remove PATH_MAX definition. * module.c (write_module, gfc_dump_module): Use alloca to allocate buffers. * scanner.s (gfc_release_include_path, form_from_filename): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.526r2=1.527 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gccr1=1.80r2=1.81 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gccr1=1.34r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/scanner.c.diff?cvsroot=gccr1=1.23r2=1.24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug c++/23477] New: default-initializing array new expression uses memcpy() instead of memset(), bloats executable
the program
int main()
{
new int[1000]();
}
generates a 40MB executable. it compiles into a memcpy() of 40MB of zeros into
the newly-allocated array.
tested at -O0 and -O3.
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
--
Summary: default-initializing array new expression uses memcpy()
instead of memset(), bloats executable
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avi at argo dot co dot il
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
[Bug target/23436] [4.1 Regression] Insn does not satisfy its constraints (reload_cse_simplify_operands)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 09:20 --- Subject: Bug 23436 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 09:20:31 Modified files: gcc: ChangeLog gcc/config/arm : arm.c arm.h arm-protos.h Log message: PR target/23436 * arm.c (thumb_legitimize_reload_address): New function. * arm-protos.h (thumb_legitimize_reload_address): Add prototype. * arm.h (THUMB_LEGITIMIZE_RELOAD_ADDRESS): Call it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9778r2=2.9779 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gccr1=1.473r2=1.474 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.h.diff?cvsroot=gccr1=1.287r2=1.288 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm-protos.h.diff?cvsroot=gccr1=1.89r2=1.90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23436
[Bug target/23436] [4.1 Regression] Insn does not satisfy its constraints (reload_cse_simplify_operands)
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-19 09:23 --- Fixed. Patch also generates slightly better code in other cases too:-) -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23436
[Bug target/23473] [4.1 Regression] ICE at config/arm/arm.c:3280
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-19 09:44 --- OK. I think I understand what's failing here. Testing patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23473
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From uros at kss-loka dot si 2005-08-19 10:19 --- (In reply to comment #13) current mainline bootstrap still fails. ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, at mode-switching.c:352 The patch at http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01142.html fixes this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug rtl-optimization/23478] New: Miscompilation due to reloading of a var that is also used in EH pad
The following testcase is miscompiled on x86_64-linux at -O2. Before global alloc/reload, the interesting part of code is: (reg:DI %rax) = (call _Znwm (1)) (reg:DI 81) = (reg:DI %rax) ... (reg:DI %rdi) = (reg:DI 81) (call _ZN2C1C1ERK2C3S2_S2_RPS1_ (%rdi, ...)) - may throw, EH pad .Leh ... (reg:DI %rdi) = (reg:DI 81) ... (barrier) .Leh: (reg:DI %rdi) = (reg:DI 81) (call _ZdlPv (%rdi)) Now, as the register preassure is pretty high, there don't appear to be any free usable call saved registers for pseudo 81, so global alloc assigns pseudo 81 into (reg:DI %r10), which is call clobbered. Then reload saves it into stack before the _ZN2C1C1ERK2C3S2_S2_RPS1_ call and restores it from the stack slot after the call. But doesn't restore it on the EH path as well. So we end up with: (reg:DI %rax) = (call _Znwm (1)) (reg:DI %r10 (81)) = (reg:DI %rax) ... (reg:DI %rdi) = (reg:DI %r10 (81)) (mem:DI %rsp+24) = (reg:DI %r10 (81)) (call _ZN2C1C1ERK2C3S2_S2_RPS1_ (%rdi, ...)) - may throw, EH pad .Leh (reg:DI %r10 (81)) = (mem:DI %rsp+24) ... (reg:DI %rdi) = (reg:DI %r10 (81)) ... (barrier) .Leh: (reg:DI %rdi) = (reg:DI %r10 (81)) (call _ZdlPv (%rdi)) As this is a reload bug, it is not reproduceable on != 3.4.x compilers I have tried, which doesn't mean the bug is present on 3.4.x only though. -- Summary: Miscompilation due to reloading of a var that is also used in EH pad Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: critical Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at redhat dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug rtl-optimization/23478] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 11:09 --- Created an attachment (id=9546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9546action=view) pr23478.C Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug middle-end/23477] [4.1 Regression] default-initializing array new expression uses makes stack usage go way up
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
11:28 ---
This has been semi fixed on the mainline:
main:
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
subl$4000, %esp
pushl $4000
call_Znaj
leal-4008(%ebp), %ebx
pushl $4000
pushl $0
pushl %ebx
movl%eax, %esi
callmemset
pushl $4000
pushl %ebx
pushl %esi
callmemcpy
leal-8(%ebp), %esp
xorl%eax, %eax
popl%ebx
popl%esi
popl%ebp
ret
But in fact this is worse as the reason for the heap allocation is to avoid
the stack usage at all and now
there is 40MB allocated on the stack.
The problem is in the middle-end:
*(int[1000] *) D.1731 = {};
Note the memcpy is an improvement over what before 4.0.0 had of writting out
element by element.
4.1's problem is a regression in terms of stack usage which should not have
happen.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed||1
GCC build triplet|i386-redhat-linux |
GCC host triplet|i386-redhat-linux |
GCC target triplet|i386-redhat-linux |
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2005-08-19 11:28:34
date||
Summary|default-initializing array |[4.1 Regression] default-
|new expression uses memcpy()|initializing array new
|instead of memset(), bloats |expression uses makes stack
|executable |usage go way up
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 11:35 --- PR 23361 is the bug about unrolling the loops. -- What|Removed |Added BugsThisDependsOn||23361 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-19 11:35 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-08-19 11:35:06 date|| Summary|Miscompilation due to |[3.4 regression] |reloading of a var that is |Miscompilation due to |also used in EH pad |reloading of a var that is ||also used in EH pad Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.
-- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg01146.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
[Bug preprocessor/23479] New: Implement binary constants with a 0b prefix
It is suggested to implement binary contants as a GCC extension to the language. This is a frequently requested item in microcontroller environments, and several other compilers already implement it. The commonly used prefix is 0b, as this does not contradict the standard C syntax, and allows for an easy private extension to the language. Several distributions of AVR-GCC (including the popular WinAVR one, and the FreeBSD port of AVR-GCC) have been shipping with this extension for quite some time, and general user feedback about it is positive. -- Summary: Implement binary constants with a 0b prefix Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at uriah dot heep dot sax dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 12:24 --- Created an attachment (id=9547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9547action=view) Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug c++/23480] New: default-initializing variable size array new expression does not work
the following function
int* f(int n) { return new int[n](); }
translates to
_Z1fi:
.LFB2:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
sall$2, 8(%ebp)
leave
.LCFI2:
jmp _Znaj
which does not default-initialize the array.
--
Summary: default-initializing variable size array new expression
does not work
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avi at argo dot co dot il
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23480
[Bug c++/23480] default-initializing variable size array new expression does not work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 13:04 --- new int[2] () is broken in 3.4.x, see PR 20427. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23480
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug target/23473] [4.1 Regression] ICE at config/arm/arm.c:3280
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 13:17 --- Subject: Bug 23473 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 13:17:04 Modified files: gcc: ChangeLog gcc/config/arm : arm.c arm-protos.h Log message: PR target/23473 * arm.md (arm_load_pic_register): Change argument to the mask of saved registers. Call thumb_find_work_register if we need a scratch register on Thumb. (arm_expand_prologue): Pass empty register set to arm_load_pic_register. (thumb_expand_prologue): Pass live_regs_mask directly to arm_load_pic_register. * arm-protos.h (arm_load_pic_register): Update prototype. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9780r2=2.9781 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gccr1=1.474r2=1.475 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm-protos.h.diff?cvsroot=gccr1=1.90r2=1.91 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23473
[Bug target/23473] [4.1 Regression] ICE at config/arm/arm.c:3280
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-19 13:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23473
[Bug c++/23480] default-initializing variable size array new expression for basic types does not work
-- What|Removed |Added Summary|default-initializing|default-initializing |variable size array new |variable size array new |expression does not work|expression for basic types ||does not work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23480
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 13:22 --- Confirmed, note I would actually disable binary constants by default instead of what the patch currently does, pedwarns about them. Or maybe pedwarn about them by default with an option to turn off that pedwarn. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-19 13:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 13:24 --- Confirmed. Do you know if this is a regression? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|any with STRICT_ALIGNMENT, |defined(STRICT_ALIGNMENT) |e.g. sh-elf | Last reconfirmed|-00-00 00:00:00 |2005-08-19 13:24:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-19 13:27 --- Testing patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 13:36 --- caller-save.c inserts the restore insns after the can_throw_internal () CALL_INSN and as the rest of reload excepts fixup_abnormal_edges to fix the mess up. But, fixup_abnormal_edges only inserts the instructions on the fallthrough edge, not on the fallthrough edge and the EH edge. Is the bug in fixup_abnormal_edges then (which ought to insert the insns on all the edges rather than just one) or is the bug in caller-save.c which would need to take care of this and inserts the restore instructions not only after the call insn (awaiting fixup_abnormal_edges moving it to next resp. new bb), but also to the abnormal edge? It doesn't seem reload.c nor reload1.c (except fixup_abnormal_edges) bothers with this at all, so my guess would be that fixup_abnormal_edges needs to be changed, on the other side it surprises me this didn't cause (reported) problems for so long. -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 13:57 --- (In reply to comment #2) Confirmed, note I would actually disable binary constants by default instead of what the patch currently does, pedwarns about them. Curious: why? There are more than two dozen GCC language extensions enabled by default, most of them would allow GCC to accept a program that will not be accepted by a different compiler. E.g., I'd consider most targets silently accepting dollar signs in identifiers to be at least similarly or even more dangerous. I simply followed the established practice in my suggested implementation. Or maybe pedwarn about them by default with an option to turn off that pedwarn. That would equally apply to about all extension. I'd rather suggest to have something like -Wgcc-extensions, and perhaps include that by default into -Wall. This would make anyone aware of the GCC extensions used in their applications. Differentiating between ``good'' and ``not so good'' GCC extensions seems to be a bit strange to me. Maybe two levels of GCC extension warnings would be appropriate, so any extension keywords starting with two underscores would only be warned at an additional level (-Wall-gcc-extensions, or perhaps only by -pedantic), as these have been used by the developers deliberately. (That should cover any case of __attribute__, __inline__, __asm__ and such being implicitly used by operating system headers, etc.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 14:12 --- (In reply to comment #3) Curious: why? There are more than two dozen GCC language extensions enabled by default, most of them would allow GCC to accept a program that will not be accepted by a different compiler. E.g., I'd consider most targets silently accepting dollar signs in identifiers to be at least similarly or even more dangerous. The main reason is because adding extensions are bad now adays. We are removing extensions which are not used that much and hard to keep working. Even though this extension is very small and well defined, it is just another extension. That would equally apply to about all extension. I'd rather suggest to have something like -Wgcc-extensions, and perhaps include that by default into -Wall. This would make anyone aware of the GCC extensions used in their applications. Differentiating between ``good'' and ``not so good'' GCC extensions seems to be a bit strange to me. It is not strange to me and many other GCC developers because well some are more defined than others. And having hardly used extension warn by default will cause people to think about a better way to write them code and more portable. Maybe two levels of GCC extension warnings would be appropriate, so any extension keywords starting with two underscores would only be warned at an additional level (-Wall-gcc-extensions, or perhaps only by -pedantic), as these have been used by the developers deliberately. __ is reserved for the implemention by the standard so we should not warn about those use at all. The use of __inline__ is also like using __extension__ inline and such so marking the line as using extensions. -pedantic does not warn them currently because of that. If somehow this gets added to a C standard, then the whole point of warning goes away with -std=future, just like long long and C99. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 14:24 --- (In reply to comment #4) The main reason is because adding extensions are bad now adays. We are removing extensions which are not used that much and hard to keep working. OK, I accept that. But then, I'm still in favour of collecting all ``dangerous'' extension, as suggested by the -Wgcc-extensions option, instead of suddenly implying a -half-pedantic behaviour which then can be turned off by a -not-so-pedantic option. That would IMHO violate POLA. If somehow this gets added to a C standard, then the whole point of warning goes away with -std=future, just like long long and C99. That raises the question: how would one propose adding this extension to the standard itself? As I said, a number of (commercial) compilers implement it as well already right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug c++/23481] New: [4.1 regression] ICE with long int and sizeof in template
The following code snippet causes a segfault in fold-const.c on mainline:
=
templatetypename T bool foo()
{
const long int i = sizeof(T) 1 ? sizeof(T) : 0;
return i 0;
}
=
Maybe a front-end or a middle-end issue.
--
Summary: [4.1 regression] ICE with long int and sizeof in
template
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23481
[Bug c++/23481] [4.1 regression] ICE with long int and sizeof in template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 14:29 --- This is most likely the same bug as PR 23357. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23481
[Bug c++/23481] [4.1 regression] ICE with long int and sizeof in template
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23481
[Bug c++/23357] [4.1 Regression] ICE with __alignof__ on template arguments
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19 14:34 --- *** Bug 23481 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23357
[Bug c++/23481] [4.1 regression] ICE with long int and sizeof in template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19 14:34 --- Indeed. Sorry for the dupe. I'll attach the testcase there, too. *** This bug has been marked as a duplicate of 23357 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23481
[Bug c++/23357] [4.1 Regression] ICE with __alignof__ on template arguments
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19
14:35 ---
Confirmed. Similar testcase from PR 23481:
=
templatetypename T bool foo()
{
const long int i = sizeof(T) 1 ? sizeof(T) : 0;
return i 0;
}
=
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2005-08-19 14:35:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23357
[Bug c++/23357] [4.1 Regression] ICE with __alignof__ on template arguments
-- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23357
[Bug tree-optimization/22543] [4.1 regression] ICE: verify_ssa failed with -ftree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19 14:44 --- Just for the record: This was really fixed by the patch in PR8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22543
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From fritz dot ganter at gmail dot com 2005-08-19 14:46 --- I think this is realy a needed feature for mikrocontroller programing. Please implement it. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/22228] [4.1 regression] ICE with -ftree-vectorize in verify_ssa
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19 14:47 --- Fixed on mainline. Btw, this fixes also the ICE from PR 23352 for me. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug tree-optimization/23352] ICE with vectorizer: verify_ssa failed - definition does not dominate use
-- Bug 23352 depends on bug 8, which changed state. Bug 8 Summary: [4.1 regression] ICE with -ftree-vectorize in verify_ssa http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23352
[Bug tree-optimization/21859] ICE with -ftree-vectorize and -O2 or higher
-- Bug 21859 depends on bug 8, which changed state. Bug 8 Summary: [4.1 regression] ICE with -ftree-vectorize in verify_ssa http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug libmudflap/18885] linker does not link libmudflap automatically with -fmudflap
--- Additional Comments From ppluzhnikov at charter dot net 2005-08-19 14:48 --- Note that threaded programs need -lmudflapth instead of -lmudflap. The driver should add correct version of libmudflap automatically, or you'll get bug reports from users who link the wrong version in. Alternatively, libmudflap could use weak unresolved pthread_* symbols, so that a single version of libmudflap works in both threaded and non-threaded environment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 14:51 --- Subject: Bug 15266 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-19 14:50:27 Modified files: fixincludes: ChangeLog inclhack.def fixincl.x fixincludes/tests/base: math.h Log message: PR libfortran/15266 * inclhack.def (broken_cabs): Mention IRIX 5/6 problem. Use double quotes in select so \t matches tabs. Add IRIX testcase. * fixincl.x: Regenerate. * tests/base/math.h [BROKEN_CABS_CHECK]: Adapt for new testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32.2.7r2=1.32.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/inclhack.def.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.16.14.4r2=1.16.14.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.x.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.16.14.4r2=1.16.14.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/tests/base/math.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2r2=1.2.18.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug libgcj/21943] O32 libffi.so fails to link on IRIX 6
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 14:54 --- Subject: Bug 21943 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-19 14:53:02 Modified files: libffi : ChangeLog libffi/src/mips: n32.S o32.S Log message: PR libgcj/21943 * src/mips/n32.S: Enforce PIC code. * src/mips/o32.S: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.222.2.5r2=1.222.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/src/mips/n32.S.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=1.3.72.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/src/mips/o32.S.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.6r2=1.6.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21943
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 15:18 --- Additional remark: GAS also recognizes 0bXXX constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 15:50 --- Subject: Bug 23065 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-19 15:50:43 Modified files: gcc/fortran: ChangeLog gfortran.h module.c scanner.c Log message: 2005-08-19 Steven G. Kargl [EMAIL PROTECTED] PR fortran/23065 * gfortran.h: Remove PATH_MAX definition. * module.c (write_module, gfc_dump_module): Use alloca to allocate buffers. * scanner.c (gfc_release_include_path, form_from_filename): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.108r2=1.335.2.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.58.2.14r2=1.58.2.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.31.2.1r2=1.31.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/scanner.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.16.10.5r2=1.16.10.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*
--
Bug 21824 depends on bug 23065, which changed state.
Bug 23065 Summary: MAXPATHLEN usage in fortran/{scanner,module}.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
What|Old Value |New Value
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-19 15:51 --- Fixed. -- What|Removed |Added CC||tobi at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k
--- Additional Comments From joel at oarcorp dot com 2005-08-19 16:02 --- Subject: Re: [4.0/4.1 regression] ICE with soft-float on m68k Why did you turn this from m68k-* to m68k-rtems? It was reported against m68k-rtems but would have be duplicated on at least m68k-elf if not any other m68k target. Even the fix is clearly not RTEMS specific. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug c++/23482] New: g++ crash building for m5307 arch
I reported this to the uClinux developer list (where I got my gcc cross-compiler
toolchain), and they recommended that I report it here.
I'm getting a compiler crash building a 3rd-party C++ lib (ACE) for uClinux.
The lib compiles with g++ for every other platform known to man, so I'm sure the
code is solid. I was able to whittle down the offending code to the following:
---
class A
{
public:
void foo();
};
class B
{
public:
~B();
};
void bar(A a)
{
B b;
a.foo();
char c[32768];
}
---
Dont ask me why, but each statement is required to produce the crash. When I
compile it with 3.4.3 (the 20050221 uClinux m68k toolchain distribution), I get
this:
% m68k-elf-g++ gcc-crash.cpp -m5307 -c
gcc-crash.cpp: In function `void bar(A)':
gcc-crash.cpp:19: error: insn does not satisfy its constraints:
(insn 24 106 107 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
(reg:SI 0 %d0)) [0 S4 A16])
(mem:SI (plus:SI (reg/f:SI 14 %a6)
(reg:SI 1 %d1)) [0 S4 A16])) 26 {*m68k.md:760} (nil)
(nil))
gcc-crash.cpp:19: internal compiler error: in final_scan_insn, at final.c:2359
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Here are the details from the compiler:
% m68k-elf-g++ -v
Reading specs from
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.3/specs
Configured with: /usr/local/src/uclinux-tools/gcc-3.4.3/configure
--target=m68k-uclinux --prefix=/usr/local/m68k-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale --disable-c-mbchar --disable-long-long --disable-checking
--enable-threads=posix --disable-libstdcxx-pch
--enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: posix
gcc version 3.4.3
BTW, this code compiles fine with the 2.95.3 uClinux m68k toolchain, but I need
to upgrade to 3.4.x.
Thanks,
Keith.
--
Summary: g++ crash building for m5307 arch
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: keith dot nicewarner at spacedev dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-redhat-linux
GCC target triplet: m68k-uclinux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23482
[Bug libgcj/23466] Double.toString(0.0010) --- 0.001 ISO 0.0010
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-19 16:20 --- I agree that this is most likely not a libgcj bug. Ronald, why do you think the _dtoa call ought to be changed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23466
[Bug libfortran/23483] New: [mingw32] Fortran runtime I/O error on correct program
The program runs with out problem with g77, but fails with gfortran - [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ g77 -o write01 write01.f [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ write01 [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ gfortran -o write01 write01.f [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ write01 At line 13 of file write01.f Fortran runtime error: Invalid argument [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ gfortran --v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,f95 --with-gmp=/home/FX/local/ --with-mpfr=/home/FX/local Thread model: win32 gcc version 4.1.0 20050805 (experimental) [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ cat write01.f program main implicit real*8 (a-h,o-z) common /ioline/ n common /iodatac/ cmmnd(52) character*16 cmmnd dimension xx(52) ntape=3 do 10 n=1,10 write (ntape) n,xx,cmmnd 10 continue rewind ntape do 15 i=1,10 read (ntape,end=20) n,xx,cmmnd 15 continue 20 continue stop end [dranta:~/tests/gfortran-D] dir% -- Summary: [mingw32] Fortran runtime I/O error on correct program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23483
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From giovannibajo at libero dot it 2005-08-19 16:28 --- If there was a voting system in this Bugzilla, I'd vote for this. It's a very useful feature in embedded programming. I also believe that it could be enabled by default in GNU C, since it's really easy and well-defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug c/23484] New: __builtin___memcpy_chk miscompilation
Hi,
Compiling ruby on x86_64 with -D_FORTIFY_SOURCE=2 will cause failure in the
testsuite.
This can be reproduced with
GNU C version 4.1.0 20050819 (experimental) (x86_64-unknown-linux-gnu)
Here is a simplified testcase.
extern void abort (void);
#undef memcpy
#define memcpy(dst, src, len) \
__builtin___memcpy_chk (dst, src, len, __builtin_object_size (dst, 0))
int
main (void)
{
static const char data[] = { 0, 0x40, 0xe2, 0x01, 0x00, 0x01, 0x80, 0xc0,
0x1d };
const char *s = data[1];
int natint = data[0];
unsigned long tmp = 0;
memcpy (tmp, s, natint ? sizeof(tmp) : 4);
if (sizeof(tmp) 4 (tmp 32) != 0) /* movq generated? */
abort ();
return 0;
}
--
Summary: __builtin___memcpy_chk miscompilation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gbeauchesne at mandriva dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 16:49 --- (In reply to comment #12) Subject: Re: [4.0/4.1 regression] ICE with soft-float on m68k Why did you turn this from m68k-* to m68k-rtems? It was reported against m68k-rtems but would have be duplicated on at least m68k-elf if not any other m68k target. Even the fix is clearly not RTEMS specific. Because I could not reproduce it with a cross to m68k-linux-gnu from powerpc- darwin on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/23482] g++ crash building for m5307 arch
-- What|Removed |Added Component|c++ |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23482
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
-- What|Removed |Added Severity|critical|normal Component|c |middle-end GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet||x86_64-*-linux-gnu Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From joseph at codesourcery dot com 2005-08-19
17:28 ---
Subject: Re: New: Implement binary constants with
a 0b prefix
The patch does not document how the types of binary constants are
determined. I suppose the rules are the same as for octal and hexadecimal
constants, but the documentation needs to say so.
The patch does not document the 0B prefix, although the code accepts it.
The documentation should say @samp{0}, @samp{1}, @samp{0b}.
You can't write diagnostics like
+SYNTAX_ERROR3 (invalid digit \%c\ in %s constant, '0' + max_digit,
+ radix == 2? binary: octal);
because this doesn't work with i18n. You need to have two separate
strings, each of them a complete sentence, rather than building up
sentences from fragments. If you use a conditional expression, check
whether you need to mark the strings with N_ to get them in cpplib.pot.
It's not clear how you ensure that someone can't write floating point
numbers as e.g. 0b1e2 (the check for floats says in part radix = 10
(c == 'e' || c == 'E') which would allow binary, being designed to allow
8 (0123e4 being decimal but looking like octal at first) and 10).
The patch is missing testcases. They should include that the values of
these constants (both 0b and 0B) are correct (both in the compiler and in
preprocessor conditionals), that the types follow the correct rules (which
need to be documented; see c99-intconst-1.c for how to test constant type
rules), that you can't write floating point numbers such as 0b1e2 or
0b1p3, and that these constants receive warnings with -pedantic and errors
with -pedantic-errors (for both C and C++, and for both the compiler and
the preprocessor).
If you don't already have a copyright assignment on file you may need to
get one. See http://gcc.gnu.org/contribute.html. As new features can't
go in until 4.1 has branched there should be plenty of time to do so
before a complete patch (submitted to gcc-patches) can be considered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 17:54 --- Subject: Bug 23048 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 17:54:16 Modified files: gcc: ChangeLog tree-if-conv.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr23048.c Log message: PR tree-optimization/23048 * tree-if-conv.c (if_convertible_bb_p): Supply basic_block as third parameter. Check whether latch is dominated by exit block or not. (if_convertible_loop_p): Supply exit block itself to if_convertible_bb_p. * gcc.dg/tree-ssa/pr23048.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9781r2=2.9782 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-if-conv.c.diff?cvsroot=gccr1=2.45r2=2.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5937r2=1.5938 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23048.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
[Bug c++/23437] [3.4/4.0/4.1 Regression] error: ... cannot appear in a constant-expression
--- Additional Comments From giovannibajo at libero dot it 2005-08-19 18:06 --- Patch posted, waiting for review: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01169.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg01169.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23437
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 18:09 --- Subject: Bug 23476 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 18:08:56 Modified files: gcc: ChangeLog tree-cfgcleanup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr23476.c Log message: PR 23476 * tree-cfgcleanup.c (cleanup_control_expr_graph): Fold the conditional expression before testing its value. PR 23476 * gcc.c-torture/compile/pr23476.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9783r2=2.9784 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfgcleanup.c.diff?cvsroot=gccr1=2.5r2=2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5938r2=1.5939 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23476.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-19 18:10 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01150.html. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug target/23485] New: [ia64]: Integer dvide by zero doesn't raise a signal
[EMAIL PROTECTED] zero]$ cat x.c
int
foo (int y, int x)
{
return y/x;
}
[EMAIL PROTECTED] zero]$ cat y.c
#include stdio.h
extern int foo (int, int);
int
main ()
{
printf ((10/0) = %d\n, foo (10, 0));
return 0;
}
[EMAIL PROTECTED] zero]$ gcc x.c y.c
[EMAIL PROTECTED] zero]$ ./a.out
(10/0) = 0
It happens on gcc 3.4/4.0/4.1.
--
Summary: [ia64]: Integer dvide by zero doesn't raise a signal
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug tree-optimization/22320] -ftree-dominator-opts documentation is the same as -ftree-dce
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-19 18:20 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01168.html. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22320
[Bug target/23485] [ia64]: Integer dvide by zero doesn't raise a signal
--- Additional Comments From hjl at lucon dot org 2005-08-19 18:21 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01172.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug tree-optimization/22320] -ftree-dominator-opts documentation is the same as -ftree-dce
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22320
[Bug target/23485] [ia64]: Integer dvide by zero doesn't raise a signal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 18:26 --- I don't see why this is a bug really as on some targets (PPC) divide by zero does not raise any thing and the result is undefined. You might want to test your patch's performance as it could cause a lot of problems if someone does a loop with divides in them and it checks all the time for divide by zero which an extra branch every time which is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-19 18:32 --- I think it's caller-save's bug. The use of fixup_abnormal_edges in reload and reg-stack is to move output reloads to the fallthru edge. Well, the output reloads are not used on the eh edge, because by definition the output was not generated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 18:32 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-19 18:34 --- More, since you cannot insert insns on the abnormal EH edge, the fix to caller-save needs to be of the form don't caller-save this variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug c++/22454] [4.0/4.1 Regression] ICE with operator in default argument in template class
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-19
18:37 ---
Even shorter testcase:
===
templateint struct A
{
A(void* = operator new);
};
===
--
What|Removed |Added
GCC build triplet|i486-linux-gnu |
GCC host triplet|i486-linux-gnu |
GCC target triplet|i486-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22454
[Bug libffi/21943] O32 libffi.so fails to link on IRIX 6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 18:43 --- Fixed als in 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Component|libgcj |libffi Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21943
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 18:51 --- It can't be inserted just on abnormal critical edges: gcc_assert (!((e-flags EDGE_ABNORMAL) EDGE_CRITICAL_P (e))); So I guess we could insert it on the EH edges if !EDGE_CRITICAL_P and only only avoid caller-saving it if EDGE_CRITICAL_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 18:54 --- Hmm, let look at the source: memcpy (tmp, s, natint ? sizeof(tmp) : 4); natint will be zero so we get -- What|Removed |Added CC||jakub at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 18:55 --- (In reply to comment #1) Ignore that comment, I am stupid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
18:55 ---
(In reply to comment #9)
Thank you very much for the useful comments.
The patch does not document how the types of binary constants are
determined. I suppose the rules are the same as for octal and
hexadecimal constants, but the documentation needs to say so.
Yes, I simply didn't think about that.
The patch does not document the 0B prefix, although the code accepts
it.
Hmm, I thought that was obvious... OK.
The documentation should say @samp{0}, @samp{1}, @samp{0b}.
OK.
You can't write diagnostics like ...
because this doesn't work with i18n.
Ah, well, understood.
It's not clear how you ensure that someone can't write floating
point numbers as e.g. 0b1e2 (the check for floats says in part
radix = 10 (c == 'e' || c == 'E') which would allow binary,
being designed to allow 8 (0123e4 being decimal but looking like
octal at first) and 10).
I didn't realize the same parser would also parse FP numbers. Sure,
FP numbers are allowed to start with 0x these days... I'll see how to
resolve that.
The patch is missing testcases.
Is there a tutorial anywhere how to run testcases?
If you don't already have a copyright assignment on file ...
I do have.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/23486] New: ICE in execute_todo, at passes.c:677
// compile with -O3
struct v { int n; };
foo (struct v *v, int *q)
{
q [v-n ++] = 0;
}
bar (int b, void *p, int *q)
{
for (;;)
foo (b ? p : 0, q);
}
//
t2.c: In function âbarâ:
t2.c:7: internal compiler error: in execute_todo, at passes.c:677
--
Summary: ICE in execute_todo, at passes.c:677
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23486
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
19:00 ---
It can be confirmed on x86 with:
extern void abort (void);
#undef memcpy
#define memcpy(dst, src, len) \
__builtin___memcpy_chk (dst, src, len, __builtin_object_size (dst, 0))
int
main (void)
{
static const char data[] = { 0, 0x40, 0xe2, 0x01, 0x00, 0x01, 0x80, 0xc0,
0x1d };
const char *s = data[1];
int natint = data[0];
unsigned long long tmp = 0;
memcpy (tmp, s, natint ? sizeof(tmp) : 4);
if (sizeof(tmp) 4 (tmp32) != 0) /* movq generated? */
abort ();
return 0;
}
And here is a testcase for big endian:
extern void abort (void);
#undef memcpy
#define memcpy(dst, src, len) \
__builtin___memcpy_chk (dst, src, len, __builtin_object_size (dst, 0))
int
main (void)
{
static const char data[] = { 0, 0x40, 0xe2, 0x01, 0x00, 0x01, 0x80, 0xc0,
0x1d };
const char *s = data[1];
int natint = data[0];
unsigned long long tmp = 0;
memcpy (tmp, s, natint ? sizeof(tmp) : 4);
printf(%llx\n, tmp);
if (sizeof(tmp) 4 (tmp 0xFF) != 0) /* 64bit move generated? */
abort ();
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC target triplet|x86_64-*-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2005-08-19 19:00:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug tree-optimization/23486] [4.1 Regression] ICE in execute_todo, at passes.c:677
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
19:07 ---
Confirmed.
Testcase:
struct v { int n; };
void bar (int b, void *p, int *q)
{
struct v *v;
for (;;)
{
v = b?p:0;
q [v-n ++] = 0;
}
}
Compile at -O1 -funswitch-loops.
--
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-19 19:07:45
date||
Summary|ICE in execute_todo, at |[4.1 Regression] ICE in
|passes.c:677|execute_todo, at
||passes.c:677
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23486
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From joseph at codesourcery dot com 2005-08-19 19:10 --- Subject: Re: Implement binary constants with a 0b prefix On Fri, 19 Aug 2005, j at uriah dot heep dot sax dot de wrote: The patch is missing testcases. Is there a tutorial anywhere how to run testcases? http://gcc.gnu.org/wiki/HowToPrepareATestcase For the testing that constants have the correct type, start with the macro definitions from c99-instconst-1.c (CHECK_HEX_CONST can be converted to what you need by changing 0x and 0X to 0b and 0B) but replace the function foo with one checking the binary versions of the hex constants presently checked. (The macros dealing with decimal constants can be removed as irrelevant for binary.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-19 19:14 --- Maybe. I think you'll find that most of the time these edges *are* critical. I don't think it's worth bothering to make the distinction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
--- Additional Comments From jakub at redhat dot com 2005-08-19 19:16 --- I have a preliminary fix, will work on testcases now, then test it thoroughly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug bootstrap/23487] New: Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
stage1/xgcc -Bstage1/ -B/home/4/wilx/i386-unknown-freebsd4.10/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes-Werror -fno-common -DHAVE_CONFIG_H\ -I/home/4/wilx/include -I. -Iada -I../../srcdir/gcc -I../../srcdir/gcc/ada -I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include ../../srcdir/gcc/ada/init.c -o ada/init.o cc1: warnings being treated as errors ../../srcdir/gcc/ada/init.c: In function '__gnat_install_handler': ../../srcdir/gcc/ada/init.c:1601: warning: assignment from incompatible pointer type make[2]: *** [ada/init.o] Error 1 make[2]: Leaving directory `/home/4/wilx/tmp/gcc-head/objdir/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/4/wilx/tmp/gcc-head/objdir/gcc' make: *** [bootstrap-lean] Error 2 -- Summary: Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: v dot haisman at sh dot cvut dot cz CC: gcc-bugs at gcc dot gnu dot org,v dot haisman at sh dot cvut dot cz GCC build triplet: i386-unknown-freebsd4.10 GCC host triplet: i386-unknown-freebsd4.10 GCC target triplet: i386-unknown-freebsd4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 19:28 --- This is a bug in the freebsd specific section in init.c. -- What|Removed |Added Component|bootstrap |ada Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug rtl-optimization/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-08-19 19:51 ---
gcse after reload may move loads from stack around stack pointer changes. here
is simple workaround, it is supposed to prevent gcse after reload from touching
expressions containing stack pointer at all.
Index: cse.c
===
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.359
diff -u -r1.359 cse.c
--- cse.c 29 Jul 2005 05:57:37 - 1.359
+++ cse.c 19 Aug 2005 19:33:49 -
@@ -2221,6 +2221,14 @@
return 0;
}
}
+ else
+ {
+ if (x == stack_pointer_rtx)
+ {
+ *do_not_record_p = 1;
+ return 0;
+ }
+ }
hash += ((unsigned int) REG 7);
hash += (have_reg_qty ? (unsigned) REG_QTY (regno) : regno);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2005-08-19 19:51 --- According to FreeBSD man page for sigaction (http://www.freebsd.org/cgi/man.cgi?query=sigactionapropos=0sektion=0manpath=FreeBSD+5.4-RELEASE+and+Portsformat=html) the following looks like it should fix it. *** init.c.~1.52.~ Sun Jul 31 23:10:03 2005 --- init.c Fri Aug 19 21:49:07 2005 *** *** 1598,1604 exceptions. Make sure that the handler isn't interrupted by another signal that might cause a scheduling event! */ ! act.sa_handler = __gnat_error_handler; act.sa_flags = SA_NODEFER | SA_RESTART; (void) sigemptyset (act.sa_mask); --- 1598,1604 exceptions. Make sure that the handler isn't interrupted by another signal that might cause a scheduling event! */ ! act.sa_handler = (void(*)(int))__gnat_error_handler; act.sa_flags = SA_NODEFER | SA_RESTART; (void) sigemptyset (act.sa_mask); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2005-08-19 19:57 --- More of the same: *** link.c.~1.16.~ Fri Jul 8 12:45:47 2005 --- link.c Fri Aug 19 21:55:40 2005 *** *** 154,166 const char *__gnat_object_library_extension = .a; #elif defined (__FreeBSD__) ! char *__gnat_object_file_option = ; ! char *__gnat_run_path_option = -Wl,-rpath,; char __gnat_shared_libgnat_default = STATIC; int __gnat_link_max = 8192; unsigned char __gnat_objlist_file_supported = 1; unsigned char __gnat_using_gnu_linker = 1; ! char *__gnat_object_library_extension = .a; #elif defined (linux) const char *__gnat_object_file_option = ; --- 154,166 const char *__gnat_object_library_extension = .a; #elif defined (__FreeBSD__) ! const char *__gnat_object_file_option = ; ! const char *__gnat_run_path_option = -Wl,-rpath,; char __gnat_shared_libgnat_default = STATIC; int __gnat_link_max = 8192; unsigned char __gnat_objlist_file_supported = 1; unsigned char __gnat_using_gnu_linker = 1; ! const char *__gnat_object_library_extension = .a; #elif defined (linux) const char *__gnat_object_file_option = ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2005-08-19 20:11 --- 2005-08-19 Vaclav Haisma [EMAIL PROTECTED] * init.c (FreeBSD's __gnat_install_handler): Cast __gnat_error_handler to proper type. * link.c (FreeBSD's __gnat_object_file_option, __gnat_run_path_option, __gnat_object_library_extension): Make const. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2005-08-19 20:12 --- Errr, my surname is missing n at the end... 2005-08-19 Vaclav Haisman [EMAIL PROTECTED] * init.c (FreeBSD's __gnat_install_handler): Cast __gnat_error_handler to proper type. * link.c (FreeBSD's __gnat_object_file_option, __gnat_run_path_option, __gnat_object_library_extension): Make const. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug tree-optimization/23486] [4.1 Regression] ICE in execute_todo, at passes.c:677
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-19 20:18 --- breaks bootstrap with BOOT_CFLAGS=-O3 . -- What|Removed |Added Severity|normal |critical Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23486
[Bug rtl-optimization/23488] New: extra reads from static variable
typedef int nl_item;
extern char *nl_langinfo (nl_item __item) __attribute__ ((__nothrow__));
char *
xtermEnvEncoding(void)
{
static char *result;
if (result == 0) {
result = nl_langinfo(1);
;
}
return result;
}
Compile the above code with -march=i686 -O2
4.1 generates extra reads to the static result.1282.
xtermEnvEncoding:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movlresult.1282, %eax
testl %eax, %eax
je .L6
movlresult.1282, %eax --- this one
leave
ret
.p2align 4,,7
.L6:
movl$1, (%esp)
callnl_langinfo
movl%eax, result.1282
movlresult.1282, %eax -- and this one
leave
ret
4.0 does not generate those instructions.
This is one of the reasons for the code size regression in PR23153.
--
Summary: extra reads from static variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux.-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug tree-optimization/23153] [4.1 Regression] code size regression from 4.0 on x86
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-19 21:47 --- Is there any reason that this PR is still in UNCONFIRMED state? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug target/23488] [4.1 Regression] extra reads from static variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 21:50 --- Confirmed. There are two issues here. First the regression was caused by: 2005-07-30 Jan Hubicka [EMAIL PROTECTED] * expr.c (expand_expr_real_1): Do not load mem targets into register. * i386.c (ix86_fixup_binary_operands): Likewise. (ix86_expand_unary_operator): Likewise. (ix86_expand_fp_absneg_operator): Likewise. * optabs.c (expand_vec_cond_expr): Validate dest. Just like all of your other regressions. Second this really should be done on the tree level. I think this is load PRE but I could be wrong. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-08-19 21:50:53 date|| Summary|extra reads from static |[4.1 Regression] extra reads |variable|from static variable Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug tree-optimization/23153] [4.1 Regression] code size regression from 4.0 on x86
-- What|Removed |Added BugsThisDependsOn||23488 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug target/23153] [4.1 Regression] [meta-bug] code size regression from 4.0 on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 21:54 --- (In reply to comment #5) Is there any reason that this PR is still in UNCONFIRMED state? Because this really a meta-bug now. And it looks like all the remaining issues are caused by: 2005-07-30 Jan Hubicka [EMAIL PROTECTED] * expr.c (expand_expr_real_1): Do not load mem targets into register. * i386.c (ix86_fixup_binary_operands): Likewise. (ix86_expand_unary_operator): Likewise. (ix86_expand_fp_absneg_operator): Likewise. * optabs.c (expand_vec_cond_expr): Validate dest. So this is target issue. -- What|Removed |Added BugsThisDependsOn|21883 | Status|UNCONFIRMED |NEW Component|tree-optimization |target Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-19 21:54:52 date|| Summary|[4.1 Regression] code size |[4.1 Regression] [meta-bug] |regression from 4.0 on x86 |code size regression from ||4.0 on x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
