--- Comment #10 from burnus at gcc dot gnu dot org 2007-07-23 06:03 ---
Subject: Bug 32600
Author: burnus
Date: Mon Jul 23 06:03:33 2007
New Revision: 126835
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126835
Log:
2007-07-23 Christopher D. Rickett [EMAIL PROTECTED]
make info currently fails on trunk:
Doing info in i686-pc-linux-gnu/libiberty
make[2]: Entering directory
`/home/ig25/gcc-bin/trunk/i686-pc-linux-gnu/libiberty'
perl ../../../../gcc/trunk/libiberty/gather-docs
../../../../gcc/trunk/libiberty ../../../../gcc/trunk/libiberty/functions.texi
alloca.c
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-23 06:05 ---
Setting to blocker as I can't do make info checks at the moment.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from cnstar9988 at gmail dot com 2007-07-23 06:08 ---
I found the problem.
But I don't know how to resolved.
$ gcc -Wl,+noallowunsats -m64 -fPIC -static-libgcc -Wl,-chpexport.sym -shared
-o libtrsbean.sl MafBean.o Function.o api/lib/trsapi.a -lc -lpthread
ld: Unsatisfied
--- Comment #6 from cnstar9988 at gmail dot com 2007-07-23 06:22 ---
Similar to this patch.
How to resolved?
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00327.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
interface.c's compare_actual_formal calls
gfc_warning (Character length of actual argument shorter
than of dummy argument '%s' (%d/%d) at %L,
f-sym-name, (int) actual_size,
(int) formal_size, a-expr-where);
--- Comment #3 from mfouts at danger dot com 2007-07-23 06:27 ---
This bug is still present in 4.2.1 but now happens on both fc5 and fc6
/space/projects/reference/tools/arm-elf-gnu/4.2.0/gcc-build-926ej-s/./gc
c/as
still remains the two line script
here be script
#!/bin/sh
--- 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 -E nul.c
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords|diagnostic |
--- 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=gccview=revrev=126836
Log:
2007-07-23 Christopher D. Rickett [EMAIL PROTECTED]
PR
--- 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
--- 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
--- 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=13952action=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 but
--- 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=13953action=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
--
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
--- 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=13954action=view)
darwin_objdir/powerpc-apple-darwin8/libgfortran/config.h
Can you post the config.h file from your build
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
--- 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.
--
--- 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 =
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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=gccview=revrev=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=gccview=revrev=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
--- 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
--- 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 get
--- 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 report
--- 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 bug.
--- 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
--- 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
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
--- 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=gccview=revrev=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=gccview=revrev=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
--- 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
--- 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
--- 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
--- 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 spec_7(ab)(3)
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
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-23 21:38
---
Fixed by: http://gcc.gnu.org/viewcvs?view=revrevision=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 #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
--- 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 #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
--
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 spec_7(ab)(3)
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.
--- 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
--- 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.
--
--- 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
--- 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=gccview=revrev=126866
Log:
2007-07-24 Thomas Koenig [EMAIL PROTECTED]
PR
94 matches
Mail list logo
