--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 09:51 ---
Confirmed. Number of iteration analysis concludes the loop
ush_4 = label.23_3 + 510B;
if (label.23_3 <= ush_4) goto ; else goto ;
:;
# ush_16 = PHI ;
# csum_14 = PHI ;
:;
# VUSE ;
D.2866_8 = *ush_16
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-17 10:10 ---
This is a dup of PR26763, which is fixed for 4.1.1.
*** This bug has been marked as a duplicate of 26763 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-17 10:10
---
*** Bug 27176 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-17 10:16 ---
This may be fixed by Zdeneks optimization of phi argument rewrite and dominator
updating. Though I bet these are not appropriate for 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 10:34 ---
#5 0x081a8738 in get_val_for (x=0xb7dedea0, base=0xb7d70480)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1254
1254 val = fold (TREE_OPERAND (stmt, 1));
(gdb) call debug_generic
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-17 10:51 ---
Hmm, looks more like a tree sharing problem
Breakpoint 5, fold_ternary (code=CALL_EXPR, type=0xb7d5fa6c, op0=0xb7d55540,
op1=0xb7dd9048, op2=0x0)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/fold-const.c:9
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-17 11:12 ---
1329aval[j] = get_val_for (op[j], val[j]);
(gdb) call debug_generic_expr(val[0])
__builtin_pow (xD.1278_4, 2.0e+0)
(gdb) call debug_generic_expr(op[0])
xD.1278_3
Program received signal SIGSEGV, Segmenta
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 11:18 ---
Now, the comment before get_val_for is confusing, as it says
* if BASE is NULL_TREE, X must be a constant and we return X.
but we do
if (!x)
return base;
now, I believe a
gcc_assert (is_gimple_min_inv
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 12:09
---
The ICE reappeared.
Probably with Jakub's fix for PR26823.
Btw, the testcase in the testsuite didn't trigger, it
probably lacks the line
/* { dg-options "-O" } */
This should be fixed once this bug gets fixed agai
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 12:17
---
The testcase fails again (with a segfault):
FAIL: gcc.dg/gomp/pr25989.c (test for excess errors)
(from http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00920.html)
This is probably due to your fix from PR26823, Ja
Consider the following class hierarchy:
struct StorageBase {
int i;
};
struct NonPod1 : StorageBase {
int get() { return i; }
NonPod1() {}
};
struct NonPod {
NonPod() { x[0].i = 0; x[1].i = 0; }
NonPod1& operator[](int i) { return *static_cast(&x[i]); }
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 12:31 ---
The tree-combiner requiring function depends on 27084. Also this happens in
tramp3d again. Also related to 27090. Still fold needs to catch it first.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-17 12:33
---
Fixed on mainline.
Thanks for fixing this one, Jakub!
Alas there seems to be some fallout: PR25874, PR25989.
@Martin: I tried to reduce your testacse a little and got a segfault in
can_throw_internal_1. So this i
--- Comment #6 from patchapp at dberlin dot org 2006-04-17 13:10 ---
Subject: Bug number PR 27136
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-04/msg00623.html
--
http://gcc.gnu.org/bugzilla/s
Hi,
gcc-4.1.0 miscompiles on sh4-linux target.
Attached testcase does not trigger this bug on mainline,
and also correctly compiled with gcc-3.4.5.
For attached testcase, source line 514 is incorrectly compiled with
following command line.
g++ -O2 -g -fno-strict-aliasing -fwrapv \
-fno-implici
--- Comment #1 from sugioka at itonet dot co dot jp 2006-04-17 13:19
---
Created an attachment (id=11282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11282&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27182
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-17 13:53 ---
Subject: Bug 26826
Author: rguenth
Date: Mon Apr 17 13:53:19 2006
New Revision: 113007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113007
Log:
2006-04-17 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-17 13:54
---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from green at redhat dot com 2006-04-17 14:43 ---
Created an attachment (id=11283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11283&action=view)
Sample patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
--- Comment #5 from green at redhat dot com 2006-04-17 14:44 ---
I've uploaded a patch that I've applied to the FC5 gcc RPM. I can't reproduce
the problem with this patch.
--
green at redhat dot com changed:
What|Removed |Added
---
--- Comment #2 from patchapp at dberlin dot org 2006-04-17 15:00 ---
Subject: Bug number PR27122
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-04/msg00626.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:12 ---
This fellow now gives:
Error: Procedure 'p' at (1) is already defined at (2)
on trunk and 4.1, so it is fixed.
Arigato goziamasu, Iguchi-san!
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:14 ---
HJ has fixed this one.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2006-04-17 15:18 ---
Fixed on trunk and will be fixed on 4.1, when patch for PR25597 is applied next
weekend.
I will close this now since its purpose is served.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25618
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:18 ---
Fixed!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 ---
The latest round of patches cured the original problem. Unfortunately, the
target itself is still broken. This time because of a bug originaly reported
for the e500v1 target. (27075).
I am not sure what is the right adm
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:32 ---
HJ has fixed this one.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-17 15:35 ---
This one now gives:
Error: 's' at (1) must have constant character length in this context
on trunk and 4.1
Fixed - thanks, Philippe!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #34 from mark at codesourcery dot com 2006-04-17 15:37 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> --- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 ---
> The latest rou
--- Comment #35 from edmar at freescale dot com 2006-04-17 15:44 ---
The original problem was solved. For futher bootstrap problems on this target,
see bug 27075.
--
edmar at freescale dot com changed:
What|Removed |Added
--
--- Comment #9 from edmar at freescale dot com 2006-04-17 15:57 ---
This bug also affects target e500v2. The e500v2 is configured with:
--target=powerpc-unknowm-linux-gnuspe --enable-e500_double.
I will try the patch on comment 8 overnight.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #6 from tromey at gcc dot gnu dot org 2006-04-17 16:00 ---
We could either use here (see ltdl.c) or we could
use libltdl instead of directly using dlopen...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--- Comment #22 from law at redhat dot com 2006-04-17 16:40 ---
Here's some code which can be clearly improved with the in-progress patch to
add additional ASSERT_EXPRs:
int f(void);
void test(int x) {
if (x & 1 ? x == 0 : x > 0) f();
}
Right now we generate something like:
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-04-17 16:54
---
It also helps for propagating loop versioning guard information like
int foo(int i, int j)
{
int res = 0;
if (i==1 && j==2)
for (;i>0;--i)
res += j;
else
for (;i>0;--i)
res += j;
return
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 17:21
---
The failures in PR25874 and PR25989 are not caused by this patch.
Sorry for blaming your patch, Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
.
Target: i386-apple-darwin8.6.1
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060417 (experimental)
[pactech01:~/tests] dir%
WARNING: Couldn't find the global config file.
Test Run By dir on Mon Ap
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 ---
*** Bug 27183 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 ---
I already filed this before.
*** This bug has been marked as a duplicate of 25765 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 17:24
---
RTH, alas there seems to be some fallout: PR25874, PR25989.
(I first blamed Jakub's patch for PR26823 for the fallout, but closer
inspection showed that it's your patch instead.)
Would you mind having a look?
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:29 ---
What's the status of this bug? Did nobody comment on the proposed patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:33 ---
Looks like a duplicate of PR26881
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27036
--- Comment #5 from pcarlini at suse dot de 2006-04-17 18:35 ---
Working on a fix.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned a
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-17 18:36 ---
Fixed by:
2006-04-17 Roger Sayle <[EMAIL PROTECTED]>
* expr.c (expand_assignment): Optimize away no-op moves where the
source and destination are equal and have no side-effects.
--
pinskia at g
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-17 18:39 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Testcase (at -O2 and above):
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
int main(void)
{
long a[2];
if (!NumSift(&a, &a))
__builtin_abort ();
return 0;
}
--
Orginally reported here:
http://gcc.gn
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.0.4
http
--- Comment #9 from janis at gcc dot gnu dot org 2006-04-17 19:36 ---
Subject: Bug 26114
Author: janis
Date: Mon Apr 17 19:35:56 2006
New Revision: 113010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113010
Log:
PR c++/26114, c++/26115
* typeck.c (cxx_mark_addr
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-17 19:38 ---
This is now fixed on mainline and 4.1:
$ cat case.f90
program main
logical :: l
select case (l)
case (.true.)
case (.true.)
end select
end program main
$ gfortran case.f90
In file case.f90:4
case (.tru
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 19:55 ---
Just to add some information from the conversation on this topic:
> > Shouldn't the aliasing set for the type atype be the same as atype1?
>
> Im not entirely sure, but the C99 standard does at least not suggest
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 20:07 ---
And this only fails for array types without their size specified. Confirmed.
Btw. inside NumShift the two array types are
unit size
align 32 symtab 0 alias set -1 precision 32 min max
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-17 20:13 ---
Simplified test case:
public class main {
public static void main(String[] args) {
char x = 56478;
System.out.println(new String(new char[] { x }));
}
}
--
tromey at gcc dot g
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-17 20:23 ---
Testing a fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
Hello.
There is part of build screen:
mkdir -p -- libgcc
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
/e/build/gcc-4.1-20060414/host-i786-pc-cygwin/gcc/xgcc
-B/e/build/gcc-4.1-20060414/host-i786-pc-cygw
in/gcc/ -B/usr/i786-pc-cygwin/bin/ -B/usr/i786-pc-cygwin/lib/ -isystem
/usr/i78
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-17 21:41 ---
Subject: Bug 27171
Author: tromey
Date: Mon Apr 17 21:41:47 2006
New Revision: 113013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113013
Log:
PR libgcj/27171:
* testsuite/libjava.lang/pr271
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-17 21:45 ---
Subject: Bug 27171
Author: tromey
Date: Mon Apr 17 21:45:42 2006
New Revision: 113014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113014
Log:
PR libgcj/27171:
* testsuite/libjava.lang/pr271
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-17 21:46 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
Compiles Booch Components but does not compile a package used for testing the
components. Compiler creates the ali file but no object file.
Cygwin from http://sources.redhat.com/cygwin/
Compiler (GNU Ada, package GNAT/GCC MS-Windows Cygwin, release 4.1.0 R4) from
http://sourceforge.net/project/sho
--- Comment #1 from george dot chapman at lmco dot com 2006-04-17 22:00
---
Created an attachment (id=11287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11287&action=view)
gnatchop input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
--- Comment #2 from george dot chapman at lmco dot com 2006-04-17 22:01
---
Created an attachment (id=11288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11288&action=view)
shell input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
Test gcc.target/powerpc/doloop-1.c has failed on mainline for powerpc64-linux
with -m64 and for powerpc-apple-darwin8.5.0 since this patch was added:
http://gcc.gnu.org/viewcvs?view=rev&rev=112126
r112126 | mkuvyrkov | 2006-03-16 05:20:39 + (Thu, 16 Mar 2006) | 9 lines
2006-03-16 Maxim Kuvy
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 ---
*** This bug has been marked as a duplicate of 26727 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 ---
*** Bug 27187 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
|| echo './'`kopetecontactlist.cpp
kopetecontactlist.cpp: In member function `QStringList
KopeteContactList::contactFileProtocols(const QString&)':
kopetecontactlist.cpp:779: internal error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.or
--- Comment #7 from alexey at cs dot sunysb dot edu 2006-04-18 00:06
---
(In reply to comment #6)
> In C, there is no ordering left to right, please go read the C FAQ at:
> http://www.eskimo.com/~scs/c-faq.com/expr/index.html
> subpage:
> http://www.eskimo.com/~scs/c-faq.com/expr/comma.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-18 00:21 ---
(In reply to comment #7)
> (In reply to comment #6)
> > In C, there is no ordering left to right, please go read the C FAQ at:
> > http://www.eskimo.com/~scs/c-faq.com/expr/index.html
> > subpage:
> > http://www.eski
--- Comment #3 from george dot chapman at lmco dot com 2006-04-18 00:35
---
(From update of attachment 11287)
Missing body for Managed_Storage.
--
george dot chapman at lmco dot com changed:
What|Removed |Added
--- Comment #4 from george dot chapman at lmco dot com 2006-04-18 00:36
---
Created an attachment (id=11289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11289&action=view)
gnatchop input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
--- Comment #5 from george dot chapman at lmco dot com 2006-04-18 00:40
---
Compiles at "-O0" but not "-O1" and subsequent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hp
pa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include
-isys
tem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-incl
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu dot org
Keywords|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-18 01:33 ---
Sorry Aldy for CCing you (I saw prune_unused and thought it was your front-end
patch). When in fact it was:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00641.html
That caused the ICE.
--
pinskia at gcc dot gnu
char* help =
"Usage: foo [options]
-v verbose
-d debug
";
Code like the above should work. It is really convenient when editing this
code that you do not have to terminate your lines with cruft like \n\
Of course this is pure convenience, but I never heard any convincing
argument why this
--- Comment #2 from wszafran at users dot sourceforge dot net 2006-04-18
03:10 ---
Yes, it works like a charm now. I only built the CygWin-hosted,
MinGW-targetting compiler with your patch applied, but I suppose a similar
result would be achieved with a compiler bootstrapped on CygWin.
--- Comment #9 from bangerth at dealii dot org 2006-04-18 03:21 ---
> It does not matter either. The evaluation of a function argument is an atomic
> procedure.
No, it actually isn't.
> If it starts it should generate a result. Isn't it strange if the
> compiler evaluates a little bi
--- Comment #4 from bangerth at dealii dot org 2006-04-18 03:28 ---
This is not a bug. While the name in a function call is looked up from
inside the class, the name of a member function is looked up in the
global scope. There, the member in question here is inaccessible.
W.
--
bang
--- Comment #1 from bangerth at dealii dot org 2006-04-18 03:30 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
/home/jerry/gcc/4.2/./gcc/xgcc -B/home/jerry/gcc/4.2/./gcc/
-B/home/jerry/gcc/usr/i686-pc-linux-gnu/bin/
-B/home/jerry/gcc/usr/i686-pc-linux-gnu/lib/ -isystem
/home/jerry/gcc/usr/i686-pc-linux-gnu/include -isystem
/home/jerry/gcc/usr/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC
-W -Wa
--- Comment #2 from bangerth at dealii dot org 2006-04-18 03:45 ---
Confirmed, though this doesn't seem to have anything to do with PR 9050.
Here's a shorter testcase:
--
struct B{};
struct Bar : virtual B {
template Bar( T const& cast );
};
template <>
--- Comment #3 from bangerth at dealii dot org 2006-04-18 03:47 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from bangerth at dealii dot org 2006-04-18 03:50 ---
We've had numerous such reports in the past. The compiler can't do anything
to detect whether it has run out of stack space. What happens is that a
program allocates stack space, the operating systems gives it to the pro
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51
---
I just found this already reported.
*** This bug has been marked as a duplicate of 27188 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51
---
*** Bug 27191 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
The program below confuses gcc in such a way that it generates code loading the
byte-address of bar() into the Z register, which causes icall to jump off to
neverneverland. Rather, the double-byte address of bar() should be loaded into
Z before the indirect call.
This bug is also present in gcc 4
dump-tree-original-raw does not print the linkage for
a variable with file scope.
--- test case (sta.c)---
static int static_var=9;
double global_var = 0;
main() {
int x;
x = 4+ static_var + global_var;
return x;
}
-- to reproduce ---
gcc -fdump-tree-original-raw sta.c
tai
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-04-18 06:12 ---
Preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
--- Comment #10 from falk at debian dot org 2006-04-18 06:27 ---
Uhm, this has nothing to do at all with evaluation order. Evaluation
order of arguments is unspecified (not undefined, which wouldn't make a
lot of sense), but that is in fact irrelevant here, it could lead to,
say, 3 1 2,
90 matches
Mail list logo
