--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-17 07:56 ---
12 is the right size for -m32, 16 for -m64.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
Boot OpenSolaris 2008.11 (64 bit OS) in 32 bit mode.
Configure gcc this way:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --wit
When making gcc 4.4.0 20090104 I saved a log of the build. I hacked
this Bug to allow the build to continue but did not file until today
when I noticed that this still occurs in gcc version 4.4.0 20090117 .
# prev-gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../g
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-01-17 03:36 ---
Reconfirming the problem with (x86 && pic), e.g.:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01601.html
Jan, any comments?
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-01-17 03:03 ---
Reconfirming...
I can see on a linux-gnu box that it's compiling the libiberty testsuite with
stage1 gcc. That masks the error of missing libgcc bits used in stage3
libiberty, but still it should be using the stage3
--- Comment #17 from ghazi at gcc dot gnu dot org 2009-01-17 02:56 ---
Reconfirming that gcc.dg/pr30957-1.c still XFAILs for me on x86_64.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-01-17 02:50 ---
Reconfirming for (x86 && pic):
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01601.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
The reported error is:
internal compiler error: in init_reg_sets_1, at regclass.c:594
SVN version @ revision r143453
--
Summary: ms_abi function attribute fails with -fno-sse
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-17 01:59 ---
init_regs may be called more than once when switching ABIs. It
may introduce memory leaks.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|valgrind find problem with -|[4.4 Regression] valgrind
|O3 -mtune=generic
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-17 01:41 ---
I can reproduce it on Linux/x86-64:
[...@gnu-6 gcc]$ valgrind --tool=memcheck ./cc1 -fpreprocessed x.i -quiet
-dumpbase x.i -mtune=generic -auxbase x -O -version -o x.s
==30493== Memcheck, a memory error detector.
--- Comment #5 from bangerth at dealii dot org 2009-01-17 01:41 ---
(In reply to comment #2)
> I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
boost.bind appears to work just fine for me, though!?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
Build broken on Trunk. Worked less than two days ago.
# prev-gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 -
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-01-17
01:17 ---
Hmm, I can't look at what happens to START or STOP at those break points
because gdb reports...
Breakpoint 1, print2 (qspcl=.TRUE., renrl=()) at print2.f:81
81WRITE(LINE(START:STOP),'(4A)') '
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-01-17
01:13 ---
If I use gdb (which doesn't suppress the bug like write statements do), and add
break points at...
> STOP=NTERMS*19+2
WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')=',ST(1:STLEN)
> END IF
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-01-17
01:02 ---
I have no idea what this means, but if I change...
CHARACTER*80 LINE
in the PRINT2 subroutine to...
CHARACTER*81 LINE
the error at -O3 disappears.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-01-17
00:58 ---
Breaking this down into separate files, as expected, the regression only occurs
when the PRINT2 subroutine is compiled at -O2 or higher.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-01-17
00:49 ---
Created an attachment (id=17125)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17125&action=view)
testcase reduced to single file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #4 from cfairles at gcc dot gnu dot org 2009-01-17 00:03
---
*** Bug 38889 has been marked as a duplicate of this bug. ***
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from cfairles at gcc dot gnu dot org 2009-01-17 00:03
---
*** This bug has been marked as a duplicate of 35569 ***
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.2
Known to work||3.4.6
--- Comment #10 from jason at gcc dot gnu dot org 2009-01-16 23:18 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jason at gcc dot gnu dot org 2009-01-16 23:17 ---
Subject: Bug 38877
Author: jason
Date: Fri Jan 16 23:17:35 2009
New Revision: 143449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143449
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow non-fie
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-16 23:17 ---
Only happens with checking enabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2009-01-16 23:15 ---
Btw, the equivalent that uses boost::bind works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
I feel like I must be doing something incredibly stupid (and I'm sorry
if indeed I do) but this:
#include
void goo(int);
void foo() {
std::bind (goo,1)(); // works
std::bind (goo,std::placeholders::_1)(1); // does not work
}
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-16 23:11 ---
Patch is ok for the 4.3 branch, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-16 23:10 ---
I have no plans for fixing this on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-16 23:09 ---
I have no plans of fixing this on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 23:08
---
I have no plans to fix this on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 22:55
---
Lowering priority, this is not a regression on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-16 22:54
---
Lowering priority, this is not a regression on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-16 22:51
---
Btw, I am sure this is not a problem for loads, as only CFG exits from
functions
causes the bogus PRE and that always clobbers memory if it may call exit
(pure and const functions may not). It may become a problem
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-16 22:50 ---
Yep, I've been making a bunch of mangling changes recently. Should be all done
now though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-16 22:48 ---
Fixed for 4.4. Will fix in 4.3 soon.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-16 22:46 ---
(In reply to comment #2)
> We demangle it as int X::f()
I have to update my c++filt even though it is from August 2008.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-16 22:46 ---
Fixed for 4.4, not fixing accepts-invalid on other branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-16 22:45 ---
We demangle it as int X::f()
The suggestion seems reasonable to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-16 22:40 ---
Subject: Bug 38877
Author: jason
Date: Fri Jan 16 22:40:25 2009
New Revision: 143448
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143448
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow non-fie
--- Comment #5 from sje at cup dot hp dot com 2009-01-16 22:38 ---
Fixed on Trunk (4.4) and 4.3 branch. 4.2 branch is closed (or shortly will be)
so I am going to just close this as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-16 22:38 ---
Well the diagnostic mechanism does not demangle anything, we have the whole
expression in memory still. So changing the diagnostic is no issue. Now I
wonder how we (c++filt) demange "_ZN1XIIidEE1fIIidEEEiv" anyways
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-16 22:36 ---
Subject: Bug 38877
Author: jason
Date: Fri Jan 16 22:36:32 2009
New Revision: 143446
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143446
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow non-fie
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-16 22:36 ---
Subject: Bug 29470
Author: jason
Date: Fri Jan 16 22:36:11 2009
New Revision: 143445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143445
Log:
PR c++/29470
* pt.c (tsubst_decl) [USING_DECL]: P
--- Comment #8 from sje at gcc dot gnu dot org 2009-01-16 22:35 ---
Subject: Bug 31260
Author: sje
Date: Fri Jan 16 22:35:24 2009
New Revision: 143444
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143444
Log:
PR c++/31260
PR c++/38357
* pt.c (tsubst): Ch
--- Comment #4 from sje at gcc dot gnu dot org 2009-01-16 22:35 ---
Subject: Bug 38357
Author: sje
Date: Fri Jan 16 22:35:24 2009
New Revision: 143444
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143444
Log:
PR c++/31260
PR c++/38357
* pt.c (tsubst): Ch
Maybe it isn't too late yet to change the specification in the ABI (or
maybe there isn't even one yet) for cases like this -- consider
template struct X {
template int f() { this->error; }
};
template int X::f();
We get this error message:
g/
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-16 22:26
---
A different possible patch would be to have a special mode that pre-splits
the CFG at the possible exit points and insert edges to the exit BB. We
could condition that on a flag or so.
--
http://gcc.gnu.org/b
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 22:24
---
Created an attachment (id=17124)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17124&action=view)
patch
Patch I am testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-01-16 22:13
---
This has been fixed on the trunk by the Andrew Pinski's patch for PR36695.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-16 22:11
---
Semi small testcase:
union u_u16
{
unsigned short v;
struct
{
unsigned char lo8, hi8;
} __attribute__ ((__may_alias__)) u;
} __attribute__ ((__may_alias__));
union u_u32
{
unsigned int v;
struct
{
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-16 22:07 ---
I'd say re-adding that symbol until you change libgfortran ABI wouldn't hurt
anything, but if you can prove no program could ever use it except for
referencing directly that symbol, I guess I can live with a WONTFIX to
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-16 21:48 ---
Confirm. Thanks for reporting.
Backtrace:
#0 0x2b4a4645 in raise () from /lib64/libc.so.6
#1 0x2b4a5c33 in abort () from /lib64/libc.so.6
#2 0x2ad69c00 in *_gfortrani_internal_unpack_4 (d=0
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-16 21:47 ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-01-16 21:43
---
Fixed on the trunk by Steve Ellcey's patch for PR38357.
Steve, would you mind backporting the patch to the 4.3 branch as it fixes an
ice-on-valid-code regression there?
--
reichelt at gcc dot gnu dot org chang
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-16 21:38 ---
Confirm.
Working: 4.4.0 20081029 (experimental) [trunk revision 141421]
Failing: 4.4.0 20081103 (experimental) [trunk revision 141544]
(assuming that my tree was clean back then)
--
burnus at gcc dot gnu dot org
--- Comment #8 from dragan at plusplus dot co dot yu 2009-01-16 21:22
---
Created an attachment (id=17123)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17123&action=view)
another test case
I disagree... here is another test case. Semantically, it is the same
as the first one, so
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-01-16 21:22
---
This has been fixed by the patch for PR36334.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from breiten at lexmark dot com 2009-01-16 21:14 ---
Created an attachment (id=17122)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17122&action=view)
unmodified preprocessor output
This is the original preprocessor output (renamed to a .c file). Compile with
-fPIC
The following program gives a run-time abort. If either of the array arguments
to MVBITS has an explicit (ie (5,1) or (6,1) ) zero size, the program does not
abort.
It aborts differently on Windows, depending on how it is run.
Dick Hendrickson
program try_ya0013
! fails on Windows XP
! g
--- Comment #1 from breiten at lexmark dot com 2009-01-16 21:11 ---
Created an attachment (id=17121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17121&action=view)
minimal file to cause error - needs -fPIC and -O2
somewhere along my trimming exercise, this file stopped demonstra
--- Comment #10 from dberlin at gcc dot gnu dot org 2009-01-16 21:07
---
Subject: Re: [4.2/4.3/4.4 Regression] trapping
expression wrongly hoisted out of loop
On Fri, Jan 16, 2009 at 4:01 PM, rguenther at suse dot de
wrote:
>
>
> --- Comment #9 from rguenther at suse dot
Got this one with the attached file when attempting to upgrade to gcc-4.3.2 for
powerpc. This compiles fine with 3.4.6. I've captured the preprocessed output
and removed everything I could that didn't make the problem disappear. This is
from openssl-0.9.8d. The problem required -O2 or -O3 and -
Another one like PR 38884 and 38865.
Simple testcase:
#define vector __attribute__((vector_size(16) ))
vector float global_res;
float x;
int main(int argc)
{
vector float res = (vector float)(0.0f,0.0f,0.0f,1.0f);
res += (vector float)(0.0f,0.0f,0.0f,1.0f);
global_res = res;
x = *(
--- Comment #9 from rguenther at suse dot de 2009-01-16 21:01 ---
Subject: Re: [4.2/4.3/4.4 Regression] trapping
expression wrongly hoisted out of loop
On Fri, 16 Jan 2009, dberlin at dberlin dot org wrote:
> Subject: Re: [4.2/4.3/4.4 Regression] trapping
> expression wrong
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-01-16 21:01
---
Fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Just like PR 38865:
struct s { _Complex float i; };
void g(struct s *);
float a (float dd)
{
struct s sv;
sv.i = dd;
_Complex float d = sv.i;
float d1 = __real__ d;
g(&sv);
return d1;
}
float a1 (float dd)
{
struct s sv;
sv.i = dd;
float d = __real__ sv.i;
g(&sv);
return d;
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
20:51 ---
Subject: Re: FAIL: abi_check hppa
> add in stubs.c for long double only
I think we also need float stubs. I saw some problems with
floorf in the testsuite in my last build.
Dave
--
http://gcc.gnu.
--- Comment #8 from dberlin at gcc dot gnu dot org 2009-01-16 20:48 ---
Subject: Re: [4.2/4.3/4.4 Regression] trapping
expression wrongly hoisted out of loop
Hmmm.
The only way you could get the CFG to represent that any call may exit
would be to calls terminate bb's and have
The following program causes an internal compiler error. If the single
reference to NF3 in the MVBITS argument list is changed to "3" the program
compiles and executes.
Dick Hendrickson
module yg0009_stuff
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 1
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-16 20:44 ---
Hmm, maybe we need to what exactly is done for profiling and split the basic
blocks at the function call boundaries but that would definitely cause lots of
compile time regressions.
--
http://gcc.gnu.org/bugzill
--
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 pinskia at gcc dot gnu dot org 2009-01-16 20:41 ---
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00448.html
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00581.html
Hmm, I think the front-end should be doing the trick of &16B->y into 16B + 4
just like the C front-en
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 20:37 ---
((char*) &(((struct s*)16)->y) - (char *)16),
That is not a valid constant expression in C++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 20:33 ---
Except really it is 5.2.5 that causes this to be invalid code. Well the C++
standard as written in 1998, it is valid but there is a defect report against
it and it fixed this code to be invalid.
*** This bug has be
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 20:33 ---
*** Bug 38870 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 20:24 ---
int
main (void)
{
int si1 = a;
int si2 = b;
int i;
for (i = 0; i < 100; ++i) {
if (a == 2)
exit (0);
r += si1 % si2;
}
abort ();
}
shows that PRE doesn't move code to where it executes mor
GCC incorrectly accepts following code with deferred constant declaration:
-- vstrings.ads
-- gnatmake -c -gnatc vstrings.ads
package VStrings is
subtype VString_Size is Integer range 0 .. 160;
type VString (Len : VString_Size := VString_Size'Last) is private;
Empty_VString : constant V
There are two problems with list_remove_elem function in objc/objc-list.h file:
- function dumps core when remove first element of the list,
- if element is in the list more than once and copy of the element are one by
one they do not be removed all.
struct objc_list *list = 0;
int elem_1
--
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 #5 from rguenth at gcc dot gnu dot org 2009-01-16 20:04 ---
PRE shouldn't cause new evaluations - the issue here is that the CFG
# BLOCK 2 freq:900
# PRED: ENTRY [100.0%] (fallthru,exec)
si1_3 ={v} a;
si2_4 ={v} b;
# SUCC: 3 [100.0%] (fallthru,exec)
# BLOCK 3
--- Comment #7 from jason at gcc dot gnu dot org 2009-01-16 20:03 ---
3.2.3 also fails the first testcase. This seems to have been broken by
2001-03-01 Nathan Sidwell
* decl2.c (do_nonmember_using_decl): Don't complain if we find
same function. Do complain about amb
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work||4.3
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-16 19:46 ---
[...@gnu-27 build_base_o3.]$ cat y.cc
template
struct pair
{
typedef _T1 first_type;
typedef _T2 second_type;
_T1 first;
_T2 second;
pair () : first(), second() { }
pair(const _T1& __a, const _T2& __b
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-16 19:43 ---
(In reply to comment #4)
> I will check, but if I recall correctly, procedure pointer were not
> implemented
> at the time when it was removed
The function was not even referred in trans*.c as far as I can see. The
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-16 19:41 ---
[...@gnu-27 build_base_o3.]$ cat x.cc
#include
#include
template class bar;
template
std::pair *, unsigned int>
foo (const std::string &name, unsigned int position)
{
const std::pair tmp;
retur
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38877
--- Comment #1 from jason at gcc dot gnu dot org 2009-01-16 19:39 ---
Testcase? I don't have SPEC handy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38877
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-16 19:32 ---
I will check, but if I recall correctly, procedure pointer were not implemented
at the time when it was removed, i.e. it could not possibly be called. When
they got implemented, no casting was needed as they were hand
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 19:23 ---
Caused by the fix for PR36227.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 19:23 ---
Caused by the fix for PR36227.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-16 19:22
---
Fixed on the trunk. Also fails with plain -O for 4.3.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
We do not fold
(long int) &16B->y - 16
--
Summary: [4.4 Regression] g++.dg/init/const7.C XFAILed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: xfail
Severity: normal
Priority: P3
Component: middl
Currently, following test fails on alpha target:
FAIL: gfortran.fortran-torture/execute/intrinsic_len.f90 execution, -O2
-fomit-frame-pointer -finline-functions -funroll-loops
This is due to generic scheduler problem, where scheduler doesn't care about
conflictig memory alias sets.
The problem
We do not fold
(long int) ((long unsigned int) b + 5) == (long int) b
--
Summary: [4.4 Regression] gcc.dg/tree-ssa/foldaddr-1.c XFAILed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: xfail
Severity: normal
P
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-16 19:18
---
Subject: Bug 38835
Author: rguenth
Date: Fri Jan 16 19:18:18 2009
New Revision: 143442
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143442
Log:
2009-01-16 Richard Guenther
PR tree-optimizatio
1 - 100 of 191 matches
Mail list logo
