bits/atomicity.h has volatile qualifiers on the _Atomic_word* arguments to
the __*_single and __*_dispatch variants of the atomic operations. This
huts especially the single-threaded optimization variants which are usually
inlined. Removing those qualifiers allows to reduce code size
On 8/30/06, Benjamin Kosnik [EMAIL PROTECTED] wrote:
bits/atomicity.h has volatile qualifiers on the _Atomic_word* arguments to
the __*_single and __*_dispatch variants of the atomic operations. This
huts especially the single-threaded optimization variants which are usually
inlined.
Using:
../gcc-4.1.1/configure --host=mingw32 --build=mingw32 --target=mingw32
--enab
le-threads --enable-optimize --disable-nls --enable-languages=c,c++,fortran
--p
refix=/c/prog/mingw4 --with-cpu=pentium4 --with-ld=/c/prog/mingw4/bin/ld.exe
--
with-as=/c/prog/mingw4/bin/as.exe
hi,
I'm having some problem during build up of libgcc2 in function
__floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
backend.The error is
../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation fault
On 30 August 2006 15:11, kernel coder wrote:
hi,
I'm having some problem during build up of libgcc2 in function
__floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
backend.The error is
../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised that the mygcc page gives x86/linux binaries, but
no source tarball of their compiler (this seems to me against the
spirit of the GPL licence,
Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised that the mygcc page gives x86/linux binaries, but
no source tarball of
On Wed, Aug 30, 2006 at 06:36:19PM +0200, Basile STARYNKEVITCH wrote:
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised that the mygcc page gives x86/linux binaries, but
no source tarball of
On Wed, Aug 30, 2006 at 06:52:59PM +0200, Basile STARYNKEVITCH wrote:
Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised
On 30 August 2006 17:53, Joe Buck wrote:
On Wed, Aug 30, 2006 at 06:36:19PM +0200, Basile STARYNKEVITCH wrote:
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised that the mygcc page gives
Joe Buck wrote:
On Wed, Aug 30, 2006 at 06:52:59PM +0200, Basile STARYNKEVITCH wrote:
Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
Sebastian Pop wrote:
In my opinion the patch needs major rework and improvements to be
included in trunk.
Here is my short review of the mygcc patch that lists some possible
improvements and things that have to be redesigned:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00616.html
Dear all,
I have been trying to insert function calls during a new pass in the
compiler but it does not seem to like my way of doing it. The basic
idea is to insert a function call before any load in the program
(later on I'll be selecting a few loads but for now I just want to do
it for
On Sun, Jul 30, 2006 at 04:38:38PM -0700, H. J. Lu wrote:
When one checkin is used to fix multiple bugs, it isn't easy to back
out just the offending bug fix only if one of the bug fixes causes
regression. Can we limit one bug fix per checkin?
Thanks.
It happened again. This checkin:
It happened again. This checkin:
Yes the standard thing is one checkin pre fix. but it also annoying that you
(HJL)
don't understand how to file a bug report which is actually documented.
-- Pinski
[EMAIL PROTECTED] wrote on 08/30/06 14:44:
Does anyone have any ideas on to how I can modify my function and get it
to insert the functions correctly ?
Browse through omp-low.c. In particular create_omp_child_function and
expand_omp_parallel. The new function needs to be added to the call
KZ == Kenneth Zadeck [EMAIL PROTECTED] writes:
KZ 2) To have a discussion about the use of DWARF3. I am now against the
KZ use of DWARF3 for encoding the GIMPLE.
FWIW your arguments convinced me.
I think what matters most is that the resulting format be relatively
well documented (say, better
[...]
KZ +case TRUTH_NOT_EXPR:
KZ +case VIEW_CONVERT_EXPR:
KZ +#if STUPID_TYPE_SYSTEM
KZ + output_type_ref (ob, TREE_TYPE (expr));
KZ +#endif
I think VIEW_CONVERT_EXPR needs to be treated like NOP_EXPR and
CONVERT_EXPR in the STUPID_TYPE_SYSTEM case. VIEW_CONVERT_EXPR is a
Andrew Pinski wrote:
It happened again. This checkin:
Yes, we did discuss it before - sorry, HJ; I am trying to get as much
done before I am forced to reduce my work on gfortran. It is much easier
to do multiple patches but I will desist.
Yes the standard thing is one checkin pre fix
Hi,
I compiled the follwing code with gcc -shared buglib.c -o buglib.dll:
buglib.h is:
struct T
{
double x[256];
double y[256];
int i;
};
struct T fun(int a);
buglib.c is
#include buglib.h
struct T fun(int a)
{
struct T retval;
int i;
Sorry,
I made a mistake with the printf()-formatting-
charcters.
Greetings, Uwe
Browse through omp-low.c. In particular create_omp_child_function
I understand the beginning of the function with its declaration of the
function but I have a question about these lines :
/* Allocate memory for the function structure. The call to
allocate_struct_function clobbers
[EMAIL PROTECTED] wrote on 08/30/06 16:41:
Is that a necessary process for the declaration of a function ? I ask
because I do not want the compiler to compile directly my function but
rather ask the linker to take care of that (it will be an external
function).
Oh, so you only want to
Follows the build info:
config.guess:
i386-pc-mingw32
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.1.1/configure --prefix=/mingw
--host=mingw32 --target=mingw32 --program-prefix= --with-gcc --with-gnu-ld
--with-gnu-as --enable-threads --disable-nls
In create_omp_child_function, an identifier for the new function is
created. We then create a call to it using build_function_call_expr in
expand_parallel_call.
Ok so that's what I saw, is this call necessary for what I'd need :
decl = lang_hooks.decls.pushdecl (decl);
Then simplifying
Hello,
I have been trying to insert function calls during a new pass in the
compiler but it does not seem to like my way of doing it. The basic
idea is to insert a function call before any load in the program
(later on I'll be selecting a few loads but for now I just want to do
it
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
[I'm sorry for not replying to this sooner. I've been on a plane or in
a
Mark Mitchell wrote:
Kenneth Zadeck wrote:
This
will be more cumbersome if we have to keep reloading each object
file's abbrev table just to tear apart a single function in that .o
file. While the abbrev sections average slightly less than %2 of the
of the size of the GIMPLE encoding for
After some discussion with Jack Howarth, I have found that the
gfortran and libgomp executable tests on powerpc-apple-darwin8.7.0
(at least) do not link the correct, just-built-using-make
bootstrap, libraries until those libraries have first been installed
in $prefix/lib/...
I filed a
Bradley,
Something still is as astray with your build configuration.
Look at my last set of results.
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01333.html
I only have 28 unexpected failures for g++ at -m64 and you
have 1350. Likewise for libstdc++ at -m64, I only have 6
unexpected
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being compiled. Getting at
those functions that are going to be inlined is where the
Geoff,
I am assuming that quite a few of the remaining regressions at -m64
on Darwin PPC with your TImode patch applied will be resolved when Eric
posts his x86_64 patches. However there are a few in gcc.target/powerpc
which likely won't be addressed by those patches. I am seeing the following
On 8/30/06, Mark Mitchell [EMAIL PROTECTED] wrote:
...
I guess my overriding concern is that we're focusing heavily on the data
format here (DWARF? Something else? Memory-mappable? What compression
scheme?) and we may not have enough data. I guess we just have to pick
something and run with
--- Comment #10 from kazu at gcc dot gnu dot org 2006-08-30 06:00 ---
Subject: Bug 26632
Author: kazu
Date: Wed Aug 30 06:00:35 2006
New Revision: 116580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116580
Log:
PR middle-end/26632
* gcc.dg/pr26632.c: New.
m68k port quietly accepts -fstack-limit-symbol on ColdFire.
-fstack-limit-symbol causes gcc to output trapcs.
However, ColdFire does not support any conditional trap.
--
Summary: m68k port quietly accepts -fstack-limit-symbol on
ColdFire
Product: gcc
--- Comment #8 from drewmccormack at mac dot com 2006-08-30 07:01 ---
Thanks Paul!
I am just using binaries, so I can't test this, but I trust you ;-)
Drew
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
--- Comment #10 from dpatel at apple dot com 2006-08-30 07:47 ---
Pinski,
Please do not reinsert my email address in CC list, again (and learn to not
jump to conclusion based on biased views)
May be it is not a good idea to ask dwarf generator to handle a case where two
shallow copy
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-08-30 08:07 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01124.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-30 08:14 ---
Subject: Bug 27735
Author: rakdver
Date: Wed Aug 30 08:14:29 2006
New Revision: 116582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116582
Log:
PR rtl-optimization/27735
* cfgloopmanip.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-30 08:27 ---
Oh, it was indeed me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Respekt! Die Aktion ist ja der Hammer!
Die sieht gut uns und setzt es für ne gute Sache ein ;-)
--- Weitergeleitete Nachricht ---
Von: Klaus Becker [EMAIL PROTECTED]
An: [EMAIL PROTECTED];
Betreff: Fwd:FW: Echte Tierliebe :-)
Datum: Wed, 18 Aug 2006 17:49:02 +0100 (MET)
Hallo
// /usr/libexec/gcc/i386-redhat-linux/4.1.0/cc1plus -fpreprocessed a.ii -quiet
-dumpbase a.cpp -mtune=generic -auxbase a -version -o - -frandom-seed=0
# 1 a.cpp
# 1 built-in
# 1 command line
# 1 a.cpp
# 45 a.cpp
templateclass A
class B {
public:
B() { i = 0; }
A a;
static int i;
};
I am testing the OpenMP support of the current gcc and use the following test
program:
long long i, num_steps = 100;
double x, sum=0.0;
double step=1.0/(double) num_steps;
#pragma omp parallel for private(i,x) reduction(+:sum)
for(i=0; inum_steps; i++)
{
x = (i+0.5)*step;
sum +=
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-30 09:43 ---
*** This bug has been marked as a duplicate of 24791 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-08-30 09:43 ---
*** Bug 28897 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from stefan dot lankes at rwth-aachen dot de 2006-08-30
09:45 ---
I discovered that program works with OMP_NUM_THREADS=2. If OMP_NUM_THREADS is
larger than 2, the program crashes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28898
--- Comment #2 from stefan dot lankes at rwth-aachen dot de 2006-08-30
09:55 ---
If I compile my test program with the current gcc and set OMP_NUM_THREADS to 2,
the program calculates a wrong value for PI. If I use Intel's C compiler, the
program calculates the correct value. Does the
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-08-30 10:35 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01131.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tbm at cyrius dot com 2006-08-30 11:10 ---
This bug happens *a lot* compiling the Debian archie with -ftree-vectorize -O3.
Additional testcases available on request.
--
tbm at cyrius dot com changed:
What|Removed |Added
The attached testcase produces an ICE gimplification failed. Works fine with
gcc 4.1 and 4.2.0 20060819, but fails with 4.2 20060823 and 20060830.
gimplification failed:
{
register unsigned int __v;
register unsigned int __x;
D.2493 = data + 4B;
D.2494 = (const uint32_t *) D.2493;
__x
--- Comment #1 from tbm at cyrius dot com 2006-08-30 11:27 ---
Created an attachment (id=12152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12152action=view)
test case
Testcase from application lcdf-typetools.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
ICE verify_stmts failed (invalid operand to unary operator) with
-ftree-vectorize and -O:
(sid)105:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -ftree-vectorize
-O1 -c
linphone-synths.c
linphone-synths.c: In function 'synths_':
linphone-synths.c:9: error: invalid operand to unary operator
--- Comment #1 from tbm at cyrius dot com 2006-08-30 11:38 ---
Created an attachment (id=12153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12153action=view)
test case
Testcase from application linphone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
gcc -Wunused-variable -c test.c, where test.c contains the
following code, fails to warn that variable a is unused:
--begin-test.c-
static const int a = 27;
static const int b = 42;
const int *f(void) { return b; }
--end-test.c--
However, gcc -Wunused-variable -c -Dconst= test.c does
produce the
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-30 12:21 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 12:37 ---
I bet this is tree-ifcvt that is causing it and not really the vectorizer, I
will check later today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The avr target gives that alignment warning for every polymorphic class,
because it doesn't define TARGET_VTABLE_ENTRY_ALIGN, which means the default
kicks in, which is the size of a pointer. Since the AVR as an 8 bit platform
has no alignment requirements, BIGGEST_ALIGNMENT is 8, which is less
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 13:00 ---
Confirmed, reduced testcase:
int check_table (int t)
{
unsigned length = 0;
if ((length =__extension__ ({register unsigned __v; __v;})))
;
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-30
13:11 ---
(In reply to comment #2)
The standard is unambiguous: A string element must be written as charr(i:i).
character(*) :: charr
.
print *, charr(i)
will always be interpreted as a call to an assumed
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
Testcase:
template class
struct View
{
int n;
};
template class ViewA
struct ViewDom : ViewViewA
{
using ViewViewA::n;
ViewDom();
};
template class ViewA
ViewDomViewA::ViewDom()
{
char a[n];
}
void element( )
{
ViewDomint a;
}
--
Summary: [4.2 Regression] Rejects VLA in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0
Known to work||4.1.1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 15:05 ---
Remove the template from View and this works.
Janis,
Could you do a regression hunt on this bug?
Thanks,
Andrew
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from eweddington at cso dot atmel dot com 2006-08-30 15:06
---
The AVR does not have an Add Immediate instruction (addi), so this is normally
done using sbi with a negative number as Andrew correctly points out.
In Ralf's unoptimized output, it correctly shows a -2
--- Comment #2 from tbm at cyrius dot com 2006-08-30 15:06 ---
Note that this must be very recent. gcc started rejecting this code between
20060806 and 20060823.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 15:09 ---
This is just unrolling/removing empty loops so invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 15:15 ---
And I was correct.
4.1.2 has the bug too:
_ifc_.33_28 = !(r__2_11 = 9.90095367431640625e-1) || _ifc_.30_3;
that is invalid gimple.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #27 from guenter at roeck-us dot net 2006-08-30 15:16 ---
Created an attachment (id=12154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12154action=view)
possible patch
This might be a possible patch. It reverts to the original insn declaration,
except for replacing
When trying to build CrystalSpace3d, which is a very big application, on
GNU/Linux, I get errors like this :
{standard input}:1236795: Error: operand out of range (0x8220 is
not between 0x8000 and 0x7fff)
(repeated about 300 times)
The file, cs_pyth.cpp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 15:23 ---
Confirmed, reduced testcase:
int synths_ ( float * rc)
{
float r1, r2;
int i;
for (i = 0; i 128; ++i)
{
r2 = rc[i];
r1 = ((r2) = (.99f) ? (r2) : (.99f));
rc[i] = ((r1) = (-.99f) ? (r1) :
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-30 15:47 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2006-08-30 15:50 ---
Subject: Bug number PR middle-end/27567
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-08/msg01134.html
--
I get the following ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O2
djvulibre-JB2EncodeCodec.cc
djvulibre-JB2EncodeCodec.cc: In member function 'void
DJVU::JB2Dict::JB2Codec::Encode::code_comment(DJVU::GUTF8String)':
djvulibre-JB2EncodeCodec.cc:60: internal compiler error: in
--- Comment #12 from jason at gcc dot gnu dot org 2006-08-30 15:51 ---
Subject: Bug 26670
Author: jason
Date: Wed Aug 30 15:51:17 2006
New Revision: 116591
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116591
Log:
PR c++/26670
* class.c (check_field_decls): Don't
--- Comment #1 from tbm at cyrius dot com 2006-08-30 15:51 ---
I get this with 4.2.0 20060823 but not with 20060721 - I wonder if it's related
to the fix for PR28814?
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2006-08-30 15:51 ---
Subject: Bug number PR 28887
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-08/msg01124.html
--
--- Comment #13 from jason at gcc dot gnu dot org 2006-08-30 15:52 ---
Subject: Bug 26670
Author: jason
Date: Wed Aug 30 15:52:12 2006
New Revision: 116592
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116592
Log:
PR c++/26670
* class.c (check_field_decls): Don't
--- Comment #2 from tbm at cyrius dot com 2006-08-30 15:52 ---
Created an attachment (id=12155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12155action=view)
test case
Testcase from application djvulibre.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
--- Comment #14 from jason at gcc dot gnu dot org 2006-08-30 15:52 ---
fixed on 4.1 branch too.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 16:07 ---
Confirmed, but it looks unrelated to that PR but rather a change from SCEV
might had caused this.
Reduced testcase:
void f(void) __attribute__ ((noreturn));
int g(void);
void code_comment (void)
{
int size = g();
Works gcc 4.2 20060806, fails with 20060823:
(sid)579:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c texlive-t1rw.cc
texlive-t1rw.cc:19: error: conflicting declaration 'unsigned char
Efont::Type1Reader::xvalue_store [257]'
texlive-t1rw.cc:5: error: 'Efont::Type1Reader::xvalue_store' has
--- Comment #1 from tbm at cyrius dot com 2006-08-30 16:16 ---
Created an attachment (id=12156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12156action=view)
test case
Testcase from application texlive-bin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 16:24 ---
Reduced testcase:
extern unsigned char xvalue_store[];
bool reserve (int want)
{
new unsigned char[want];
}
unsigned char xvalue_store[257];
I almost think this was casued by the patch to fix PR 27184.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
ICE. Works with gcc 4.2 20060806, fails with 20060823.
(sid)630:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c
ragel-parsedata.cc
ragel-parsedata.cc:19: internal compiler error: tree check: did not expect
class 'type', have 'type' (template_type_parm) in contains_placeholder_p, at
--- Comment #1 from tbm at cyrius dot com 2006-08-30 16:57 ---
Created an attachment (id=12157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12157action=view)
test case
Testcase from application ragel.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28907
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 17:18 ---
*** Bug 28907 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 17:18 ---
It is the same bug as PR 28906.
*** This bug has been marked as a duplicate of 28906 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 17:20 ---
This also causes wrong code:
extern char machineMain[];
void sort (long len)
{
new char[100];
}
char machineMain[] = main;
int main(void)
{
if (sizeof(machineMain)!=sizeof(main))
__builtin_abort();
}
--
This testcase coms from SPEC CPU 2006:
[EMAIL PROTECTED] wrf-1]$ cat foo.f90
module foo
use bar
implicit none
private
type ESMF_Clock
type(ESMF_Time) :: CurrTime
end type
interface operator (+)
function add (x, y)
use bar
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 17:50 ---
When reporting regressions can you at least give the version of GCC you are
using as it might had been fixed already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 17:52 ---
Also saying what is the last known version to work is also nice.
Note I am going to say this is related to PR 28630 and either is caused by it
or fixed by it.
--
--- Comment #28 from guenter at roeck-us dot net 2006-08-30 18:00 ---
Created an attachment (id=12158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12158action=view)
Another possible patch
Another possible patch. This one retains m-r handling, and thus produces
somewhat more
--- Comment #3 from hjl at lucon dot org 2006-08-30 18:02 ---
The regression was introduced between revision 116091 and 116362. revision
116590
still has this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #29 from dje at watson dot ibm dot com 2006-08-30 18:08 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
Yes, I was testing out the same change as your second patch. That
looks reasonable if it works.
By the way, the use of %H in the frob
--- Comment #4 from hjl at lucon dot org 2006-08-30 18:41 ---
Revision 116268 is the cause. There are several bug fixes in one checkin. It is
hard to just back out one bug fix.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #30 from dje at watson dot ibm dot com 2006-08-30 18:42 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
In other words, should the lwz actually be evlwwsplat?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
--- Comment #31 from amylaar at gcc dot gnu dot org 2006-08-30 18:47
---
(In reply to comment #29)
(In reply to comment #28)
2006-08-29 Nathan Sidwell [EMAIL PROTECTED]
Jorn Rennecke [EMAIL PROTECTED]
PR tree-optimization/17506
* tree-ssa.c
--- Comment #5 from hjl at lucon dot org 2006-08-30 18:55 ---
This patch:
http://gcc.gnu.org/ml/fortran/2006-08/msg00154.html
is the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
1 - 100 of 145 matches
Mail list logo
