--- Comment #1 from paolo at gcc dot gnu dot org 2005-11-05 09:42 ---
Subject: Bug 22203
Author: paolo
Date: Sat Nov 5 09:42:01 2005
New Revision: 106524
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106524
Log:
2005-11-05 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2005-11-05 09:43 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 10:31 ---
This is probably a dup of Bug 22509, which has a patch.
Can someone check if this bug is fixed by the patch from Bug 22509?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-05 10:48 ---
This doesn't fail for me with the test case from comment #6... :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-11-05 10:51 ---
Subject: Re: [4.0/4.1 Regression] PUBLIC derived types
with private components
tobi at gcc dot gnu dot org wrote:
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-01 19:22 ---
CCing pault, as he
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-05 11:06 ---
Yes, I have been too strict. The private derived type must be accessible
inside the module where it is defined (4.4.1).
I'll have a patch ready before the weekend is out.
Thanks Harald!
Paul
--
There are two sample programs at www.openmp.org . One of them - md - fails
with ICE.
svn update was done on Nov. 5, i.e. r106450 of the gomp-branch.
gfortran-gomp -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gomp
--program-suffix=-gomp
--- Comment #1 from magnus_os at yahoo dot se 2005-11-05 11:17 ---
I just found out that I made a small misstake in the copy paste of the
example. One line the initialize subroutine has two variable declarations
like this:
integer i, j real*8 x
Please press Return to
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2005-11-05
11:51 ---
I got some preliminary results from debugging.
By -fdump-parse-tree, YLOCAL does have the correct (implicitly
determined) type of CHARACTER*8 at statement YLOCAL='A'.
However, by the time we reach
Compiling kdenetwork3 we get
/abuild/buildsystem.f198.rguenther/usr/lib64/gcc/x86_64-suse-linux/4.1.0/cc1plus
-fpreprocessed hash.3.1.ii -quiet -dumpbase hash.cpp -mtune=k8 -ansi
-auxbase-strip .libs/libiris_xmpp_core_la-hash.o -O2 -O2 -Wno-long-long -Wundef
-Wcast-align -Wconversion
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-05 12:13 ---
Created an attachment (id=10152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10152action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #18 from bonzini at gcc dot gnu dot org 2005-11-05 12:15
---
Patch had to be reverted on 3.4
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-05 14:14
---
(In reply to comment #11)
This is probably a dup of Bug 22509, which has a patch.
Can someone check if this bug is fixed by the patch from Bug 22509?
I doubt this is related at all to PR 22509 because this has
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-05 14:17 ---
Isn't this a dup of bug 20928. (I will try with a GCC after that patch to
double check).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-05 14:25 ---
I doubt, the compiler is from Nov 4, while the patch looks like comitted at
latest Oct 31. But I haven't re-checked against mainline HEAD.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from thebohemian at gmx dot net 2005-11-05 14:57 ---
By further inspecting the problem I got the impression that gcj's approach of
linking is flawed. As I understand it gcj does linking-on-initialization but
for the java language, being built-around the idea of late
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 15:07 ---
Fails also with 4.1.0 20051026 and with last night's compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-05 15:13 ---
This is another loop.c bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Using --help flag, there is no description of how to use OpenMP, which flag
(which is -fopenmp), etc.
Without documentation, it is impossible for ordinary users to use the Gomp
OpenMP implementation.
--
Summary: No flag documentation for gomp (openmp)
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-05 15:29 ---
try --help -v.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24684
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-05 15:50 ---
Confirmed (reduced C or C++ testcase):
int* block;
void final(){
unsigned int i, j;
unsigned char* data = (unsigned char *)\0;
for (i = 0; i 8;i++)
for ( ;j + 63 1;j += 64)
block = (int*) data[j];
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-05 15:56 ---
Here is a reduced testcase without an uninitialized variable:
int* block;
void final(unsigned int j){
unsigned int i;
unsigned char* data = (unsigned char *)\0;
for (i = 0; i 8;i++)
for (;j + 63 1;j +=
--- Comment #5 from thebohemian at gmx dot net 2005-11-05 15:59 ---
Created an attachment (id=10153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10153action=view)
preliminary patch - just for review
Here is a first start for a patch that makes access to static methods lazy. The
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-05 16:00 ---
Honza, can you look at this? Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-05 16:01 ---
The reduced testcase in comment #7 fails also in 4.0.3 and 4.0.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-05 16:10
---
And here is a testcase which fails in 3.4.5 and above:
int* block;
void final(unsigned int j){
int * lsm_tmp1;
unsigned char * data;
unsigned int i;
data = (unsigned char *) ;
lsm_tmp1 = block;
i = 0;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
GCC target triplet|x86_64-unknown-linux-gnu
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 16:34 ---
Comment #5 is not helpful. Why is this a loop.c bug, you think? In my
backtrace we bail out from regmove. It would be far more helpful if you'd add
some explanation for why you think this is a loop.c bug.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-05 16:55 ---
Breakpoint 4, emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140
3140 enum machine_mode mode = GET_MODE (x);
(gdb) p debug_rtx(x)
(reg:DI 68)
$10 = void
(gdb) p debug_rtx(y)
(const:DI (plus:DI
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-05 16:59 ---
ICE on a primary platform, in a popular package.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2005-11-05 17:22 ---
This is clearly nonsense. Although the type my_t is PUBLIC,
its components are not.
No, this is not nonsense, just incorrect. See PR16404 and the discussion about
test #6.
I have incompletely applied the
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-05 17:26
---
(In reply to comment #13)
ICE on a primary platform, in a popular package.
As I mentioned in another bug, I think Mark should be the only one which
changes the Priority.
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-05 17:31
---
(In reply to comment #14)
(In reply to comment #13)
ICE on a primary platform, in a popular package.
As I mentioned in another bug, I think Mark should be the only one which
changes the Priority.
I should
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-05 17:47
---
And here is one which also fails in 3.3.6:
int final(int j){
unsigned int i = 0;
do {
if (j)
j = (__SIZE_TYPE__)[4294967233];
i = i + 1;
} while (i != 8);
return j;
}
--
pinskia at gcc
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-05 17:48
---
(In reply to comment #16)
And here is one which also fails in 3.3.6:
Hmm but passes in 4.0.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-05 17:50
---
Note that the original problem, ICE in kdenetwork3 only happens with mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #10 from jblomqvi at cc dot hut dot fi 2005-11-05 18:07 ---
Updated**2 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
--- Comment #2 from jblomqvi at cc dot hut dot fi 2005-11-05 18:08 ---
Patch (that also fixes PR 24174) here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-11-05 18:12 ---
(In reply to comment #5)
(In reply to comment #4)
We need to settle what kind of disk image we want for real(kind=10)
before resolving this for complex.
I am strongly in favour of real(kind=10) being written
--- Comment #7 from ron_hylton at hotmail dot com 2005-11-05 18:49 ---
(In reply to comment #5)
I tried out a few cross compilers for i686-pc-cygwin over the last few
months. The code compiled cleanly on 20040607. Sometime between then
and 20040709 it started failing with a
--- Comment #8 from ron_hylton at hotmail dot com 2005-11-05 18:51 ---
Created an attachment (id=10154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10154action=view)
modified test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-05 19:25 ---
This works with the 5 extra patches I have in my tree for VLA support
(same problem as on libgomp/testsuite/libgomp.fortran/vla1.f90).
--
jakub at gcc dot gnu dot org changed:
What|Removed
Seems that the parsing routines cannot deal with big values:
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
program huge_real10_formatted
! This should be kind=10 on systems that support it
integer, parameter :: k = selected_real_kind (precision (0.0_8) + 1)
--- Comment #6 from shap at eros-os dot org 2005-11-05 19:44 ---
I know you folks have many other things to do, but any further ideas on this
one? If not, what can I do to help get the test case confirmed and into the
regression suite?
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-05 20:30 ---
Something is not gimplifing an expression:
*(struct RegisterLayoutD.2065 *) (charD.3 *) SimulatedRegistersD.2082
--
# SimulatedRegistersD.2082_6 = V_MAY_DEF SimulatedRegistersD.2082_5;
((struct
--- Comment #23 from olh at suse dot de 2005-11-05 20:31 ---
this patch works, tested with r106530
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 20:34 ---
Lattice value changed to CONSTANT ((struct RegisterLayout *) (char *)
SimulatedRegisters)-intmask. Adding SSA edges to worklist.
Substituing values and folding statements
Folded statement: mpMaskRegister.0_4 =
--- Comment #3 from tkoenig at gcc dot gnu dot org 2005-11-05 21:53 ---
(In reply to comment #2)
Note there are still some more 2k5/6 SPEC blocking bugs which just had not
been
filed yet.
Well, can anybody file them? I don't have access to the SPEC suite.
--
tkoenig at gcc dot
--- Comment #5 from tkoenig at gcc dot gnu dot org 2005-11-05 22:05 ---
Hmm... in this case, I think we should document that only 0 and 1
are valid for logical types, and if the user stuffs anything else
into one of our logicals, he is on his own.
After we have documented this, we can
--- Comment #11 from tkoenig at gcc dot gnu dot org 2005-11-05 22:21
---
OK, for the interface...
My suggestion would be to have three levels of supplying this value (ifort
has five or six :-)
First, an option to supply to the compiler. This could be
-fconvert=big_endian
We have a customized version of the NMSTL library, and get an ICE when we build
it. (Sorry, I couldn't find directions on how to fill out Host triplet, Target
triplet, and Build triplet.)
I'm using Ubuntu Linux 5.10.
--
Summary: ICE when building a variation of NMSTL
--- Comment #1 from christian dot convey at gmail dot com 2005-11-05 22:35
---
Created an attachment (id=10155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10155action=view)
stdout/stderr from the build process that cause the ICE
--
--- Comment #2 from christian dot convey at gmail dot com 2005-11-05 22:37
---
Created an attachment (id=10156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10156action=view)
Preprocessed output file 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
--- Comment #3 from christian dot convey at gmail dot com 2005-11-05 22:40
---
Created an attachment (id=10157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10157action=view)
Preprocessed output file 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 22:42 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE
testcase:
typedef struct {
}
extern C++ {
}
extern C {
templatetypename _Tp struct __is_pod { enum {
__value = (sizeof(__gnu_internal::__test_type_Tp(0))!=
sizeof(__gnu_internal::__one)) }; };
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-05 22:55 ---
Note I found this while reducing PR 24686
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-05 23:06 ---
I did some further research, and while g77 didn't seem to have documented any
of the details of how LOGICALs are implemented, we have the following in
gfortran.texi:755:
@node Implicitly interconvert LOGICAL and
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-11-05 23:20 ---
(In reply to comment #6)
I think we should be consistent.
g77 also gives inconsistent results with the test program:
$ cat logic.f
program main
implicit none
logical :: lo1, lo2
integer
--- Comment #6 from kazu at gcc dot gnu dot org 2005-11-05 23:23 ---
Reduced down to:
void
foo (unsigned long *a, unsigned long long *p)
{
if (*p == 0)
*p = *a;
}
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-05 23:24
---
Looking at the difference, there also seems to be some problem with
arithmetic..
No, it's only that the default format is not wide enough :)
Compared to other compilers, we could probably do something like:
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-05 23:32 ---
Reduced down to:
void
foo (unsigned long *a, unsigned long long *p)
{
*p = *a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23435
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-05 23:46 ---
As far as I can see this is valid code (the machine which was doing the
reduction crashed or something because I cannot connect to it).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-05 23:47 ---
Backtrace:
#0 0x0813611e in decl_linkage (decl=0xb7ce1870) at
/home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/tree.c:2171
#1 0x080dc7f2 in retrofit_lang_decl (t=0xb7ce1870) at
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-05 23:51 ---
Reduced as far as I can get it:
extern C {
templatetypename _Tp struct __is_pod {
enum {
__value = (sizeof(__gnu_internal::__test_type_Tp(0)))};
--
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-05 23:53 ---
Fixed in current CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from kargl at gcc dot gnu dot org 2005-11-06 00:02 ---
The code is illegal, so every compiler has produced a
correct result.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org
|dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-06 00:18 ---
Confirmed, reduced testcase:
struct string {
struct _Alloc_hider {
~_Alloc_hider();
};
mutable _Alloc_hider _M_dataplus;
};
templateclass T string to_string(const T t);
struct debug_msg {
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-06 00:22 ---
Note -fno-threadsafe-statics makes this works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-06 00:22 ---
One can get quite interesting results out of g77, e.g.
[EMAIL PROTECTED]:~/src/tests cat ugly.f
LOGICAL L, M
equivalence (i,l)
DO i=0,5
M = i
PRINT (5l2), l, m, l.neqv..true.,
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
I'm trying to bootstrap gcc-3.4.3 on HP-UX 11.23/IA-64. I'm bootstrapping with
the HP C compiler. The system has patch PHSS_33351 installed. The tail of
/usr/include/math.h:
inline int sqr(int __x) {return(__x*__x);}
inline double sqr(double __x) {return(__x*__x);}
# ifndef _STDLIB_INCLUDED
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 00:24 ---
I thought this was fixed in 3.4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
--- Comment #10 from kargl at gcc dot gnu dot org 2005-11-06 00:32 ---
Do we care? Equivalencing integer and logical is prohibited
(although we don't warn about this with --std=f95; maybe
that is the error).
Thomas, can you point to the text in the standard that
prohibits the
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-06
00:45 ---
I'm using the version of inclhack.def from gcc-3_4-branch. I looked at the
changes in
http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/fixinc/inclhack.def?rev=100333view=log
and don't see anything
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-06 00:55
---
I thought that a key observation is that we only need to know (a) what empty
subobjects are at offset zero, and (b) what empty subobjects occur before the
location where we will next place a non-empty field or
--- Comment #3 from rth at gcc dot gnu dot org 2005-11-06 00:55 ---
Subject: Bug 24612
Author: rth
Date: Sun Nov 6 00:55:43 2005
New Revision: 106551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106551
Log:
PR middle-end/24612
* omp-low.c
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-06 00:56 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from paolo at gcc dot gnu dot org 2005-11-06 01:12 ---
Subject: Bug 23953
Author: paolo
Date: Sun Nov 6 01:12:23 2005
New Revision: 106553
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106553
Log:
2005-11-05 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #8 from pcarlini at suse dot de 2005-11-06 01:13 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #9 from pcarlini at suse dot de 2005-11-06 01:13 ---
Oops...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-06 01:20 ---
Oh well, I'll try and fix this...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-06 02:10 ---
Reduced down to:
void bar (unsigned int);
void
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
switch (**q)
{
case 1: ch = 5; break;
case 2: ch = 4;
Consider:
extern void bar (unsigned int);
int
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
switch (**q)
{
case 1: ch = 5; break;
default: ch = 0; break;
}
#if 1
bar (ch);
#endif
return ch;
}
This function should be
Using TinyVector from the Blitz++ C++ library (http://www.oonumerics.org/b as a
temporary to initialize a default constructor values gives errors. The actual
code follows. Preprocessed code attached.
#include blitz/tinyvec-et.h
class Foo
{
blitz::TinyVectordouble, 3 x;
--- Comment #1 from faheem at email dot unc dot edu 2005-11-06 03:05
---
Created an attachment (id=10158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10158action=view)
Preprocessed file showing the error
Error is:
foo.cc:15: error: type specifier omitted for parameter
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org
|dot org
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-06 04:25 ---
Not reproducible using x86_64-pc-linux-gnu X m68k-none-elf.
Paul, is this still reproducible?
I also tried, gcc.c-torture/execute/920501-6.c, but I didn't get any ICE.
--
kazu at gcc dot gnu dot org changed:
--- Comment #15 from kazu at gcc dot gnu dot org 2005-11-06 04:28 ---
Not reproducible using x86_64-pc-linux-gnu X m68k-none-elf.
I'm using mainline for the cross compiler.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 04:34 ---
Looks like another one of the call clobbered bugs:
Variable: buf, UID 1612, char[1], is an alias tag, is addressable, call
clobbered, default def: buf_2
Though that should not matter.
Here is a testcase where call
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 04:37 ---
This is a dup of bug 57. There is still an open question in the C++ standards
committee if this is valid or invalid code. So right now GCC is correct.
*** This bug has been marked as a duplicate of 57 ***
--
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-11-06 04:37
---
*** Bug 24690 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 04:47 ---
Note switch statements here have nothing to do with the real issue:
extern void bar (unsigned int);
extern void bar1 (const char **);
int
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-06 04:50 ---
(In reply to comment #0)
This function should be optimized to return 0;, but it isn't.
Interestingly, if you change #if 1 to #if 0, you are going to get
this optimized.
Not really because SRA works then, using
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-06 04:52 ---
Here is another testcase:
extern void bar (unsigned int);
extern void bar1 (const char **);
char buf[1];
int
foo (void)
{
const char *p = buf;
const char **q = p;
buf[0] = 3;
unsigned int ch;
if(**q)
1 - 100 of 107 matches
Mail list logo
