I just tried, what I thought to be default enabled, to build a
multilibbed gcc mainline. However, when I run the testsuite with -m64
flag, I get warnings like this (this is from gcc testsuite)
Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc
-B/usr/local/src/trunk/objdir32/gcc/ -O0 -w
[EMAIL PROTECTED] wrote on 17/07/2005 08:30:26:
Michael Veksler [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
|
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| | Anything it sees anything in a statement with volatile, it marks
the
| | statement as
| From: Gabriel Dos Reis [EMAIL PROTECTED]
|
| D. Hugh Redelmeier [EMAIL PROTECTED] writes:
|
| | | From: Gabriel Dos Reis [EMAIL PROTECTED]
| |
| | | After many exchanges via private mails and
| | | looking at the various reports related to this issue, it has become
| | | clear to me that the
On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
Andrew Pinski has declared this to be a bug, but the audit trail
isn't clear as to why.
Because the abs is a function call, there is only one load and should
be only
one load as
| From: Daniel Berlin [EMAIL PROTECTED]
| On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
| | From: Gabriel Dos Reis [EMAIL PROTECTED]
|
| | After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that
Daniel Berlin [EMAIL PROTECTED] writes:
In other words, we're asked to agree that the type of an object
changes depending on how it is accessed.
For the benefit of readers, only the first sentence of this para is
the language of the standard; the rest isn't.
That an object referred
Gabriel Dos Reis writes:
Daniel Berlin [EMAIL PROTECTED] writes:
| | There is no point in type qualifiers if they can be simply changed at
| | will. Do not lie about your objects, and you will not be screwed over.
|
| only if the language you're implementing the compiler for
Andreas Schwab [EMAIL PROTECTED] writes:
Andreas Jaeger [EMAIL PROTECTED] writes:
I know have a problem building gcc mainline with a parallel build on
Linux/x86-64:
/usr/include/java/net/URL.h:25: error: global qualification of class name is
inva
lid before ':' token
R Hill wrote:
Richard Guenther wrote:
On 7/14/05, Richard Guenther [EMAIL PROTECTED] wrote:
As subject says - on x86_64 it takes a whopping 30 minutes to
compile said with -fprofile-generate!
It's caused by -frename-registers enabled by -funroll-loops. Compiling
with -O2 -fno-unroll-loops
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
|
| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
|
| Andrew Pinski has declared this to be a bug, but the audit trail
| isn't clear as to why.
|
| Because the abs is a function call,
D. Hugh Redelmeier [EMAIL PROTECTED] writes:
[...]
| | At this point we need:
| | (1) agreement from C and C++ maintainers on access through volatile
| | lvalue
|
| I don't know C++ well enough to say whether the analogous optimization
| is wrong for C++.
C++ has resisted, for two
Andrew Haley [EMAIL PROTECTED] writes:
[...]
| You know, the more this goes on the more I believe we should send
| X3J11 a request for clarification. Perhaps X3J11 has been disbanded,
| so there may be problems. But we should ask.
I don't know whether X3J11 is disbanded. However, at the last
On Sun, 17 Jul 2005, Gabriel Dos Reis wrote:
D. Hugh Redelmeier [EMAIL PROTECTED] writes:
| | From: Gabriel Dos Reis [EMAIL PROTECTED]
|
| | After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that the
% ../gcc-4.0.1/config.guess
powerpc-apple-darwin6.8
% /usr/local/bin/g++-4.0.1 -v
Using built-in specs.
Target: powerpc-apple-darwin6.8
Configured with: ../gcc-4.0.1/configure --program-suffix=-4.0.1
--enable-languages=c,c++ --enable-threads=posix : (reconfigured)
../gcc-4.0.1/configure
Tom Tromey dixit:
I'm finally ready to check in the big classpath merge, and I wanted to
post a short warning before I went ahead with it.
Is it possible to use a current libgcj or classpath with gcc 3.4?
Thanks,
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit
On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
Daniel Berlin [EMAIL PROTECTED] writes:
| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching
Daniel Berlin [EMAIL PROTECTED] wrote on 17/07/2005 17:33:17:
On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
[...]
I can't agree with that as is. I would refine it to:
Anything that *does* optimizes away visible reads or writes of
something marked volatile is buggy.
I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
node itself, rather than only on the this pointer argument.
this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv
qualified member function. Should it be itself (thereby breaking the invariant
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
Speaking with the optimizer hat on, we *don't* do much
Richard Henderson wrote:
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
yeah, I can understand that :)
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
http://people.redhat.com/dnovillo/spec2000/gcc/log/20050717/spec-20050717.stats
Sadly, the SPEC box only measures rounded numbers for the build times, so
the places where there is no measured slowdown may actually have slowed
down as well, but there is no way to tell from this data.
CFP2000 BASE
Richard Henderson [EMAIL PROTECTED] writes:
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
Case 1:
void
On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
Issue 1.
void Foo (char *ptr) {
*(volatile char *)ptr;
}
...
char c;
*(volatile char *)c; // can this read be deleted?
...
void Foo (volatile char *ptr) {
*(char *)ptr;
I did see Ian's summary,
Richard Henderson [EMAIL PROTECTED] writes:
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
As I read the
On Sun, Jul 17, 2005 at 09:18:01AM -0700, Ian Lance Taylor wrote:
This is PR 22278. DannyB posted a simple, untested, patch here:
http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
Thanks. I think Danny's patch attacks this too late. The
following patch appears to do the right thing with
Richard Henderson [EMAIL PROTECTED] writes:
| On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
| Issue 1.
| void Foo (char *ptr) {
|*(volatile char *)ptr;
| }
| ...
| char c;
| *(volatile char *)c; // can this read be deleted?
| ...
| void Foo (volatile char *ptr) {
|
Vincent == Vincent Lefevre [EMAIL PROTECTED] writes:
Vincent On 2005-07-12 23:42:23 +0200, Erik Trulsson wrote:
Pointer subtraction is only well defined if both pointers point to
elements in the same array (or one past the end of the array).
Vincent I don't know what you mean by well
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
Hi,
There are some huge compile time regressions between 16/7 and 17/7, most
likely due to the IPA work from Kenny and Dan.
Definitely.
The peak compile time slowdown is due to the promote statics pass, which
in term causes more work
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
Hi,
There are some huge compile time regressions between 16/7 and 17/7, most
likely due to the IPA work from Kenny and Dan. These are the build times
in seconds, taken from Diego Novillo's nightly SPEC tester box:
As i expected, the
I did see Ian's summary,
http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html
wherein he ascribed the semantics of the volatile qualifier to the
access, and not to the object. I agree with his description completely,
as I believe it embodies the intuition that C programmers have used
wrt
On Sunday 17 July 2005 19:48, Daniel Berlin wrote:
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
Hi,
There are some huge compile time regressions between 16/7 and 17/7, most
likely due to the IPA work from Kenny and Dan. These are the build times
in seconds, taken from
On Sun, Jul 17, 2005 at 01:48:44PM -0400, Daniel Berlin wrote:
As i expected, the sixtrack slowdown is entirely in global-alloc, in
daten.f
with -fno-tree-promote-statics
global alloc : 0.23 ( 4%) usr 0.00 ( 0%) sys 0.24 ( 3%)
wall 448 kB ( 3%) ggc
without:
global
200.sixtrack 74 258 348.65%
I can get this down to something slightly more sane (cut down
global-alloc time by 80%) by upping the global var threshold.
The problem is that the global var threshold causes us to make all the
promoted statics touch the global var.
#
Tut mir leid ich glaube ich habe die email an den falschen geschickt sorry
vielmalls wird nicht wieder vorkommen ich habe ein problem mit meinem outlok
express sorry vielmalls der link
http://search.ebay.de/_W0QQsassZwww_get-time_deQQhtZ-1 war nicht für dich
gedacht .
Tut mir leid !!
Tut mir leid ich glaube ich habe die email an den falschen geschickt sorry
vielmalls wird nicht wieder vorkommen ich habe ein problem mit meinem outlok
express sorry vielmalls der link
http://search.ebay.de/_W0QQsassZwww_get-time_deQQhtZ-1 war nicht für dich
gedacht .
Tut mir leid !!
Nathan Sidwell wrote:
I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
node itself, rather than only on the this pointer argument.
I don't think that's a good idea. The const on the member function
really does apply to the type pointed to be the this pointer,
Daniel Berlin wrote:
On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
| I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I hope
I have some problems with using inline PowerPC assembly in GCC (4.0.1).
Consider the following code:
void save_fp_register(double* buffer)
{
asm(stfd F0, 0(%0) : : r (buffer) );
}
When compiled with -Os the generated code becomes
save_fp_register:
stfd F0, 0(3)
Stefan writes:
Stefan I have some problems with using inline PowerPC assembly in GCC (4.0.1).
Stefan Consider the following code:
Stefan void save_fp_register(double* buffer)
Stefan {
Stefan asm(stfd F0, 0(%0) : : r (buffer) );
Stefan }
Use constraint b.
David
Hi All,
What is the best way of including target-specific files in the
version-specific gcc library directory? I need to include a
file that will be referenced from LINK_SPEC as gcc.map%s.
IE, in the same place the startup files are located. So
really I need to know two things:
1) How to I
On Jul 17, 2005, at 19:15, Stefan wrote:
I have some problems with using inline PowerPC assembly in GCC
(4.0.1). Consider the following code:
void save_fp_register(double* buffer)
{
asm(stfd F0, 0(%0) : : r (buffer) );
}
Try using 'b' for the constraint - that selects for
Note that I'm explicitly not taking a position on what the standard says.
The standard is notoriously incomplete with respect to object model issues,
including volatility, so I think that trying particularly hard to parse its
words in this area is probably not a good use of time for people
On 2005-07-17 12:55:38 -0400, Paul Koning wrote:
Are you sayinvg that a-b is not always guaranteed to work when a
and b point to elements of the same array? That sounds wrong; can
you given an example or standards text that supports this?
6.5.6 Additive operators
[...]
[#9]
| From: Vincent Lefevre [EMAIL PROTECTED]
| To: gcc@gcc.gnu.org
| Subject: Re: Pointers in comparison expressions
|
| On 2005-07-17 12:55:38 -0400, Paul Koning wrote:
| Are you sayinvg that a-b is not always guaranteed to work when a
| and b point to elements of the same array? That sounds
I have recently been noticing inconsistent warnings when building GCC (for
example,
warnings about uninitialised variables in gcc/ddg.c). I had not realised it,
but the
top-level CFLAGS defaults to -g -O2 whereas gcc's Makefile sets CFLAGS to
-g by
default. So, if you compile this way:
cd
On Jul 18, 2005, at 12:32 AM, Ben Elliston wrote:
I have recently been noticing inconsistent warnings when building GCC
(for example,
warnings about uninitialised variables in gcc/ddg.c). I had not
realised it, but the
top-level CFLAGS defaults to -g -O2 whereas gcc's Makefile sets
CFLAGS
/source/gcc-mainline/gcc/ddg.c -o ddg.o
(using GCC 4.0.2 20050717)
[EMAIL PROTECTED]:~/build/gcc-mainline/gcc$ gcc -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werror -fno-common
Steve Kargl wrote:
On Tue, Jul 12, 2005 at 05:10:19PM -0500, Justin Thomas wrote:
I am a big fan of the GNU project and would really like to use
gfortran for Fortran development work on my 64-bit AMD Opteron machine
running Red Hat Linux. I cannot find any documentation on your
website at all,
Kean Johnston [EMAIL PROTECTED] writes:
What is the best way of including target-specific files in the
version-specific gcc library directory? I need to include a
file that will be referenced from LINK_SPEC as gcc.map%s.
IE, in the same place the startup files are located. So
really I need
On Sun, Jul 17, 2005 at 10:31:03PM -0700, Brooks Moses wrote:
Steve Kargl wrote:
On Tue, Jul 12, 2005 at 05:10:19PM -0500, Justin Thomas wrote:
I am a big fan of the GNU project and would really like to use
gfortran for Fortran development work on my 64-bit AMD Opteron machine
running Red Hat
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
07:48 ---
Is this before or after:
2005-07-13 David Edelsohn [EMAIL PROTECTED]
* tree-ssa-dom.c (lookup_avail_expr): Do not pass member in freed
structure as argument.
?
That patch should have
--- Additional Comments From hugh at mimosa dot com 2005-07-17 08:04
---
There is a thread on the gcc at gcc.gnu.org mailing list discussing this. A
possible fix to GCC4.x has been posted in that thread:
http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
08:09 ---
Confirmed, backtrace:
#0 0x0010c034 in is_gimple_variable (t=0x0) at ../../gcc/tree-gimple.c:239
#1 0x0010c70c in is_gimple_val (t=0x0) at ../../gcc/tree-gimple.c:366
#2 0x0012bd94 in
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr
2005-07-17 09:51 ---
Please let me know if the attached fixes it
Yes, it fixes my original report as well as the shorter testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22483
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-17 10:00
---
With mainline I still get no error. With 4.0.2 I get some errors and then the
final assertion is triggered (rather than a segfault) so using mudflap changes
the behaviour of the program:
g++40 -g -static
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-17 10:46
---
P.S. If I compile with -m32 I get 40 mudflap violations, but only one in 64-bit
mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22513
$ cat elem-char.f90
program main
character(len=2) :: a(2)
print *,foo(a)
contains
elemental function foo(a)
character(len=*), intent(in) :: a
character(len=*) foo
foo = a
end function foo
end program main
$ gfortran elem-char.f90
elem-char.f90: In function 'MAIN__':
elem-char.f90:3:
--
What|Removed |Added
BugsThisDependsOn||22518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
The memory layout of a real*10 variable on an i386 processor requires 12 or 16
bytes per variable, depending on the flag -m128bit-long-double. The disk
layout for unformatted (binary) writing occupies 10 bytes per variable.
This has several disadvantages. It is different from I would
This is actually applicable to every version of g++ I have on my system, not
just 4.0.1. I am tempted to say I have it wrong, but the only difference between
the two object declarations is how a constant is expressed.
g++ treats these two object declarations as different:
Angle angle1(
--- Additional Comments From ccarena at cox dot net 2005-07-17 14:04
---
This change will make it work:
Degrees degrees180( OneEighty );
Angle angle1( Degrees(180.0));// an instance of Angle
Angle angle2( degrees180 ); // this will work now
--
the preprocessed file, which I uploaded on
http://starynkevitch.net/Basile/jaksy-g++-4.1.0-20050717-bug.ii.gz (md5sum of
gzipped file is e71436c0b8f93cef110aa6068b13bcb3) produce a reproducible
compiler bug:
/usr/local/bin/g++_4_snap -c jaksy.ii
jaksy.hh: In constructor 'Jaksy_TVectorctag
--- Additional Comments From basile at starynkevitch dot net 2005-07-17
14:31 ---
Created an attachment (id=9293)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9293action=view)
preprocessor output (gnuzipped) of failing code
Sample code (preprocessor output with g++ -C -E and
FAIL: gcc.dg/tree-ssa/flatten-2.c scan-assembler cycle.:
(a new test) has appeared on hppa2.0w-hpux and hppa64-hpux. The problem is that
different targets use different syntax for assembler labels, so you need to
allow space, colon, tab or newline rather than just colon in such tests.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
15:31 ---
Confirmed.
Richard you can look into other tests to find the exact regex pattern for this.
Mainly the C++ tests:
./abi/mangle1.C:// { dg-final { scan-assembler \n_?_ZN1A1fEv\[: \t\n\] } }
--
Reading PR 22522 and searching for the correct regex for it, I noticed that
template/inline1.C in the
C++ testsuite just uses : as the syntax for assembler labels
./template/inline1.C:// { dg-final { scan-assembler-not _ZN1X3FooIiEEvT_: } }
--
Summary: template/inline1.C does not
--
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
15:47 ---
Confirmed, related to PR 22146.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
15:56 ---
*** This bug has been marked as a duplicate of 18000 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
15:56 ---
*** Bug 22520 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
15:57 ---
Forgot to mention GCC is right, see [8.2] of the standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22520
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
16:31 ---
This code is invalid. You cannot access a local variable in a local class.
*** This bug has been marked as a duplicate of 22464 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
16:31 ---
*** Bug 22521 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
BugsThisDependsOn||22524
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
Testcase (reduced from 20020107-1.c)
char buf[10];
char * a();
int
main (void)
{
int i = (a() - 1) - buf;
}
I will attach the patch to catch this to PR 22368.
20020107-1.c: In function 'main':
20020107-1.c:7: error: types mismatch in unary operand
intD.0
charD.1 *
~bufD.1263;
20020107-1.c:7:
--
What|Removed |Added
BugsThisDependsOn||22525
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
The testcase is gcc.dg/tree-prof/val-prof-2.c. It only happens when profile
use is used.
Note this is worse if we use unsigned long long instead as we get a size
mismatch.
See PR 22368 for the patch to catch this (the second patch):
--
What|Removed |Added
BugsThisDependsOn||22526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
take following example (compile with -O1 -ftree-vectorize -maltivec):
void a(unsigned long long __n, int *__new_start)
{
for (; __n 0; --__n, ++__new_start)
*__new_start = 0;
}
With the second patch in PR 22368, we get the following error:
pr18425.c: In function 'a':
pr18425.c:2: error:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
17:33 ---
Note the comparisions patch because of the way gimple removes casts to void*
gets:
int f(int *a, char*b)
{
return ((void*)a) == ((void*)b);
}
wrong.
The following is also effected:
g++.dg/abi/vbase13.C:
--
What|Removed |Added
BugsThisDependsOn||22527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
The following code:
c { dg-do compile }
c { dg-options -O2 -std=legacy }
LOGICAL*1 l1
INTEGER*1 i1
l1 = i1
END
produces mismatch types in comparision.
See PR 22368 for the patch which catches this.
logint-1.f: In function 'MAIN__':
logint-1.f:5: error: types mismatch
--
What|Removed |Added
CC||phython at gcc dot gnu dot
||org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
17:53 ---
Created an attachment (id=9295)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9295action=view)
patch which I need to test (from Honza)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22525
--
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22517
//Reading specs from
/usr/local/cross-arm/bin/../lib/gcc-lib/arm-linux/3.3.2/specs
//Configured with:
/home/localgjs/tnbt_cvstrees/software/tools/gcc/../../tools/gcc/configure
--target=arm-linux --disable-shared --disable-threads --with-gnu-as
--with-gnu-ld --enable-multilib --enable-languages=c
--
What|Removed |Added
Component|rtl-optimization|target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22528
--- Additional Comments From pluto at agmk dot net 2005-07-17 18:50 ---
gcc-4.0.1 works fine.
$ arm-linux-eabi-gcc gcc-pr22528.c -O2 -march=armv3 -S -mlittle-endian
test:
mov r3, #8
mov r2, #0
strbr3, [r0, #1]
strbr2, [r0, #0]
Take the following code:
struct f1
{
int i;
};
void f(void)
{
static struct f1 *f2 = (struct f1){1};
}
This is valid C99 at least according to both ICC and Comeau.
And we acceptted it in 3.0.4 also.
--
Summary: [3.4/4.0/4.1 Regression] Rejects valid C99 address of
--
What|Removed |Added
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22529
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-17
19:12 ---
Subject: Bug 21480
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-17 19:12:07
Modified files:
libgfortran:
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-07-17
19:12 ---
Fixed in 4.0.
--
What|Removed |Added
Status|ASSIGNED
Compile the following valid C99 code at -O3 and we get an ICE:
struct f1
{
int i;
};
void g(int);
static struct f1 *f2 = (struct f1){1};
int f(void)
{
g(f2-i);
return f2-i;
}
--
Summary: [4.1 Regression] ICE with static promotion
Product: gcc
Version: 4.1.0
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22530
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-17
19:17 ---
Subject: Re: New: [4.1 Regression] ICE with
static promotion
On Sun, 2005-07-17 at 19:13 +, pinskia at gcc dot gnu dot org wrote:
Compile the following valid C99 code at -O3 and we get an
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
19:18 ---
Forgot to say the ICE for this testcase is:
unhandled expression in get_expr_operands():
compound_literal_expr 0x41ebaf80
type record_type 0x41eaed20 f1 type_0 SI
size integer_cst 0x41e11740
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -c -g
-O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototype
s -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -
fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc
--
What|Removed |Added
Summary|[4.1 regression]|[4.1 regression] tree-into-
|dwarf2out.c:751:ICE |ssa.c:2290 ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
19:34 ---
What date is this from?
--
What|Removed |Added
Keywords|
1 - 100 of 167 matches
Mail list logo
