--- Comment #5 from nemet at gcc dot gnu dot org 2009-01-16 18:57 ---
Subject: Bug 38554
Author: nemet
Date: Fri Jan 16 18:56:47 2009
New Revision: 143440
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143440
Log:
PR target/38554
* expmed.c (expand_shift): With
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 18:57
---
*** This bug has been marked as a duplicate of 36227 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from nemet at gcc dot gnu dot org 2009-01-16 18:57 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 18:57
---
*** Bug 38835 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36227
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-16 18:58 ---
*** This bug has been marked as a duplicate of 38579 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-01-16 18:58 ---
*** Bug 35640 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-16 18:59 ---
Here is another testcase but this time without - :
struct s { int i; };
void g(struct s *);
float a (void)
{
struct s sv;
sv.i = 0;
int d = sv.i;
float d1 = *(float*)d;
g(sv);
return d1;
}
float a1
=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143437] (GCC)
[...@gnu-27 build_base_o3.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38877
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-16 19:18
---
Subject: Bug 36227
Author: rguenth
Date: Fri Jan 16 19:18:18 2009
New Revision: 143442
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143442
Log:
2009-01-16 Richard Guenther rguent...@suse.de
PR
--- 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=gccview=revrev=143442
Log:
2009-01-16 Richard Guenther rguent...@suse.de
PR
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
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) 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:
--- 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
--- 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
--
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 #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
--- 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
--
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 #2 from hjl dot tools at gmail dot com 2009-01-16 19:41 ---
[...@gnu-27 build_base_o3.]$ cat x.cc
#include string
#include utility
template int dim class bar;
template int dim
std::pairbardim *, unsigned int
foo (const std::string name, unsigned int position)
{
--- 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 #3 from hjl dot tools at gmail dot com 2009-01-16 19:46 ---
[...@gnu-27 build_base_o3.]$ cat y.cc
templateclass _T1, class _T2
struct pair
{
typedef _T1 first_type;
typedef _T2 second_type;
_T1 first;
_T2 second;
pair () : first(), second() { }
pair(const _T1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
--- 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 nat...@codesourcery.com
* decl2.c (do_nonmember_using_decl): Don't complain if we find
same
--- 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
--
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
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
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
--- 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
--- 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 #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
--- 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 #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-end
--
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 #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.
--
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
--- 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
--- 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
--
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;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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
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 =
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
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #9 from
--- 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=17121action=view)
minimal file to cause error - needs -fPIC and -O2
somewhere along my trimming exercise, this file stopped
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
!
--- 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=17122action=view)
unmodified preprocessor output
This is the original preprocessor output (renamed to a .c file). Compile with
-fPIC
--- 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 #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=17123action=view)
another test case
I disagree... here is another test case. Semantically, it is the same
as the first one, so
--- 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
--
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 #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
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-16 21:47 ---
http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
--- 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
--
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 #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
--- 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 #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 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=17124action=view)
patch
Patch I am testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
--- 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.
--
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 typename... T struct X {
template typename... U int f() { this-error; }
};
template int Xint,double::fint,double();
--- 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=gccview=revrev=143444
Log:
PR c++/31260
PR c++/38357
* pt.c (tsubst):
--- 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=gccview=revrev=143444
Log:
PR c++/31260
PR c++/38357
* pt.c (tsubst):
--- 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=gccview=revrev=143445
Log:
PR c++/29470
* pt.c (tsubst_decl) [USING_DECL]:
--- 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=gccview=revrev=143446
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow
--- 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 #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 #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=gccview=revrev=143448
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-16 22:45 ---
We demangle it as int Xint, double::fint, double()
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:46 ---
Fixed for 4.4, not fixing accepts-invalid on other branches.
--
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 Xint, double::fint, double()
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 #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 #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 #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
--- 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 #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 #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 #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 #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:11 ---
Patch is ok for the 4.3 branch, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I feel like I must be doing something incredibly stupid (and I'm sorry
if indeed I do) but this:
#include functional
void goo(int);
void foo() {
std::bind (goo,1)(); // works
std::bind (goo,std::placeholders::_1)(1); // does not work
}
--- 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
--- 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 #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=gccview=revrev=143449
Log:
PR c++/38877
* tree.c (lvalue_p_1): Allow
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.2
Known to work||3.4.6
--- 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
--- 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 #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=17125action=view)
testcase reduced to single file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- 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 #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.
--
--- 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 #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)') '
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 #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
--- 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
101 - 200 of 210 matches
Mail list logo
