--- Comment #7 from cnstar9988 at gmail dot com 2007-07-23 07:15 ---
I build with -lgcc_stub, So works ok.
I think "_Jv_RegisterClasses" for GCJ.
"__cxa_finalize" for G++.
My Library only use C language, so works ok.
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-07-23
07:37 ---
seen on the trunk 20070730
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31900
[forwarded from http://bugs.debian.org/423160]
seen with trunk 20070720
The gij implementation of EnumMap class contains a flaw: it returns
strange java.lang.Object classes for missing elements. The error can be
demonstrated with this program:
=== Cut ===
import java.util.*;
public class Test {
--- Comment #17 from dannysmith at users dot sourceforge dot net
2007-07-23 08:04 ---
(In reply to comment #16)
Maybe we
> should make it match "con" with case ignored.
No, please. "con", "nul", "prn" (with or without suffix) are reserved device
names on windows.
(eg "gcc -v -dM -
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords|diagnostic |
http://gcc.gn
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 09:03 ---
Subject: Bug 32732
Author: burnus
Date: Mon Jul 23 09:03:30 2007
New Revision: 126836
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126836
Log:
2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-23 09:06 ---
This is indeed fixed by my patch for PR31205. I had the breakthrough in
understanding why this broke cp2K at about 3 o'clock this morning *sigh* The
fix turned out to be very easy but understanding what was broken was
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 09:08 ---
FIXED. Steve, please check under IA64 HP-UX whether it works now.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-23 09:24 ---
Not a bug GCC can able to fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html
Cf. also PR 32797.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html
Cf. also PR 32800.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
--- Comment #5 from brian dot sidebotham at gmail dot com 2007-07-23 09:39
---
Here is the output of a correctly built and installed toolchain:
> arm-elf-as -V
arm-elf-as: unrecognized option `-V'
> arm-elf-as -Qy
arm-elf-as: unrecognized option `-Qy'
> arm-elf-as --version
GNU assem
--- Comment #6 from vogel at pi2 dot physik dot uni-erlangen dot de
2007-07-23 10:08 ---
This program demonstrates the problem, it creates different output depending on
if compiled with or without optimisation.
Without optimisation, n->next is not cached:
n->next = 0xbfb01af0
n->next =
4.3.0 20070723 (experimental)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -fpreprocessed vfprintf.i
-quiet -dumpbase vfprintf.i -mcpu=G4 -auxbase vfprintf -O2 -version -o
/tmp/cc85HTF5.s
GNU C version 4.3.0 20070723 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version
--- Comment #1 from michelin60 at gmail dot com 2007-07-23 13:48 ---
Created an attachment (id=13952)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13952&action=view)
preprocessed vprintf.c from glibc-2.6
vprintf.c from glibc-2.6, glibc2.6.90, and glibc-2.5 differ in minor ways bu
--- Comment #2 from michelin60 at gmail dot com 2007-07-23 13:51 ---
Created an attachment (id=13953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13953&action=view)
Partial *.s output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
--- Comment #7 from falk at debian dot org 2007-07-23 14:17 ---
(In reply to comment #6)
> This program demonstrates the problem, it creates different output depending
> on
> if compiled with or without optimisation.
This does not demonstrate the problem, since your code has undefined
/vol/gnu/src/gcc-4.2.1/./gcc/xgcc -v -B/vol/gnu/src/gcc-4.2.1/./gcc/
-B/vol/gnu/alphaev6-dec-osf4.0f/bin/ -B/vol/gnu/alphaev6-dec-osf4.0f/lib/
-isystem /vol/gnu/alphaev6-dec-osf4.0f/include -isystem
/vol/gnu/alphaev6-dec-osf4.0f/sys-include -O0 -I/vol/gnu/include -mieee
-DIN_GCC -W -Wall -Wwrite-st
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|glibc ICE's gcc-4.3.0 SSA |[4.3 Regressio
--- Comment #9 from dominiq at lps dot ens dot fr 2007-07-23 14:53 ---
Created an attachment (id=13954)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13954&action=view)
darwin_objdir/powerpc-apple-darwin8/libgfortran/config.h
> Can you post the config.h file from your build direct
This patch
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00685.html
causes
(gdb) r readdata.f90 -quiet -dumpbase readdata.f90 -mtune=generic -auxbase
readdata -O2 -version -ffast-math -o readdata.s -fintrinsic-modules-path
/export/gnu/import/rrs/126826/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/fincl
--- Comment #1 from hjl at lucon dot org 2007-07-23 15:02 ---
(gdb) p b->value.character
$10 = {length = 15180528, string = 0xe660fd "__trim_1"}
(gdb) p a->value.character
$11 = {length = 15170912, string = 0xe660fd "__trim_1"}
The length field doesn't look right.
--
http://gcc.gnu
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-23 15:03 ---
This a regression from 4.2. The following code
real(8) x, y
real(8) down, up
x = huge(x)
y = down(x)
print *, y, up(y)-x, up(up(y))-x, up(up(x))-x
y = up(y)
print *, x, y
end
real(8) function up(x)
real(8) x
up = ne
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-23 15:08 ---
Not yet.
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01652.html
is an update for the quoted patch, it might help to the extend that you get an
error, not an ice.
What does the corresponding Fortran code look lik
--- Comment #3 from hjl at lucon dot org 2007-07-23 16:09 ---
(In reply to comment #2)
> Not yet.
>
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01652.html
>
> is an update for the quoted patch, it might help to the extend that you get an
> error, not an ice.
It makes no difference.
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-23 16:11 ---
I have a fix I'm testing.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #4 from hjl at lucon dot org 2007-07-23 16:23 ---
Here is a small testcase:
[EMAIL PROTECTED] 459.GemsFDTD]$ cat foo.f90
MODULE Readdata_mod
IMPLICIT NONE
Private
Public Parser
integer, parameter:: nkeywords = 2
character(80), PARAMETER, dimension(1:nke
--- Comment #5 from hjl at lucon dot org 2007-07-23 16:31 ---
A smaller testcase:
[EMAIL PROTECTED] 459.GemsFDTD]$ cat foo.f90
SUBROUTINE Parser(nx, ny, keyword)
character(80), PARAMETER, dimension(1:2) :: keywords = &
(/'PROBLEMSIZE', &
'NFTRANS_TD'/)
integer, intent(inout
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-23 16:36 ---
Confirmed. Will look into it.
As it works with scalars, I think I forgot to take arrays into account ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pieter dot donche at ua dot ac dot be 2007-07-23 16:43
---
Subject: Re: make fails, Java CLASSPATH
Hi,
Thanks. It did compile now..
(from midnight to 10:30 in the morning ...)
P.
\___
/ Pieter Donche \
| ITC
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-07-23 17:17 ---
I currently cannot check the documentation changes requried
in the review for PR 30814. The condition of a Blocker,
"Blocks development and/or testing work" is fulfilled, IMHO.
Andrew, you marked this as a non-bloc
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-23 17:22 ---
Stop changing the CC for this bug, the issue is a generic issue and most likely
unrelated to any of the CC you added. This is more likely to be a PRE issue
than anything else. When I get into work, I will look into
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-23 17:24 ---
Normal issue of not following directions (Solaris's /bin/sh is not a POSIX
shell).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Compiling this C or C++ file:
#define __STDC_FORMAT_MACROS 1
#define __STDC_FORMAT_MACROS 1
produces these warnings:
foo.c:2:1: warning: "__STDC_FORMAT_MACROS" redefined
foo.c:1:1: warning: this is the location of the previous definition
This is because of these lines in libcpp/macro.c:
if (
--- Comment #3 from dj at redhat dot com 2007-07-23 17:29 ---
Subject: Re: New: [4.3 Regression] "make info" fails in libiberty
I've checked in a fix for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 ---
Subject: Bug 32797
Author: burnus
Date: Mon Jul 23 17:47:16 2007
New Revision: 126856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856
Log:
2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 ---
Subject: Bug 32800
Author: burnus
Date: Mon Jul 23 17:47:16 2007
New Revision: 126856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856
Log:
2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:51 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:52 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from michelin60 at gmail dot com 2007-07-23 18:03 ---
(In reply to comment #3)
> Stop changing the CC for this bug, the issue is a generic issue and most
> likely
> unrelated to any of the CC you added. This is more likely to be a PRE issue
> than anything else. When I
--- Comment #5 from dje at watson dot ibm dot com 2007-07-23 18:05 ---
Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
> michelin60 at gmail dot com writes:
michelin60> Doing a search of PR's filed I came up, surprise, with no remotely
equivalent
michelin60> re
--- Comment #6 from michelin60 at gmail dot com 2007-07-23 18:33 ---
(In reply to comment #5)
> Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
>
> No, you do not. You submitted the bug. Let the GCC developers
> decide how best to triage and analyse the bu
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-23 18:42 ---
(In reply to comment #6)
> Well David here is an interesting quote:
Lets put it this way, this quote is true but it is held hostage in a good way.
You don't want broken code in your compiler do you? This is what D
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-23 18:46 ---
(In reply to comment #5)
> character(80), PARAMETER, dimension(1:2) :: keywords = &
>(/'PROBLEMSIZE', &
> 'NFTRANS_TD'/)
it is probably not related to the ICE, but the above is invalid F95.
Error: test.f90,
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-07-23 18:50 ---
> it is probably not related to the ICE, but the above is invalid F95.
> Error: test.f90, line 2: Array constructor values have differing CHARACTER
> lengths (11 and 10). gfortran should error out on this.
This is
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-23 18:56 ---
Working on a reduced testcase but when I quickly looked into it, PRE was
messing up the variables that have abnormal set so this is unrelated to the
rs6000 back-end.
--
pinskia at gcc dot gnu dot org changed:
it's not clear to me why there is an ifdef __x86_64__ around the definitions of
_mm_cvtsi64_si128/_mm_cvtsi64x_si128 in emmintrin.h. the movq instruction
required to implement those has always been present in sse2 -- even on 32-bit
hosts.
gcc seems to do the right thing already if i just remove t
Compiling this code:
struct Foo {
struct Bar;
Foo();
};
namespace Baz {
Foo::Foo() { }
struct Foo::Bar { };
}
Gives the following two error messages:
test.C:6: error: definition of 'void Foo::Foo()' is not in namespace enclosing
'Foo'
test.C:7: error: declaration of 'struct Foo::Bar' in '
Let's look at this:
long foo(long a, long b, long c, uint8_t d){
if(d){
return a+b;
}else{
return a-c;
}
}
The listing reports this:
long foo(long a, long b, long c, uint8_t d){
4e: cf 92 push r12 ;All this registers are pushed
50: ef 92 push r14 ;despi
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-23 19:24 ---
Re-open, as the branches are still affected and this is a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-23 19:42 ---
Currently regtesting the patch below without problem so far.
H.J. could you please verify that it fixes your problem?
Index: expr.c
===
--- expr.c
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-07-23 19:47 ---
Yes, it's fixed now.
Thanks!
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl at lucon dot org 2007-07-23 19:53 ---
(In reply to comment #9)
> Currently regtesting the patch below without problem so far.
> H.J. could you please verify that it fixes your problem?
>
> Index: expr.c
> =
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-07-23 20:08
---
Patch in comment #9 passed regression testing on i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-23 20:35 ---
Subject: Bug 25104
Author: dfranke
Date: Mon Jul 23 20:35:03 2007
New Revision: 126858
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126858
Log:
gcc/fortran:
2007-07-23 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-07-23 20:35
---
Subject: Bug 31639
Author: dfranke
Date: Mon Jul 23 20:35:03 2007
New Revision: 126858
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126858
Log:
gcc/fortran:
2007-07-23 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-23 20:38
---
Commit shown in comment #9 restores the situation as described in comment #8,
no further development yet.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
If I do a bootstrap build of GCC I get a large (160+) number of C test failures
due to extra warning output. This only happens with a bootstrap build so I
think GCC is miscompiling itself. The included program gives the warning:
x.c:2: warning: inline function 'foo' given attribute noinline
Wh
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-07-23 20:45
---
Closing again. The orginal testcase is now correctly handled for all standards.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from vda dot linux at googlemail dot com 2007-07-23 20:50
---
I want to apologise. Apparently this behavior (16-byte stack alignment) can be
turned off with an option => I can still have just word-aligned stack. As long
as that still works, I am a more-or-less happy campe
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-07-23 20:55
---
On mainline the diagnostic for the second testcase got even worse:
bug.cc:3: error: no 'void A::foo()' member function declared in class 'A'
bug.cc:3: error: prototype for 'void A::foo()' does not match any in cla
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-07-23 21:31 ---
Generic (also ICEs on i686-linux-gnu) reduced testcase:
void _IO_vfprintf_internal ( char *f )
{
static const void *const step0_jumps[] = { &&do_form_unknown, &&do_flag_plus,
&&do_form_float };
const void * ptr =
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 21:31
---
The bug disappeared on the 4.1 branch (already in GCC 4.1.2).
It is still present on the 4.2 branch and mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-23 21:35
---
Value numbering spec_28(ab) stmt = spec_28(ab) = PHI
Setting value number of spec_28(ab) to spec_7(ab)
We should not value number this PHI node, yes it is a copy but a needed copy
for abnormal edges.
Note the re
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-23 21:38
---
Fixed by: http://gcc.gnu.org/viewcvs?view=rev&revision=126857
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-23 21:55 ---
The error message is:
/home/apinski/x86-local-fsf/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algo.h:2789:
instantiated from 'void std::sort(_RandomAccessIterator,
_RandomAccessIterator)
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-07-23 22:05
---
Since Nathan's patch for PR32839, we get the following error message for the
testcase in comment #7 (and similar messages for the original testcase, the
testcase in comment #6, and PR 24606):
bug.cc: In function '
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 22:08
---
Since Nathan's patch for PR32839 we get the same error message for PR24602
as for PR24606. This really looks like a duplicate.
*** This bug has been marked as a duplicate of 24602 ***
--
reichelt at gcc dot g
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-07-23 22:08
---
*** Bug 24606 has been marked as a duplicate of this bug. ***
--
Bug 24602 depends on bug 24606, which changed state.
Bug 24606 Summary: ICE on template function which gets an template agrument as
a function w
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-07-23 22:22
---
The problem disappeared on the 4.2 branch (already for GCC 4.2.0), but is still
present on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27002
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 22:26
---
Since the 4.2 branch doesn't show the bug, we have a regression.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from eweddington at cso dot atmel dot com 2007-07-23 22:57
---
Here's what I see:
The array __clz_tab is used in a macro, count_leading_zeros, which is called in
the function __clzSI2 in libgcc2.c, which (AFAICT) gets compiled to the
function __clzsi2 and aggregated in l
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
--- Comment #11 from michelin60 at gmail dot com 2007-07-23 23:17 ---
Very interesting
Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3.
This led to further research prompting not only the CC's but also the quote.
Dr. Edelsohn metioned triage but there are
Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE.
is_long_double_1221(ab) and is_long_double_144(ab)
vfprintf.c: In function '_IO_vfprintf_internal':
vfprintf.c:184: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32873
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-23 23:29
---
> Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3.
> This led to further research prompting not only the CC's but also the quote.
If it does not fail on i686 with the non preprocessed
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-23 23:30
---
As mentioned before closing this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-23 23:30 ---
Value numbering spec_28(ab) stmt = spec_28(ab) = PHI
Setting value number of spec_28(ab) to spec_7(ab)
We should not value number this PHI node, yes it is a copy but a needed copy
for abnormal edges.
Note the redu
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-23 23:52 ---
I think this is related to the patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01668.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32852
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 00:34 ---
Confirmed, I saw this also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hp at gcc dot gnu dot org 2007-07-24 00:58 ---
Caroline Tice, by the lack of comments I kind of doubt you're reading this, but
for the record, there should have been a PR middle-end/32761 marker in the
ChangeLog entry and one for PR32764; there are several examples of
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 02:14 ---
This is improved by
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00573.html
But for:
struct a
{
int t, t1;
};
int f(struct a b)
{
return b.t + b.t1;
}
We still get a store/load.
--
http://gcc.gnu.org/bugz
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-24 02:14 ---
(In reply to comment #2)
> This is improved by
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00573.html
Also the store is still there:
.L.f:
srawi 0,3,16
stw 3,48(1)
extsw 3,0
blr
-
--- Comment #12 from hjl at lucon dot org 2007-07-24 03:33 ---
(In reply to comment #9)
> Currently regtesting the patch below without problem so far.
> H.J. could you please verify that it fixes your problem?
>
> Index: expr.c
> =
--- Comment #4 from mfouts at danger dot com 2007-07-24 05:17 ---
OK, so this one's weird and starts out as a user error.
If the path specified in --prefix=/usr/local/armdev-$CPU-4.2.0 in the original
config is *not* writable by the account running the build, the make all-gcc
fails with
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-07-24 05:52 ---
Subject: Bug 30814
Author: tkoenig
Date: Tue Jul 24 05:52:44 2007
New Revision: 126866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126866
Log:
2007-07-24 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #137 from pault at gcc dot gnu dot org 2007-07-24 06:18 ---
Joost,
Are you seeing this on bench01 and bench02? - this is on yesterday's tree
Program received signal SIGSEGV, Segmentation fault.
0x00c67e4a in __topology_util_MOD_topology_set_atm_mass ()
(gdb) backtrace
#0 0
--- Comment #138 from jv244 at cam dot ac dot uk 2007-07-24 06:31 ---
(In reply to comment #137)
> Joost,
>
> Are you seeing this on bench01 and bench02? - this is on yesterday's tree
>
By chance I ran a test yesterday evening (rev. 126856) which ran OK. This was
on an opteron with '"
93 matches
Mail list logo
