[Bug target/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #7 from kazu at gcc dot gnu dot org 2006-09-24 06:41 --- This is because of GEN_INT (0x8000) is used in SImode. Searching for "GEN_INT (0x8000)" in m68k.md reveals three such uses. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-24 05:34 ---
Here is a testcase which shows this is a latent bug:
extern int f2 (int, int, int, int);
struct s { char b[4]; };
__thread struct s a[2];
void f1 (int a1, int a2)
{
int i, j;
for (i = 0; i < 4; i++)
{
int tot = 0;
for (j = 0; j < 4; j++)
tot += f2 (a1, a2, i, j);
*(&a[0].b[0] + i) = tot;
}
}
--
But since the orginal testcase worked in 3.4.0, this should be still marked as
a regression, IV-OPTs is causing the latent bug to show up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-24 05:31 --- I should note that -fno-ivopts causes to produce the correct result for this testcase. I am going to try to find a testcase that fails even with 3.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 05:29 --- Confirmed, this testcase worked in 3.4.0 but that might just mean this is a latent bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-09-24 05:29:30 date|| Summary|Incorrect reference to |[4.0/4.1/4.2 Regression] |__thread array with -fPIC - |Incorrect reference to |O2 on x86 |__thread array with -fPIC - ||O2 on x86 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug target/29198] New: Incorrect reference to __thread array with -fPIC -O2 on x86
I compiled this C code with current mainline with -fPIC -O2 on x86 GNU/Linux:
extern int f2 (int, int, int, int);
struct s { char b[4]; };
__thread struct s a[2];
void f1 (int a1, int a2)
{
int i, j;
for (i = 0; i < 4; i++)
{
int tot = 0;
for (j = 0; j < 4; j++)
tot += f2 (a1, a2, i, j);
a[0].b[i] = tot;
}
}
The resulting assembler file had this in it:
movl[EMAIL PROTECTED](%ebx), %ecx
But a is declared with __thread. This should instead be something like:
leal[EMAIL PROTECTED](,%ebx,1), %eax
call[EMAIL PROTECTED]
In the real code there are other references to a, which leads to a linker
error:
`a' accessed both as normal and thread local symbol
I believe the bug is in legitimize_address or in legitimize_pic_address in
config/i386/i386.c. legitimize_address gets called with
(plus:SI (reg/v:SI 64 [ i ])
(symbol_ref:SI ("a") [flags 0x8] ))
When it sees a symbol as the right-hand operand of a PLUS, it calls
legitimize_pic_address. That returns an UNSPEC_GOT. Somewhere along the way,
it needs to call legitimize_tls_address.
--
Summary: Incorrect reference to __thread array with -fPIC -O2 on
x86
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug objc/29197] [4.0/4.1/4.2 Regression] ICE after error with array type with undefined variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 03:03 --- I know how to fix this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Severity|normal |minor Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-09-24 03:03:53 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug objc/29197] New: [4.0/4.1/4.2 Regression] ICE after error with array type with undefined variable
@ implementation NGActiveSocket
+ (void) socketPair:(int[m]) _pair {}
@end
---
t.m:3: internal compiler error: tree check: expected class 't', have 'x'
(error_mark) in objc_method_parm_type, at objc/objc-act.c:3596
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.0/4.1/4.2 Regression] ICE after error with array type
with undefined variable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, ice-checking
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug objc/29195] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-24 03:01 --- (In reply to comment #4) > objc_push_parm is borken for other problems, guess I have to fix the other > problems too. But I will enter them as other bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29195
[Bug objc/29195] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-24 02:59 --- objc_push_parm is borken for other problems, guess I have to fix the other problems too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29195
[Bug objc/29195] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-24 02:56 --- The problem is with objc_push_parm where we forgot to relayout the decl. I have an obvious fix which I will apply after testing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29195
[Bug objc/29195] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-24 02:50 --- The problem is that the decl mode is DImode which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29195
[Bug objc/29195] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 02:37 ---
Confirmed, reduced testcase:
@ implementation NGActiveSocket
+ (void) socketPair:(int [2])
_pair
{
_pair[0] = 0;
}
@end
--
I think this is an objc only bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|middle-end |objc
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2006-09-24 02:37:21
date||
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29195
[Bug bootstrap/29196] gcc fails to build on x86-64 linux
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 02:30 --- /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or direc\ tory That means you don't have the 32bit userland installed which means you either use --disable-multilib or install it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29196
[Bug bootstrap/29196] New: gcc fails to build on x86-64 linux
The current svn tree, revision 117177 as checked out about half an hour ago, fails to build on an x86-64 running GCC 4.1.1 and Linux: [EMAIL PROTECTED] objdir]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) The failing part of the build is as follows: make[5]: Entering directory `/home/donnybrook2/phr/gcc/objdir/gcc' /home/donnybrook2/phr/gcc/objdir/./gcc/xgcc -B/home/donnybrook2/phr/gcc/objdir/./gcc/ -B/home/donnybrook2/phr/gcc/installdir/x86_64-unknown-linux-gnu/bin/ -B/home/donnybrook2/phr/gcc/installdir/x86_64-unknown-linux-gnu/lib/ -isystem /hom\ e/donnybrook2/phr/gcc/installdir/x86_64-unknown-linux-gnu/include -isystem /hom\ e/donnybrook2/phr/gcc/installdir/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I32 -I../../gcc/gcc -I../../gcc/gcc/32 -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I\ ../../gcc/gcc/../libdecnumber -I../libdecnumber -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \ -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o 32/crtbegin.oIn file included from /usr/include/features.h:352, from /usr/include/stdio.h:28, from ../../gcc/gcc/tsystem.h:90, from ../../gcc/gcc/crtstuff.c:68: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or direc\ tory make[5]: *** [32/crtbegin.o] Error 1 make[5]: Leaving directory `/home/donnybrook2/phr/gcc/objdir/gcc' make[4]: *** [extra32] Error 2 make[4]: Leaving directory `/home/donnybrook2/phr/gcc/objdir/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/home/donnybrook2/phr/gcc/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/donnybrook2/phr/gcc/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/donnybrook2/phr/gcc/objdir' make: *** [all] Error 2 -- Summary: gcc fails to build on x86-64 linux Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phr-gcc at nightsong dot com GCC build triplet: x86-64, linux GCC host triplet: x86-64, linux GCC target triplet: x86-64, linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29196
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #11 from pinskia at gmail dot com 2006-09-24 00:34 --- Subject: Re: optimzation breaks floating point exception flag reading On Sat, 2006-09-23 at 23:02 +, joseph at codesourcery dot com wrote: > In that case you have a bug that is not a duplicate of the lack of > FENV_ACCESS pragma support. The relevant semantics are meant to be > supported by these command line options. This is a TER bug then and I really doubt it can be fixed easy. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #10 from joseph at codesourcery dot com 2006-09-23 23:02 --- Subject: Re: optimzation breaks floating point exception flag reading On Sat, 23 Sep 2006, kreckel at ginac dot de wrote: > I am still not entirely sure whether we are really talking about the same > problem. The original problem was that the compiler optimized assuming that > the > floating point division cannot have side effects, such that the offending > division happens after the call to fetestexcept(3): > Neither -ftrapping-math, nor -frounding-math change anything, as long as -O1 > is > turned on: The printf inside the if statement is *not* executed. In that case you have a bug that is not a duplicate of the lack of FENV_ACCESS pragma support. The relevant semantics are meant to be supported by these command line options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #9 from kreckel at ginac dot de 2006-09-23 22:58 ---
(In reply to comment #8)
I am still not entirely sure whether we are really talking about the same
problem. The original problem was that the compiler optimized assuming that the
floating point division cannot have side effects, such that the offending
division happens after the call to fetestexcept(3):
#include
#include
int main()
{
double x = (double)printf("") + 1.0; // one
double y = (double)printf(""); // zero
feclearexcept(FE_ALL_EXCEPT);
double z = x / y; // should set FE_DIVBYZERO
if (fetestexcept(FE_ALL_EXCEPT)) {
printf("flag set after call.\n");
}
printf("%f/%f==%f\n",x,y,z);
}
Neither -ftrapping-math, nor -frounding-math change anything, as long as -O1 is
turned on: The printf inside the if statement is *not* executed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug java/29194] fails to import package from project
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-23 22:33 --- Note that -d doesn't do anything when compiling to object. However, adding -C doesn't help either. A simple workaround is to add -Isrc. This is fixed on the gcj-eclipse branch, I marked this PR as depending on PR 28067. Perhaps gcj needs to handle -combine properly. That would also help fix this, I think. -- tromey at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28067 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-23 22:33:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29194
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #8 from joseph at codesourcery dot com 2006-09-23 22:19 --- Subject: Re: optimzation breaks floating point exception flag reading On Sat, 23 Sep 2006, kreckel at ginac dot de wrote: > > > --- Comment #7 from kreckel at ginac dot de 2006-09-23 22:11 --- > (In reply to comment #6) > > Use -frounding-math to enable FENV_ACCESS for the whole translation unit, > > Sorry, I fail to see what -frounding-math has to do with this. The example in > comment #5 was about overflows and divisions by zero. Anyway, adding > -frounding-math does not change anything in the case at hand. Exceptions are meant to be covered by -ftrapping-math, which is on by default; with -frounding-math the whole of FENV_ACCESS should be enabled. Although we don't implement the pragmas for control of these features in particular regions of code, we *do* have options that are meant to enable them for whole translation units. So any failure of those options to disable problem optimizations is a bug which is *not* a duplicate of the lack of the pragmas. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #7 from kreckel at ginac dot de 2006-09-23 22:11 --- (In reply to comment #6) > Use -frounding-math to enable FENV_ACCESS for the whole translation unit, Sorry, I fail to see what -frounding-math has to do with this. The example in comment #5 was about overflows and divisions by zero. Anyway, adding -frounding-math does not change anything in the case at hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug middle-end/27945] [4.0/4.1/4.2 Regression] Packed struct of variable length has wrong size
-- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27945
[Bug middle-end/20983] [4.0/4.1/4.2 Regression] varargs functions force va_list variable to stack unnecessarily
-- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #6 from joseph at codesourcery dot com 2006-09-23 21:52 --- Subject: Re: optimzation breaks floating point exception flag reading On Sat, 23 Sep 2006, kreckel at ginac dot de wrote: > According to C99, 7.6.1, you are technically right. But still: an > implementation that does not allow access to floating point flags irritates > me. Use -frounding-math to enable FENV_ACCESS for the whole translation unit, but note the warnings in the documentation of that option. If that option does not meet all the requirements of FENV_ACCESS, file a new bug report for each specific problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #5 from kreckel at ginac dot de 2006-09-23 21:41 ---
(In reply to comment #3)
> So this is not a bug except for the fact GCC does not implement "#pragma STDC
> FENV_ACCESS "
According to C99, 7.6.1, you are technically right. But still: an
implementation that does not allow access to floating point flags irritates me.
Couldn't that be outright dangerous, in certain circumstances?
Consider a hypothetical train control unit:
#define FE_CRITICAL (FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW)
double compute_speed(double measurement)
{
return -1./(measurement); // in reality, some rather hairy computation
}
// Adjusts speed towards nominal speed, given measurement of speed sensor.
// May decelerate, in unforeseen cases.
void control(double nominal_v, double measurement)
{
#pragma STDC FENV_ACCESS on
feclearexcept(FE_CRITICAL);
double v = compute_speed(measurement);
if (fetestexcept(FE_CRITICAL)) {
// Unexpected error: should not trust the computed speed.
decelerate();
return;
}
if (v > nominal_v*1.001) {
printf("v==%f\n",v);
decelerate();
return;
}
if (v < nominal_v*0.999) {
accelerate();
return;
}
}
Would you board that train if the train control unit were compiled with GCC?
The function decelerates the train if something unforeseen happens inside the
speed computation. At least it did that when it was compiled with GCC 3.3.x,
3.4.x, or 4.0.x. Now, with GCC 4.1.x, all bets are off. Also, no compiler
version seems to care to print a warning.
Having the users lulled in a false sense of safety for so long, this changed
behavior with a allusion to the standard ("we need not return something
meaningful") strikes me as, excuse me, somewhat careless.
Maybe somehone can provide other suggestions how to program defensively? In
principle, the functionality used above (testing floating point flags) has been
promised since two decades (it's IEEE 754) and has been implemented in almost
every major hardware since as long. Can GNU-C not be used for such simple
things?
--
kreckel at ginac dot de changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
21:33 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c6)
(gdb) p locale_mutex
$2 = {_M_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0,
__m_kind = 0, __m_lock = {__spinlock = {lock = {0, 0, 0, 0}},
__status = 0}}}
(gdb) p &locale_mutex
$3 = (__gnu_cxx::__mutex *) 0x41c6
All the "lock" values should be 1 immediately after initialization.
Could this be an ordering problem?
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug tree-optimization/29195] New: [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6932
Happens at least with 4.1 and 4.2. Maybe Andrew can find a C testcase?
(sid)88:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -x objective-c -O -c
sope-NGActiveSocket.m
sope-NGActiveSocket.m:18: warning: cannot find interface declaration for
'NGActiveSocket'
sope-NGActiveSocket.m:22: warning: '@end' missing in implementation context
sope-NGActiveSocket.m: In function '+[NGActiveSocket socketPair:inDomain:]':
sope-NGActiveSocket.m:21: internal compiler error: in expand_expr_real_1, at
expr.c:6932
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
(sid)89:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -x objective-c -c
sope-NGActiveSocket.m
sope-NGActiveSocket.m:18: warning: cannot find interface declaration for
'NGActiveSocket'
sope-NGActiveSocket.m:22: warning: '@end' missing in implementation context
(sid)90:[EMAIL PROTECTED]: ~] gcc-4.1 -x objective-c -O -c sope-NGActiveSocket.m
sope-NGActiveSocket.m:18: warning: cannot find interface declaration for
âNGActiveSocketâ
sope-NGActiveSocket.m:22: warning: [EMAIL PROTECTED] missing in implementation
context
sope-NGActiveSocket.m: In function â+[NGActiveSocket
socketPair:inDomain:]â:
sope-NGActiveSocket.m:21: internal compiler error: in expand_expr_real_1, at
expr.c:6763
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
(sid)91:[EMAIL PROTECTED]: ~]
(sid)91:[EMAIL PROTECTED]: ~] cat sope-NGActiveSocket.m
typedef unsigned char BOOL;
@protocol NSObject - (Class) class;
@end @ interface NSObject < NSObject >
@end typedef struct _NSRange
{
}
NSRange;
@interface NSException:NSObject
@end static inline BOOL
NGIsStreamErrorException (NSException * _exception)
{
}
@protocol NGSocketAddress < NSObject >
@end @ protocol NGSocket < NSObject > -(id < NGSocketAddress >) localAddress;
@end @ protocol NGSocketDomain < NSObject > -(id < NGSocketAddress >)
addressWithRepresentation:(void
*)
_data size:(unsigned int) _size;
@end @ implementation NGActiveSocket + (BOOL) socketPair:(id < NGSocket >[2])
_pair inDomain:(id < NGSocketDomain >) _domain
{
_pair[0] = (id) 0;
}
--
Summary: [4.1/4.2 Regression] ICE in expand_expr_real_1, at
expr.c:6932
Product: gcc
Version: 4.2.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=29195
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #8 from giffordj at linkline dot com 2006-09-23 20:27 --- Created an attachment (id=12317) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12317&action=view) Attempt #3 at attaching -save-temp info -- giffordj at linkline dot com changed: What|Removed |Added Attachment #12311|0 |1 is obsolete|| Attachment #12312|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
20:18 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.
We seem to have an uninitialized mutex:
(gdb) break *0x40b4c6bc
Breakpoint 1 at 0x40b4c6bc: file mutex.c, line 123.
(gdb) cond 1 mutex->__m_lock.__spinlock.lock[0]==0
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/home/dave/gcc-4.2/objdir/hppa-linux/libstdc++-v3/testsuite/23591_thread-1.xg
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 6058)]
[New Thread 32769 (LWP 6059)]
[New Thread 16386 (LWP 6060)]
[Switching to Thread 16386 (LWP 6060)]
Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c6)
at mutex.c:123
123 mutex.c: No such file or directory.
in mutex.c
(gdb) p *mutex
$1 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) bt
#0 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c6) at mutex.c:123
#1 0x41ba9a5c in locale (this=0x41c5ece4) at gthr-default.h:549
#2 0x41ba49e4 in Init (this=) at streambuf:462
#3 0x41bbea94 in __static_initialization_and_destruction_0 (
__initialize_p=, __priority=0) at iostream:77
#4 0x41c2d2c0 in __do_global_ctors_aux ()
from
/home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5 0x41b93984 in _init ()
from
/home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#6 0x402917f8 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#7 0x402919b0 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#8 0x410710a0 in dl_open_worker (a=) at dl-open.c:504
#9 0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#10 0x410707d4 in *__GI__dl_open (file=0x10aa0 "./testsuite_shared.so",
mode=-2147483646, caller_dlopen=0x10714, nsid=-2) at dl-open.c:577
#11 0x4037c13c in dlopen_doit (a=0x410b7608) at dlopen.c:59
#12 0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#13 0x4037c620 in _dlerror_run (
operate=0x41c5d458 <__cxxabiv1::__unexpected_handler+8248>,
args=0xc025d644) at dlerror.c:162
#14 0x4037c0d0 in __dlopen (file=, mode=1103486040)
at dlopen.c:78
#15 0x00010714 in run (arg=)
at
/home/dave/gcc-4.2/gcc/libstdc++-v3/testsuite/19_diagnostics/23591_thread-1.c:35
#16 0x40b4b28c in pthread_start_thread (arg=0x410b7000) at manager.c:310
#17 0x40b4b628 in pthread_start_thread_event (arg=0x410b7000) at manager.c:334
#18 0x41036134 in thread_start () from /usr/lib/debug/libc.so.6
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23 19:25 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites > One thing you could try, to confirm that this is what's up, is to replace the > hppa atomics config with the generic pthreads layer. Doesn't fix problem. > To confirm, if you go into the freshly built libstdc++/src directory and > > ls -al atomicity.cc > > You should see it pointing to > config/cpu/generic/atomicity_mutex/atomicity.h > > instead of the current > config/cpu/hppa/atomicity.h Yes, atomicity.cc is pointing to the generic directory. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in -> build fails
--- Comment #5 from mkoeppe at gmx dot de 2006-09-23 18:54 --- Created an attachment (id=12316) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12316&action=view) patch to fix this bug Hello Andrew, I now tested your fix and built a diff. It works great and now I'm able to build a cross compiler successfully: ../src/configure --target=i586-pc-interix3 \ --enable-languages=c \ --enable-threads=posix \ --with-stabs \ --enable-nls \ --enable-shared \ --disable-libssp \ --with-gnu-as \ --with-gnu-ld Even if non-cross "make bootstrap" on i586-pc-interix3 still doesn't work out of the box, the patch should nevertheless be applied to gcc-4.2.0 and gcc-4.1.1 to close this bug, as exactly this configuration has worked with 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug c++/28989] [4.0/4.1/4.2 Regression] post-increment of bool variable accepted as lvalue
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-23 18:50 --- I have a new patch, for some reason we are looking through a SAVE_EXPR which is incorrect really. A SAVE_EXPR can never be a lvalue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |09/msg00532.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28989
[Bug java/21697] gcj segfaults with Jabref.jar
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-09-23 18:42 --- not reproducible with the 2.1 jar file and current 4.1 branch Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21697
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2006-09-23 18:41 --- Paul, The new patch doesn't allow gfortran to build. I get an error... /sw/src/fink.build/gcc4-4.1.-20060923/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060923/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc-4.2-20060923/gcc -I../../gcc-4.2-20060923/gcc/fortran -I../../gcc-4.2-20060923/gcc/../include -I./../intl -I../../gcc-4.2-20060923/gcc/../libcpp/include -I/sw/include -I../../gcc-4.2-20060923/gcc/../libdecnumber -I../libdecnumber -I/sw/include ../../gcc-4.2-20060923/gcc/fortran/trans-expr.c -o fortran/trans-expr.o ../../gcc-4.2-20060923/gcc/fortran/trans-expr.c: In function 'gfc_conv_structure': ../../gcc-4.2-20060923/gcc/fortran/trans-expr.c:2902: error: 'gfc_constructor' has no member named 'allocatable' make[3]: *** [fortran/trans-expr.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug rtl-optimization/29128] [4.2 Regression] ICE: in move_block_after_check, at haifa-sched.c:4337
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-09-23 18:30 --- Created an attachment (id=12315) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12315&action=view) Patch. That's my bug, sorry. The attached patch has only been tested on x86_64; sadly, I'll be able to run it on ia64 not before Monday. 2006-09-23 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR rtl-optimization/29128 * sched-ebb.c (advance_target_bb): Use correct condition to allow interblock movement of speculation checks. * sched-int.h (IS_SPEC_BRANCY_CHECK_P): New macro. 2006-09-23 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR rtl-optimization/29128 * gcc.c-torture/compile/pr29128.c: New test. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23 18:03 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites > > Does hpux use the hppa atomics config, or the generic layer? If it uses the > > hppa atomics config, why isn't this a problem on hpux? > > I believe they use the same atomics. I think it points to a pthread > issue. Further to this point, I used strace to look at pthread6 while it was executing. I see a continuous stream of sched_yield calls with a few nanosleep calls every so often. Thus, I think the code is spinning in __pthread_acquire. This would happen if spinlock/mutex initialization is broken. Proper initialization is needed on hppa-linux because locked is 0 and unlocked is 1. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug c/29193] Warning on if(a < b < c) and other similar codes
--- Comment #1 from schwab at suse dot de 2006-09-23 17:29 --- This is part of -Wparentheses since gcc 4.0. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29193
[Bug java/29194] fails to import package from project
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-09-23 17:18 --- Created an attachment (id=12314) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12314&action=view) example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29194
[Bug java/29194] New: fails to import package from project
[forwarded from http://bugs.debian.org/369873]
GCJ fails with
Can't find default package 'core'. ...
when a class source file specifies `import core.*'. A full example is
outlined below.
If you try to compile this `project' like
gcj -d . src/Main.java src/core/Foo.java
the above mentioned error is reported. The same project works fine
with Sun's or Blackdown's Java compiler.
Suppose we have the directory structure
> find .
./src
./src/core
./src/core/Foo.java
./src/Main.java
with the following contents of `src/Main.java':
// commenting out this line makes the classes compile.
import core.*;
public class Main
{
public Main()
{
core.Foo foo = new core.Foo();
foo.print();
}
public static void main(String args[])
{
Main m = new Main();
}
}
and the following contents of `src/core/Foo.java':
package core;
public class Foo
{
public Foo()
{}
public void print()
{
System.out.println("Hello, world");
}
}
--
Summary: fails to import package from project
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29194
[Bug c++/26938] [4.0/4.1/4.2 regression] ICE with wrong number of template parameters
--- Comment #4 from patchapp at dberlin dot org 2006-09-23 16:35 --- Subject: Bug number PR c++/26938 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/2006-09/msg01019.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26938
[Bug c++/26938] [4.0/4.1/4.2 regression] ICE with wrong number of template parameters
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-30 23:18:48 |2006-09-23 16:34:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26938
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
--- Comment #4 from patchapp at dberlin dot org 2006-09-23 16:30 --- Subject: Bug number PR c++/27961 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/2006-09/msg01018.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/29188] undocumented extension with ambiguous between conversion function/constructor. related to const
--- Comment #2 from greifel at megatop200 dot com 2006-09-23 16:29 --- According to 1.4/8 implementations with extensions are required to "diagnose programs that use extensions that are ill-formed according to this International Standard." This code is ill-formed so presumably g++ should print a warning. I don't know the motivation for the extension but would highlight the question of whether it was intentional that it affects non-const arguments but not const. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29188
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-14 19:06:35 |2006-09-23 16:28:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2006-09-23 16:24 --- Paul, Could you please include the testsuite testcases when you post the patch? It's rather hard to regression test without those. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c/29193] New: Warning on if(a < b < c) and other similar codes
Consider this code: if(a <= b <= c) something(); If c is >= 1, then the `if' will always execute something(), because `a <= b' returns either 0 or 1. This, obviously, is not an error, but it can mislead some programmers, therefore it would be nice to have a warning like "warning: suggest parentheses around inequality used as truth value". In this way, the following code will be accepted without warnings: if((a <= b) <= c) something(); That's all ;) -- Summary: Warning on if(a < b < c) and other similar codes Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alpt at freaknet dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29193
[Bug c++/27667] [4.0/4.1/4.2 regression] ICE with in-class specialization
--- Comment #2 from patchapp at dberlin dot org 2006-09-23 16:20 --- Subject: Bug number PR c++/27667 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/2006-09/msg01017.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27667
[Bug c++/27667] [4.0/4.1/4.2 regression] ICE with in-class specialization
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-26 15:06:59 |2006-09-23 16:18:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27667
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #21 from paul dot thomas at jet dot uk 2006-09-23 16:18 --- Created an attachment (id=12313) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12313&action=view) Latest patch This version fixes the problem with constructors of structures that have allocatable components of structures with allocatable components. It also fixes Salvatore's problem with initializers (thanks!). Finally, the problems with forall seem to have fixed themeselves...,I think. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c++/29024] [4.0/4.1/4.2 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
--- Comment #3 from patchapp at dberlin dot org 2006-09-23 16:10 --- Subject: Bug number PR c++/29024 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/2006-09/msg01016.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug c++/29080] [4.0/4.1/4.2 Regression] Multiple-inheritance with template method function code triggers "internal compiler error: in build_base_path, at cp/class.c:273"
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-23 15:19 ---
Breakpoint 1, fancy_abort (file=0xde98b0 "../../trunk/gcc/cp/class.c",
line=272,
function=0xde98a0 "build_base_path") at ../../trunk/gcc/diagnostic.c:642
642 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x004c328a in build_base_path (code=PLUS_EXPR, expr=0x2af85340,
binfo=0x2aac19a0, nonnull=1) at ../../trunk/gcc/cp/class.c:269
269 gcc_assert ((code == MINUS_EXPR
(gdb) l
264
265 probe = TYPE_MAIN_VARIANT (TREE_TYPE (expr));
266 if (want_pointer)
267 probe = TYPE_MAIN_VARIANT (TREE_TYPE (probe));
268
269 gcc_assert ((code == MINUS_EXPR
270&& SAME_BINFO_TYPE_P (BINFO_TYPE (binfo), probe))
271 || (code == PLUS_EXPR
272 && SAME_BINFO_TYPE_P (BINFO_TYPE (d_binfo), probe)));
273
(gdb) p code
$1 = PLUS_EXPR
(gdb)
(gdb) p probe
$2 = (tree) 0x2af7db00
(gdb) p debug_tree(probe)
constant invariant 16>
unit size constant invariant 2>
align 8 symtab 0 alias set -1
fields
nonlocal decl_4 VOID file t.C line 7
align 1 context
>
X() X(constX&) this=(X&) n_parents=2 use_template=0 interface-unknown
pointer_to_this chain >
$3 = void
(gdb) p debug_tree(d_binfo)
unit size
align 8 symtab 0 alias set -1
fields
nonlocal decl_4 VOID file t.C line 5
align 1 context
>
X() X(constX&) this=(X&) n_parents=1 use_template=0 interface-unknown
chain >
private>
$4 = void
(gdb) p d_binfo->common.type
$5 = (tree) 0x2af7d840
(gdb) p debug_tree(d_binfo->common.type)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab 0 alias set -1
fields
nonlocal decl_4 VOID file t.C line 5
align 1 context
>
X() X(constX&) this=(X&) n_parents=1 use_template=0 interface-unknown
chain >
$6 = void
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug rtl-optimization/29128] [4.2 Regression] ICE: in move_block_after_check, at haifa-sched.c:4337
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-23 15:14 ---
This is where we ICE:
Breakpoint 1, fancy_abort (file=0xbfb788 "../../trunk/gcc/haifa-sched.c",
line=4337,
function=0xbfc0a0 "move_block_after_check") at
../../trunk/gcc/diagnostic.c:642
642 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x00a721d5 in move_block_after_check (jump=0x2af8f180)
at ../../trunk/gcc/haifa-sched.c:4336
4336 gcc_assert (RECOVERY_BLOCK (jump)
(gdb) l
4331 jump_bb = BLOCK_FOR_INSN (jump);
4332 jump_bb_next = jump_bb->next_bb;
4333
4334 update_bb_for_insn (jump_bb);
4335
4336 gcc_assert (RECOVERY_BLOCK (jump)
4337 || RECOVERY_BLOCK (BB_END (jump_bb_next)));
4338
4339 unlink_block (jump_bb_next);
4340 link_block (jump_bb_next, bb);
(gdb) p debug_rtx(jump)
(jump_insn 93 121 122 7 (set (pc)
(reg:DI 326 b6)) 330 {indirect_jump} (nil)
(expr_list:REG_DEAD (reg:DI 326 b6)
(nil)))
$7 = void
(gdb) p h_i_d[93].recovery_block
$8 = (basic_block) 0x0
(gdb) p debug_bb(jump_bb_next)
;; basic block 8, loop depth 0, count 0
;; prev block 7, next block 1
;; pred:
;; succ:
;; Registers live at start: (nil)
(note 122 93 94 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(note 94 122 96 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
;; Registers live at end: (nil)
$9 = void
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
--- Comment #4 from uros at kss-loka dot si 2006-09-23 14:41 --- Fixed. -- uros at kss-loka dot si changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
--- Comment #3 from uros at gcc dot gnu dot org 2006-09-23 14:40 --- Subject: Bug 29169 Author: uros Date: Sat Sep 23 14:40:07 2006 New Revision: 117171 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117171 Log: PR target/29169 * gcc.target/i386/sse-21.c: Rename from sse3-not-fisttp.c. (dg-options): Add -mfpmath=387. Added: trunk/gcc/testsuite/gcc.target/i386/sse-21.c - copied, changed from r117170, trunk/gcc/testsuite/gcc.target/i386/sse3-not-fisttp.c Removed: trunk/gcc/testsuite/gcc.target/i386/sse3-not-fisttp.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug c/29192] gcc will delete the c_source_file.c without any alarm!
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-23 14:03 --- And this is not a bug, and here is why libnetsnmp could contain a main which means GCC is just calling the linker at this point so the linker is the one which is removing your source. And the output file really could be called anything for a program. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29192
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
-- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg01012.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-09-21 17:52:55 |2006-09-23 13:36:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug c++/29024] [4.0/4.1/4.2 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-09-23 13:31 --- Testing a patch. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-11 20:50:09 |2006-09-23 13:31:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug c/29192] New: gcc will delete the c_source_file.c without any alarm!
when I made a mistake that I forgot to add the Object output file name after the option -o ,gcc deleted my source file without any alarm so quickly that I lost my source file and I had to type the source file again. command & ouput: [EMAIL PROTECTED]:~$ gcc -o snmpget.c -lnetsnmp /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o: In function `_start':../sysdeps/i386/elf/start.S:115：对main未定义的引用 collect2: ld 返回 1 [EMAIL PROTECTED]:~$ ls snmpget.c ls: snmpget.c: No such file or directory -- Summary: gcc will delete the c_source_file.c without any alarm! Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: freephp at gmail dot com GCC build triplet: gcc -o snmpget.c -lnetsnmp GCC host triplet: Ubuntu 6.06 GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29192
[Bug c/29154] [4.0/4.1/4.2 Regression] *(* ppointer++)++ = *pointer++ generates bad code
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-23 10:33 --- Sounds reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #54 from rguenth at gcc dot gnu dot org 2006-09-23 10:22 --- It's at least still a regression on the 4.1 branch, which still does cc1: out of memory allocating 290995744 bytes after a total of 43593728 bytes at -O1. Otherwise we have 3.4.6: 106s 4.0.3: 108s 4.1.2: OOM 4.2.0: 86s and 4.2.0 uses a lot less memory than 4.0.3. So, let's remove the 4.2 regression marker. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.1.2 |4.1.2 Known to work|4.0.2 |3.4.6 4.0.2 4.2.0 Summary|[4.1/4.2 regression] A file |[4.1 regression] A file that |that can not be compiled in |can not be compiled in |reasonable time/space |reasonable time/space http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/29183] cc1: internal compiler error: Segmentation Fault
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-23 10:05 --- gcc -g -Wall -D -I . -I ../Common/MemMgmt -I ../Common/StringMgmt -I The '-D -I .' part is broken. Remove the -D. Otherwise we cannot do anything about bugs without a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29183
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #53 from steven at gcc dot gnu dot org 2006-09-23 09:44 --- Is this still a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #26 from agner at agner dot org 2006-09-23 08:23 --- Thank you for fixing this, but you need to tell the world which solution you have chosen. Please see the discussion at the dublicate bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537 for arguments for and against each possible solution. You need to specify whether the chosen solution is to enforce 16 byte stack alignment regardless of -Os option or the solution is to make no assumption about stack alignment when making XMM code. This is an ABI issue that has to be standardized and made public. The makers of the Intel compiler are waiting for a resolution to this issue so that they can make their compiler compatible with GCC. For the same reason, assembly programmers need to know whether stack alignment is required or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug c/28712] [4.0/4.1/4.2 Regression] Compile failure with --combine and packed structures.
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-23 07:15 --- Subject: Bug 28712 Author: jakub Date: Sat Sep 23 07:15:37 2006 New Revision: 117167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117167 Log: PR c/28706 PR c/28712 * tree.c (merge_attributes, attribute_list_contained): If both TREE_VALUEs are TREE_LISTs, use simple_cst_list_equal instead of simple_cst_equal. * c-typeck.c (comptypes_internal): Don't consider aggregates in different TUs as compatible if there one set of attributes is not a subset of the other type's attributes. (composite_type): Try harder not to create a new aggregate type. * gcc.dg/pr28706.c: New test. * gcc.dg/pr28712.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr28706.c trunk/gcc/testsuite/gcc.dg/pr28712.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28712
[Bug c/28706] [4.1/4.2 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-23 07:15 --- Subject: Bug 28706 Author: jakub Date: Sat Sep 23 07:15:37 2006 New Revision: 117167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117167 Log: PR c/28706 PR c/28712 * tree.c (merge_attributes, attribute_list_contained): If both TREE_VALUEs are TREE_LISTs, use simple_cst_list_equal instead of simple_cst_equal. * c-typeck.c (comptypes_internal): Don't consider aggregates in different TUs as compatible if there one set of attributes is not a subset of the other type's attributes. (composite_type): Try harder not to create a new aggregate type. * gcc.dg/pr28706.c: New test. * gcc.dg/pr28712.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr28706.c trunk/gcc/testsuite/gcc.dg/pr28712.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
