--- Comment #3 from jakub at gcc dot gnu dot org 2005-12-07 08:18 ---
BTW, is the s390 hw really masking the shift count with 63 for all insns,
or just the DImode shifts and with 31 for SImode shifts?
I'd say targets masking the shift count to number of bits of *shift3's
mode is very com
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-12-07 08:29
---
> I bootstrapped this on i686-pc-linux-gnu, all languages. Eric, can you test
> it on a non-C99 platform?
I don't seem to be able to regenerate aclocal.m4 and configure correctly, so
the new test GCC_HEADER_STDI
Code is extracted from WINE.
gcc version 4.2.0 20051206 (experimental)
/home/marcus/projects/gcc/BIN/bin/gcc -c typelib.i -O2 -Wall
typelib.i: In function ‘ITypeLibComp_fnBind’:
typelib.i:11: internal compiler error: tree check: expected tree that contains
‘decl common’ structure, have ‘struct_fie
--- Comment #1 from marcus at jet dot franken dot de 2005-12-07 08:51
---
Created an attachment (id=10432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10432&action=view)
typelib.i
gcc -O2 -c typelib.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25291
--- Comment #2 from marcus at jet dot franken dot de 2005-12-07 09:31
---
4.2 actually
--
marcus at jet dot franken dot de changed:
What|Removed |Added
Versio
The ASSOCIATED statement with function argument is rejected by gfortran.
ifort, g95, pgf90, pathf90, sunf90, xlf90 all happily accept the (somewhat
silly) program below with expected results?
Regards, Juha
program test
real, pointer :: a
allocate(a)
print*,associated( x(a) )
contains
--- Comment #3 from andraz dot tori1 at guest dot arnes dot si 2005-12-07
10:29 ---
this is really a shame, long long is really usefull to have, and from what i
gathered it was not so hard to fix...
http://gcc.gnu.org/ml/libstdc++/2003-10/msg2.html
--
http://gcc.gnu.org/bugzil
--- Comment #4 from barbieri at gmail dot com 2005-12-07 10:49 ---
So, this is a bug.
I just need a confirmation if it's a bug in the middle-end layer, so there is
already a patch, or if this is a bug in the front-end, then I will add the
check to the gimplify code.
Since there is no d
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-12-07
10:52 ---
Subject: Re: bootstrap failures on non-C99 platforms
>>I bootstrapped this on i686-pc-linux-gnu, all languages. Eric, can you test
>>it on a non-C99 platform?
>>
>>
>I don't seem to be able to rege
/* { dg-options "-m32 -mpreferred-stack-boundary=2 -mtune=i586 -O2
-fomit-frame-pointer -g" } */
struct T { unsigned short t1, t2, t3, t4, t5, t6, t7; };
struct S { struct T s1; unsigned short s2, s3; };
unsigned short v1;
int f1 (void);
int f2 (struct T);
int f3 (const char *);
int
foo (struct S
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-12-07 11:12
---
I ran into this on i586 too.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from krebbel at gcc dot gnu dot org 2005-12-07 11:26 ---
(In reply to comment #3)
> BTW, is the s390 hw really masking the shift count with 63 for all insns,
> or just the DImode shifts and with 31 for SImode shifts?
On S/390 all shift count operands are masked with 63. SI
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-12-07 11:31
---
> You have to do "aclocal -I ../config", or you can configure with
> --enable-maintainer-mode.
Ah, thanks. It fails very early though:
In file included from /home/eric/svn/gcc/libdecnumber/decContext.h:43,
--- Comment #9 from aldyh at gcc dot gnu dot org 2005-12-07 11:37 ---
Subject: Bug 24138
Author: aldyh
Date: Wed Dec 7 11:37:53 2005
New Revision: 108157
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108157
Log:
PR C++/24138
* tree.c (integer_all_onesp): Always
--- Comment #10 from aldyh at gcc dot gnu dot org 2005-12-07 11:38 ---
fixed on 4.1 branch as well
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2005-12-07 12:06 ---
Oops, sorry for not RTFSing before posting the comment here.
All I did was verify that x86_64 doesn't remove useless ANDs.
Should we add new peepholes or insns patterns to i386 for this too?
--
http://gcc.gnu.org/
--- Comment #7 from andreas at florath dot net 2005-12-07 12:37 ---
--- gcc-4.1-20051202 ---
Same behaviour: ICE compiling tar.
I run the testsuites, once for (3):
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00372.html
(3 ICEs)
and once for (5):
http://gcc.gnu.org/ml/gcc-testresu
--- Comment #6 from amodra at bigpond dot net dot au 2005-12-07 12:42
---
I'm willing to write a patch for this as I'm inclined to think that changing
gcc --print-search-dirs is the best way to make gcc/libtool work together. A
typical linux distribution contains many packages with dif
--- Comment #7 from dje at gcc dot gnu dot org 2005-12-07 13:19 ---
Changing the behavior of GCC -print-search-dirs is a bad idea and will break
other applications relying on the current behavior. Introducing a major
incompatibility into GCC is not a solution and I strongly oppose the p
--- Comment #1 from hp at gcc dot gnu dot org 2005-12-07 13:20 ---
I also see this on x86_64-unknown-linux-gnu (FC4).
All targets using a combined tree (with CVS binutils).
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-12-07 13:28
---
> I run the testsuites, once for (3):
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00372.html
> (3 ICEs)
The configure line doesn't match the title of the report: the compiler has been
configured as a nativ
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Component|preprocessor|other
Priority|P3 |P2
http://g
--- Comment #22 from amylaar at gcc dot gnu dot org 2005-12-07 13:31
---
Subject: Bug 20070
Author: amylaar
Date: Wed Dec 7 13:31:41 2005
New Revision: 108164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108164
Log:
2005-12-07 J"orn Rennecke <[EMAIL PROTECTED]>
Pre
--- Comment #8 from amodra at bigpond dot net dot au 2005-12-07 13:49
---
There is no appropriate gcc option. Some paths printed by -print-search-dirs
need the suffix printed by -print-multi-os-directory, others need the suffix
printed by -print-multi-directory. How is libtool suppose
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE in tree-check |[4.
--- Comment #3 from dberlin at gcc dot gnu dot org 2005-12-07 14:05 ---
Mine
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-07 14:09 ---
*** Bug 25293 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-12-07 14:09 ---
*** This bug has been marked as a duplicate of 25023 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
OS: Fedora Core 4 (linux 2.6.14)
output of gcc -v:
Using built-in specs.
Target: i386-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
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 14:45 ---
Confirmed a regression from 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 14:47 ---
Another example which shows this is specific to the C++ front-end:
struct f{
#pragma pack(1) /* Start comment
end comment on next line */
};
int main(int argc, char *argv[])
{
return 0;
}
The attached code compiled with the command line below results in the following
assembly that saves an unused register (r8) in the function prolog.
gcc -fno-strict-aliasing -fno-common -ffreestanding -Os
-fomit-frame-pointer -march=nocona -ffixed-r10 -mno-red-zone -mcmodel=kernel
-pipe -fno-re
--- Comment #1 from bcrl at kvack dot org 2005-12-07 15:10 ---
Created an attachment (id=10433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10433&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25295
--- Comment #7 from martinol at nrlssc dot navy dot mil 2005-12-07 15:28
---
Since g77 supported this construct, should this not be a regression rather than
an enhancement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
--- Comment #6 from jakub at gcc dot gnu dot org 2005-12-07 15:32 ---
Created an attachment (id=10434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10434&action=view)
gcc41-s390-shift-and.patch
How does this patch look like then? Sorry for not waiting for your patch,
but I need
--- Comment #6 from amodra at gcc dot gnu dot org 2005-12-07 16:07 ---
Subject: Bug 25212
Author: amodra
Date: Wed Dec 7 16:07:08 2005
New Revision: 108167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108167
Log:
PR target/25212
* config/rs6000/rs6000.c (legit
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2005-12-07
16:14 ---
Can we please have the fix for PR 14024 backported into gcc 4.1? It will be
very difficult
to get upstream packages like swig for c++ fixed with regards to the
dereferencing type-punned
pointers breaking st
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-07 16:19 ---
(In reply to comment #6)
> Can we please have the fix for PR 14024 backported into gcc 4.1? It will be
> very difficult to get upstream packages like swig for c++ fixed with regards
> to the
> dereferencing type-pun
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-07 16:26 ---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from krebbel at gcc dot gnu dot org 2005-12-07 16:26 ---
Created an attachment (id=10435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10435&action=view)
Patch without testcase
I've bootstrapped the attached patch on s390 and s390x without
testsuite regressions.
T
--- Comment #8 from mueller at kde dot org 2005-12-07 16:33 ---
that comparison isn't quite fair. strict aliasing is an optimisation that
breaks code when compiled with a newer version of gcc, and there is lots of
code to fix because of that.
Sure, you can fix it by reading through all
--- Comment #5 from dorit at il dot ibm dot com 2005-12-07 16:35 ---
> What's the best approach to fixing this? Punting in vectorizable_reduction
> if we know beforehand that the loop will be versioned?
> /* Same if the loop is to be versioned. */
> if (VEC_length (tree, LOOP_VINFO
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-07 16:38 ---
(In reply to comment #8)
> that comparison isn't quite fair. strict aliasing is an optimisation that
> breaks code when compiled with a newer version of gcc, and there is lots of
> code to fix because of that.
Actu
--- Comment #4 from dberlin at gcc dot gnu dot org 2005-12-07 16:39 ---
Subject: Bug 25291
Author: dberlin
Date: Wed Dec 7 16:39:33 2005
New Revision: 108168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108168
Log:
2005-12-07 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR
I am an adamant user of const, as it helps checking the code with (by way of
the compiler) for stupid errors, helps with defining what is happening and
gives the compiler more help optimisation.
I had tried something that I think should have work as promoting a type to a
const type should be strai
--- Comment #5 from dberlin at gcc dot gnu dot org 2005-12-07 16:40 ---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from adrian dot hawryluk at gmail dot com 2005-12-07 16:42
---
Created an attachment (id=10436)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10436&action=view)
Source file for test.
Complete source file of offending example.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** This bug has been marked as a duplicate of 20857 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 25074 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** This bug has been marked as a duplicate of 20857 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 20859 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
--- Comment #4 from tobi at gcc dot gnu dot org 2005-12-07 16:49 ---
These all amount to the same problem. Being a bit more descriptive would also
make searching for duplicates easier.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from jakub at gcc dot gnu dot org 2005-12-07 16:52 ---
Created an attachment (id=10437)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10437&action=view)
gcc41-pr25268.patch
Ok (not sure if it really is a good idea to make the *_operand names that
long), just I'm afr
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 17:06 ---
The warning is correct as the const "promotion" only applies to the outer most
type. so that const int * const is imcompatible with int *.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
*** Bug 19866 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
To close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
*** Bug 25296 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
Reoepening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-07 17:09 ---
To Close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-07 17:09 ---
*** Bug 24727 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-12-07 17:10
---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-12-07 17:10
---
To close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-07 17:10 ---
*** Bug 20230 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:12 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:12 ---
To close as a dup of bug 14557.
*** This bug has been marked as a duplicate of 14557 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-12-07 17:12
---
*** Bug 8262 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
>From an old SGI Fortran-77 Language Reference Manual:
"The RECORD statement creates a record in the format specified by a previously
declared STRUCTURE statement. The effect of a RECORD statement is comparable
to that of an ordinary type declaration."
"The STRUCTURE statement defines a record s
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 17:19 ---
Why can't you use the standard Fortran 90/95 derived types?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25297
--- Comment #9 from krebbel at gcc dot gnu dot org 2005-12-07 17:33 ---
(In reply to comment #8)
> Ok (not sure if it really is a good idea to make the *_operand names that
> long),
Mmmh you are right but I couldn't think of a better name that moment.
just I'm afraid ashrdi3_cc_64_and,
--- Comment #2 from martinol at nrlssc dot navy dot mil 2005-12-07 17:37
---
I require a library that is not under my control to change (I have the source,
but am not the primary developer) and it was written using the SGI f77
compiler. I would like to see this construct added to gfort
Compiling the source below with avr-gcc 4.0.2 gives an "invalid lvalue in
assignment":
--
#include
int main(void)
{
(unsigned char)DDRD |= (unsigned char)(1 << 7);
return 0;
}
--
The same code above builds fine for avr-gcc 3.4.3. The issue has to do with
--- Comment #1 from eweddington at cso dot atmel dot com 2005-12-07 18:01
---
Created an attachment (id=10438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10438&action=view)
Preprocessed test case.
Attaching a preprocessed testcase using 4.0.2.
--
http://gcc.gnu.org/bugzil
--- Comment #8 from jakub at gcc dot gnu dot org 2005-12-07 18:12 ---
I believe negative CFA offsets that aren't a multiple of 4 aren't representable
in DWARF 3, so either we'd have to lie in the unwind info, or we shouldn't
be misaligning the stack pointer ever.
--
http://gcc.gnu.o
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 18:16 ---
This is invalid C and in fact we removed the extension for 4.0.x.
See http://gcc.gnu.org/gcc-4.0/changes.html
And http://gcc.gnu.org/gcc-3.4/changes.html
which talks about this extension.
--
pinskia at gcc dot gn
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-12-07 18:18
---
[Thanks for the very detailed plan.]
> You can assign this to me, but I won't be able to get to this for the next
> week, so maybe I better have it assigned to me when I actually have time to
> work on this (in a
--- Comment #9 from rth at gcc dot gnu dot org 2005-12-07 18:21 ---
Indeed we shouldn't be mis-aligning the stack pointer. And if you look at
the actual assembly, we aren't. Therefore the problem is bogus debug info.
I had been looking at this PR for a while, but got sidetracked. I s
--- Comment #3 from eweddington at cso dot atmel dot com 2005-12-07 18:24
---
Thanks for pointing this(In reply to comment #2)
> This is invalid C and in fact we removed the extension for 4.0.x.
> See http://gcc.gnu.org/gcc-4.0/changes.html
> And http://gcc.gnu.org/gcc-3.4/changes.html
--- Comment #10 from jakub at gcc dot gnu dot org 2005-12-07 18:27 ---
The stack is misaligned, though not at any call insn:
subl$2, %esp
movl40(%esp), %eax
pushl %eax
movl40(%esp), %eax
pushl %eax
movl40(%esp), %eax
--- Comment #20 from bkoz at gcc dot gnu dot org 2005-12-07 19:01 ---
> I have customers using Obj C++ who want to turn off C++
> exception support, but retain Obj C exception support. [snip]
What does this even mean? Can you detail or explain how this is supposed to
work?
> They are
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-12-07 19:32
---
Subject: Bug 22618
Author: reichelt
Date: Wed Dec 7 19:32:17 2005
New Revision: 108173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108173
Log:
Backport:
2005-10-20 Mark Mitchell <[EM
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-12-07 19:34
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19397
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #4 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19764
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19762
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #4 from reichelt at gcc dot gnu dot org 2005-12-07 19:42
---
Fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from reichelt at gcc dot gnu dot org 2005-12-07 19:43
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-12-07 19:44
---
Fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from berndtrog at yahoo dot com 2005-12-07 19:55 ---
patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01887.html
--
berndtrog at yahoo dot com changed:
What|Removed |Added
-
The following source should compile on powerpc-darwin with no errors:
struct a { double a[2]; int i; };
struct b { double a; double b; int i; };
int g[sizeof(struct a) == sizeof(struct b)?1:-1];
But currently it does not because we don't take into account that the type of
the array.
--
The testcase g++.dg/template/inherit.C causes an ICE on the 4.1 branch
and mainline:
=
template
struct X { void f() { } };
struct Z : X { };
int main()
{
Z z;
z.X::f(); // { dg-error ".*" "" }
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 20:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |other
Summary|ld segmentation fault |[4.1/4.2 Regres
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 20:26 ---
>From the sound of it, AIX has the same issue. I have the simple fix but I
cannot test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25299
The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
A reduced testcase is:
===
typedef struct A B;
int i = sizeof(B);
===
bug.c:2: error: invalid application of `sizeof' to incomplete type `
Internal compiler error: Error reporting ro
The comment on top of the testcase gcc.dg/noncompile/920923-1.c reads:
/* This test case contains a large number of syntactic errors. We
believe the intent of the test is that the compiler simply not
crash. The set of error messages reported is different when the C
parser is gen
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-12-07 20:38
---
The PR for the testcase in the testsuite is PR 25302.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
| A reduced testcase is:
|
| ===
| typedef struct A B;
| int i = sizeof(B);
| ===
|
| bug.c:2: error: invalid applica
1 - 100 of 148 matches
Mail list logo
