Jan Engelhardt a écrit :
On Thursday 2009-01-01 03:05, Andrew Pinski wrote:
On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt jeng...@medozas.de wrote:
Hi,
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
test.c: In function 'pam_sm_authenticate':
test.c:6: warning: implicit declaration of function 'undef'
This works on the trunk but fails on the 4.3 branch.
Hi,
Sorry in advance if this going over old ground. And if not, sorry
for the somewhat negative message ;), but ... I think the current
documentation and/or behaviour of the optimize attribute are a little
confusing.
The current behaviour is that, if __attribute__((optimize(...))) does
not
Hello,
I recently ported our GCC to new IRA by following mainline development. The
only interface I added is IRA_COVER_CLASSES. Our architecture has predicate
register file. When predicate register has to be spilled, the new IRA produces
inferior code to the old register allocator. The old
On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi,
Sorry in advance if this going over old ground. And if not, sorry
for the somewhat negative message ;), but ... I think the current
documentation and/or behaviour of the optimize attribute are a little
I found if I define a new register class that covers both GR_REGS and PR_REGS,
the issue can be solved. New IRA spill the predicate register to general
regsister first instead of memory. Is this right approach?
#define IRA_COVER_CLASSES \
{ \
GRPR_REGS, M_REGS,
On Thu, Jan 01, 2009 at 03:11:52AM +0100, Jan Engelhardt wrote:
On Thursday 2009-01-01 03:05, Andrew Pinski wrote:
On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt jeng...@medozas.de wrote:
Hi,
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it
On Fri, Jan 2, 2009 at 4:05 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi,
Sorry in advance if this going over old ground. And if not, sorry
for the somewhat negative message ;), but ... I
I am working toward efficient support of some of the sfixed point
types on avr architecture.
I started out by writing an assembly library to handle all of the
conversions to and from various fixed point, integer, and floating
point types. In many cases the functions are only 1 or 2
instructions,
Snapshot gcc-4.4-20090102 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
--- Comment #5 from laurent at guerby dot net 2009-01-02 12:51 ---
4.3.2-1 debian gnueabi and trunk rev 142984 do not ICE, waiting for
confirmation.
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #7 from q at ping dot be 2009-01-02 13:00 ---
Created an attachment (id=17021)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17021action=view)
Reduced test case part 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
--- Comment #8 from q at ping dot be 2009-01-02 13:01 ---
Created an attachment (id=17022)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17022action=view)
Reduced test case part 2
--
q at ping dot be changed:
What|Removed |Added
--- Comment #9 from q at ping dot be 2009-01-02 13:04 ---
I've reduced the test case. The call to siglongjmp() needs to be in a separate
file.
When the problem occurs the test program returns exit code 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
On 4.3.2-1 debian gnueabi:
gue...@gcc50:~$ gcc
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c -O0
-frtl-abstract-sequences
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
foo:
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c:35:
--- Comment #1 from laurent at guerby dot net 2009-01-02 13:17 ---
Similar failure for another test:
Executing on host: /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -Os
-frtl-abstract-sequences
4.3.2 works at -O0/1/2/3 but trunk at rev 142984 works at -O0 and fail at
-O1/2/3
gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/ -O1 -w -c -o pr37433.o
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c
GCC 4.3.2-1 debian gnueabi and trunk at rev 142984 generate wrong code at -O2
and above for pr37868.c
gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.dg/torture/pr37868.c -O2 -lm -o
./pr37868.exegue...@gcc50:~$
As shown on http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00092.html
neon tests scanning for vmov are failing on trunk:
FAIL: gcc.target/arm/neon/polytypes.c (test for excess errors)
FAIL: gcc.target/arm/neon/vget_lowf32.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9
--- Comment #1 from laurent at guerby dot net 2009-01-02 13:43 ---
Forgot the compile line used:
/home/guerby/build-142984/gcc/xgcc -B/home/guerby/build-142984/gcc/
-save-temps -O0 -mfpu=neon -mfloat-abi=softfp -c -o vget_lowf32.o
--- Comment #1 from rob1weld at aol dot com 2009-01-02 13:46 ---
Prior to changing gcc/config/i386/sol2-10.h:
u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v
-B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
--- Comment #6 from zadeck at naturalbridge dot com 2009-01-02 14:09
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
Kenneth Zadeck wrote:
2009-01-01 Kenneth Zadeck zad...@naturalbridge.com
PR rtl-optimization/35805
--- Comment #1 from laurent at guerby dot net 2009-01-02 14:17 ---
gcc 4.3.2-1 on debian gnueabi and current trunk do not seem to generate wrong
code but may be I'm wrong in my setup to reproduce this problem?
gue...@gcc50:~$ cat pr38692.c
#include stdio.h
int main(void)
{
int
--- Comment #9 from tdragon at tdragon dot net 2009-01-02 14:23 ---
That patch seems to work fine, and I haven't seen any unwarranted errors
relating to static data members so far. Thank you very much for tracking this
down!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #7 from bonzini at gnu dot org 2009-01-02 14:26 ---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
I think so. The global changed flag allows it to delete the case:
loop:
... - x // This is dead.
x- - ...
go to loop
it just is not
The following invalid code snippet triggers an ICE on the trunk:
=
union U
{
int i, j;
};
U u({1,2});
=
bug.cc:6: internal compiler error: in process_init_constructor_union, at
cp/typeck2.c:1101
Please submit a full bug report, [etc.]
--
Summary:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38698
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-02 14:39 ---
Subject: Bug 38690
Author: jakub
Date: Fri Jan 2 14:38:05 2009
New Revision: 143012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143012
Log:
PR middle-end/38690
* tree-flow.h (op_code_prio,
The following valid code snippet triggers an ICE since GCC 4.2.0:
==
struct A
{
const char* p;
};
void foo()
{
__builtin_offsetof(struct A, p[0]);
}
==
bug.cc: In function 'void foo()':
bug.cc:8: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
The following valid code snippet triggers an ICE since GCC 4.1.0:
==
int foo()
{
L: return __builtin_expect ((__SIZE_TYPE__)L, 0);
}
==
bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected tree
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38700
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-02 14:44 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from s__nakayama at infoseek dot jp 2009-01-02 14:52 ---
If T is the name of a class, then each of the following shall have a name
different from T:
- every data member of class T;
This description is the one in ISO/IEC 14882:1998.
It was changed in ISO/IEC
The following invalid code snippet triggers an ICE on the trunk:
==
void foo() = default;
==
bug.cc:1: error: 'void foo()' cannot be defaulted
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
The following invalid code snippet triggers an ICE on the trunk:
=
enum E { e };
E operator |= (E, const E) = default;
=
bug5.cc:3: internal compiler error: in copy_fn_p, at cp/decl.c:9717
Please submit a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Current debian lenny comes with glibc-2.7 and does not provide __gnu_mcount_nc
which will come with 2.8 as discussed on gcc-patches here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00319.html
But this means that all the tests from gcc testsuite using -p fail to link, eg:
Executing on host:
--- Comment #3 from laurent at guerby dot net 2009-01-02 15:17 ---
Still there with 4.3.2 and
gcc version 4.4.0 20081228 (experimental) [trunk revision 142939] (GCC)
Arnaud, do you have a generic expert handy to check wether this code is legal
or not? generic compiling but not an
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-02 15:20 ---
That seems invalid, not valid.
E.g. C says that for offsetof (type, member) for
static type t;
(t.member) evaluates to an address constant, which is not the case for
const char *p; field and p[0].
--
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-02 15:20
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
I think so. The global changed flag allows it to delete the case:
loop:
... - x // This is dead.
x- - ...
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 15:19 ---
This is a bug specific to the maverick set of chips.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 15:20 ---
Most likely needs to be skipped just like sparc as this is an unaligned access.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:29
---
CC-ing Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from zadeck at naturalbridge dot com 2009-01-02 15:34
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
On looking at the code, there is an issue with the first patch. I
should have been clearing solutions_dirty flag at the start of the
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:30
---
Likewise...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-02 15:36 ---
--with-cpu=pentium-m
Hmm, that might be the cause Testing with that option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38686
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:31
---
And again...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
#includeiostream
int main(int,char**){
const longdouble PiLD=3.1415926535897932384626433832795029L;
std::cout 3.1415926535897932384626433832795029std::endl;
std::cout.precision(70);
std::coutLD=PiLDstd::endl;
return 0;}
/*
Very bad
--- Comment #10 from bonzini at gnu dot org 2009-01-02 16:33 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
I will test this patch, but we still need to resolve your issues with my
approach.
The problem is that you're really doubling the cost of
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:33 ---
Changing component to pch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:39 ---
Please report the bug in comment #2 separately.
Otherwise it is unlikely to be seen by the appropriate person.
Andrew is correct; this would probably be fixed if we had gcc
tell libcpp to use its diagnostic code.
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:44 ---
You can try -C to keep the comments.
In the original report you said you can't get a backtrace.
That makes it a lot harder :(
Could you try shrinking the test case somehow?
Or perhaps you could change the abort()
I turfed up an ICE with optimization, but the thing compiled fine without. To
reproduce, use the soon-to-be attached source and do:
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -c AlpsTreeNode.ii
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -O3 -c AlpsTreeNode.ii
AlpsTreeNode.cpp: In
--- Comment #1 from sdirkse at gams dot com 2009-01-02 16:49 ---
Created an attachment (id=17023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17023action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
--- Comment #1 from pbrook at gcc dot gnu dot org 2009-01-02 17:01 ---
That's what dg-require-profiling does.
IMHO this is a deficiency in your glibc. It's very hard to distinguish between
something is subtly busted and my glibc sucks, so I'm not sure fixing this
is appropriate for fsf
--- Comment #1 from schwab at suse dot de 2009-01-02 17:02 ---
Depending on the actual value of DECIMAL_DIG this does not really look bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38704
--- Comment #6 from tromey at gcc dot gnu dot org 2009-01-02 17:04 ---
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.
This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.
--
tromey at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-02 17:07 ---
Ok, I can reproduce the failure. The work around is removing
-with-arch=pentium-m.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from andreasmeier80 at gmx dot de 2009-01-02 17:08 ---
What is the status of this bug?
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #8 from andreasmeier80 at gmx dot de 2009-01-02 17:08 ---
What is the status of this bug?
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-02 17:17 ---
Seeing what tests gcc fail with stage1's gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38686
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-02 17:09 ---
Here is a reduced testcase:
t.c:
#include t.h
--- CUT ---
t.h:
#ifdef __PME__
#define _TLS_QUAL /*0123456790*/
#endif // __PME__
Compile with gcc t.c -isystem . -traditional-cpp.
--
pinskia at gcc dot gnu
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-02 17:11 ---
I can reproduce the abort on both i686-linux-gnu and i386-darwin8.11 with my
reduced testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 17:29 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
--- Comment #2 from laurent at guerby dot net 2009-01-02 17:30 ---
The test already has:
/home/guerby/trunk/gcc/testsuite/gcc.dg/20021014-1.c
/* { dg-require-profiling -p } */
If configure tests the system compiler for profiling support it will of
course be fooled by a GCC changing
--- Comment #3 from joseph at codesourcery dot com 2009-01-02 17:35 ---
Subject: Re: testsuite __gnu_mcount_nc link error when
profiling on arm
On Fri, 2 Jan 2009, laurent at guerby dot net wrote:
I could not find a GLIBC 2.8 release in http://ftp.gnu.org/gnu/glibc/
nor in
Hi!
configured with: --host=alpha-linux-gnu --build=alpha-linux-gnu
--target=alpha-linux-gnu --enable-languages=c,c++ --with-system-zlib
Build fails with this error:
/bin/sh ../libtool --tag CXX --mode=compile /home/arthur/build/./gcc/xgcc
-shared-libgcc -B/home/arthur/build/./gcc -nostdinc++
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-01-02 18:05
---
Subject: Bug 33649
Author: mmitchel
Date: Fri Jan 2 18:04:28 2009
New Revision: 143014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143014
Log:
PR 33649
* tree-ssa-pre.c (compute_antic):
--- Comment #6 from mmitchel at gcc dot gnu dot org 2009-01-02 18:08
---
Fixed.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
While trying to figure out what is causing bootstrap to fail with
--with-arch=pentium-m, I decided to test the testsuite with stage1's gcc and
found that gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m, this
happens even with a normal compiled compiler.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 18:19 ---
Forgot to add the ICE:
/home/pinskia/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33:
internal compiler error: in immed_double_const, at emit-rtl.c:548^M
--
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-02 18:21 ---
Confirmed at r134530 with the following reduced test case:
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef USItype halffractype;
typedef
--- Comment #11 from zadeck at naturalbridge dot com 2009-01-02 18:21
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
I will test this patch, but we still need to resolve your issues with my
approach.
The problem is that
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-02 18:25 ---
The zero_extract:DI appears for the first time in the .163r.combine dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
--- Comment #9 from aanisimov at inbox dot ru 2009-01-02 18:30 ---
(In reply to comment #7)
Ok, I can reproduce the failure. The work around is removing
-with-arch=pentium-m.
Not a good idea ;-). I found that reverting diff r137645:r137646 makes the
compilation finish and the
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-02 18:38 ---
Reduced testcase:
typedef int AlpsNodeIndex_t;
void writeRep(char* representation_, const int len) {
__builtin_memcpy(representation_ , len, sizeof(int));
}
struct AlpsTreeNode
{
AlpsNodeIndex_t index_;
--- Comment #12 from bonzini at gnu dot org 2009-01-02 18:38 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
StevenB talked me out of this because he considered it wrong to have
the client pass get conservative info. I agreed with him but I am
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-02 18:39
---
I think:
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL:
I think this is the cause of PR 38686 but I could be wrong.
Anyways gcc.c-torture/execute/memset-3.c fails with -march=pentium-m -O1
--
Summary: [4.4 Regression] gcc.c-torture/execute/memset-3.c Fails
with -march=pentium-m -O1
Product: gcc
--- Comment #9 from hp at gcc dot gnu dot org 2009-01-02 18:44 ---
See comment #5. The subsequent commits were AFAIK not addressing it. I don't
have time to experiment right now, and as the bug only appeared (at the time)
with separate patches, I'm making it SUSPENDED. CC:ers, feel
--- Comment #13 from stevenb dot gcc at gmail dot com 2009-01-02 18:45
---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini bonz...@gnu.org wrote:
At this point, if your patch costs say 0.3%, and removing all
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 18:46 ---
Also fails on i386-darwin with -march=pentium-m. Plus it works with 4.3.3 so
this is only a 4.4 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 18:48 ---
This is also a regression from 4.3.2. It also ICEs on i386-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2009-01-02 18:48
---
Revision 137653 gave:
h...@gnu-3 gcc]$ cat /tmp/x.c
int
main ()
{
return 0;
}
[...@gnu-3 gcc]$ ./xgcc -B./ -S /tmp/x.c
/tmp/x.c: In function main:
/tmp/x.c:5: internal compiler error: in
--- Comment #14 from zadeck at naturalbridge dot com 2009-01-02 18:54
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Steven Bosscher wrote:
On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini bonz...@gnu.org wrote:
At this point, if your patch costs
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-02 18:57 ---
gcc.dg/compat//scalar-return-4_y.c fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37813
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-02 18:55
---
I think this is the same as PR 38708 really which I filed for memset-3.c case.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jv244 at cam dot ac dot uk 2009-01-02 18:57 ---
(In reply to comment #7)
Subject: Re: problem with contained subprocedure.
Hello,
This appears to be the problem. In any case, I just submitted a new archive
file. I hope this one's correct.
No... it is not.
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-02 18:58
---
Adding -mtune=pentium-m will fail gcc.c-torture/execute/memset-2.c
with -O3 and gcc.c-torture/execute/memset-3.c with -O/-O2/-O3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-02 19:01 ---
Adding -mtune=pentium-m will fail gcc.c-torture/execute/memset-2.c
with -O3 and gcc.c-torture/execute/memset-3.c with -O/-O2/-O3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-02 19:02 ---
Oh, I see now, The current version of the defect reports can be found at
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html DR80.
I tried looking for it but I must have missed it.
--
pinskia at gcc
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
$ cat ice.f90
INTEGER, PARAMETER :: i = 42
INTEGER, PARAMETER :: array(1) = (/ 1 /)
INTEGER, PARAMETER :: unknown = array(shape(i))
END
$ gfortran-svn ice.f90
f951: internal compiler error: in find_array_section, at fortran/expr.c:1213
$ gfortran-svn --version
GNU Fortran (GCC) 4.4.0
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
1 - 100 of 184 matches
Mail list logo
