--- Comment #6 from jb at gcc dot gnu dot org 2008-05-09 06:15 ---
Another solution is to have status flags for allocated and associated in the
descriptor, IIRC at least Pathscale does this.
Aren't there actually free bits left in the dtype flag that gfortran could use,
without
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-09 08:03
---
Subject: Bug 36162
Author: fxcoudert
Date: Fri May 9 08:02:52 2008
New Revision: 135109
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135109
Log:
PR fortran/36162
* module.c
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-09 08:04
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
cat -n bug.cc
1 struct Base {
2 virtual ~Base() {}
3 virtual void f() = 0;
4 };
5 struct Derived : Base {
6 Derived();
7 virtual void f() {}
8 };
9 struct Foo {
10 Foo(Base);
11 };
12
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||wrong-code
--- Comment #5 from ubizjak at gmail dot com 2008-05-09 09:12 ---
Probably duplicate of or at least related to PR35215 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 09:21 ---
Confirmed. We move parameter initialization after the call...
this-D.2090._vptr.Base = _ZTV7Derived[2];
__comp_ctor (foo, this-D.2090);
@@ -59,11 +59,11 @@
movq%rbx, %rsi
subq$16,
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 09:10 ---
The integer vector operation
(gdb) call debug_generic_expr (phi)
vect_var_.32_20 = PHI vect_var_.32_21(4), { 0, 0, 0, 0 }(9)
is not considered a simple iv.
--
rguenth at gcc dot gnu dot org changed:
$ cat a.f90
program test0
implicit none
integer :: x = 1
write(*,*) cmplx(b'0110100101010001',1,4)
write(*,*) cmplx(b'0110100101010001',x,4)
end program test0
$ gfortran a.f90
$ ./a.out
( 2.6457512, 1.)
( 1.07645030E+09, 1.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-09 09:40
---
And a related issue:
program test0
implicit none
integer :: x = 0
write(*,*) cmplx(b'10110100101010001',x,4)
end program test0
This should error with BOZ constant at (1) is too large
--- Comment #3 from sam at gcc dot gnu dot org 2008-05-09 09:46 ---
This is not a GCC bug in this case, the Ptr formal parameter masks the Ptr
type.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sam at gcc dot gnu dot org 2008-05-09 09:48 ---
This appears to be fixed in SVN trunk:
25.pak3.x2.p1(5); -- line 25
|
actual for x1 must be a variable
27.pak3.x3.all.p1(7); -- line 27
|
actual for
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-09 09:51 ---
This appears to be already fixed on SVN trunk:
Do_Stuff( Thing : in D ) = 0
Finalize( Thing : in out D ) = 0
Finalize( Thing : in out D ) = -1
--
sam at gcc dot gnu dot org changed:
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2008-05-09
09:59 ---
Fixed long ago.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #6 from riku dot voipio at iki dot fi 2008-05-09 10:05 ---
The attached testcases compile now fine with gcc 4.3 branch updated to 20080501
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-4'
--- Comment #7 from hp at gcc dot gnu dot org 2008-05-09 10:16 ---
(In reply to comment #5)
I am testing this patch on x86. But hp needs to test it on the cris
before i will ask for approval.
The patch works with no regressions; tested against 135097 for cris-elf and
crisv32-elf.
--- Comment #6 from ubizjak at gmail dot com 2008-05-09 11:13 ---
Something interesting:
In atomic_kind_types.F.085t.copyprop3, we have:
bb 76:
D.2711_888 = *atomic_kind_38(D);
D.2731_889 = D.2711_888-element_symbol[1]{lb: 1 sz: 1};
__builtin_memcpy (element_symbol[1]{lb: 1 sz:
--- Comment #7 from ubizjak at gmail dot com 2008-05-09 11:18 ---
-fdump-tree-fab-details:
;; Function read_atomic_kind (__atomic_kind_types_MOD_read_atomic_kind)
Simplified
__builtin_memset (element_symbol[2]{lb: 1 sz: 1}, 32, 1);
to
(void) 0;
--
--- Comment #8 from zadeck at naturalbridge dot com 2008-05-09 11:20
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
hp at gcc dot gnu dot org wrote:
--- Comment #7 from hp at gcc dot gnu dot org 2008-05-09 10:16 ---
(In reply to comment
--- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 ---
You know I'm still not sure if I can review patches outside df* (i.e. files
that do what flow.c did, but are not dataflow related), but if you think I
can... then patch is ok. :-)
--
--- Comment #8 from ubizjak at gmail dot com 2008-05-09 11:48 ---
Patch in testing:
Index: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c (revision 135108)
+++ tree-ssa-ccp.c (working copy)
@@ -2916,6 +2916,9 @@
--- Comment #9 from ubizjak at gmail dot com 2008-05-09 11:50 ---
*** Bug 35215 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2008-05-09 11:50 ---
The proposed patch is attached to PR36129. Should also fix this PR.
*** This bug has been marked as a duplicate of 36129 ***
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #10 from ubizjak at gmail dot com 2008-05-09 11:54 ---
The same problem is on 4.3 branch, as confirmed by the dupe.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from zadeck at naturalbridge dot com 2008-05-09 11:58
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
bonzini at gnu dot org wrote:
--- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 ---
You know I'm still not sure
--- Comment #5 from zadeck at gcc dot gnu dot org 2008-05-09 12:15 ---
Subject: Bug 36117
Author: zadeck
Date: Fri May 9 12:14:57 2008
New Revision: 135113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135113
Log:
2008-05-08 Kenneth Zadeck [EMAIL PROTECTED]
PR
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #11 from zadeck at naturalbridge dot com 2008-05-09 12:25
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
zadeck at naturalbridge dot com wrote:
--- Comment #10 from zadeck at naturalbridge dot com 2008-05-09 11:58
---
--- Comment #12 from zadeck at naturalbridge dot com 2008-05-09 12:29
---
Patch committed.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #2 from wouter dot vermaelen at scarlet dot be 2008-05-09
13:02 ---
This bug seems to be introduced in (or triggered by) revision 135053:
[EMAIL PROTECTED] - still ok
[EMAIL PROTECTED] - generates wrong code
--
wouter dot vermaelen at scarlet dot be changed:
--- Comment #5 from andreasmeier80 at gmx dot de 2008-05-09 13:18 ---
Perhaps it is a good idea to add the testcase to the testsuite
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34496
A similar problem as PR33870 is still present as seen with the attached
testcase
(forwarded from https://bugzilla.novell.com/show_bug.cgi?id=388664):
g++-4.3 -O2 -o t testfoo.cxx
./t
start test
dbl2 data error 0x0
dbl2 data error 0x4002, value n was 1.00
fail e.g. interesting
g++-4.3 -O2 -o
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 13:26 ---
Created an attachment (id=15619)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15619action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-09 13:29 ---
The symptom of the alias problem is that we apply store-motion to
aTmp.eType = SbxDataType( p-eType | SbxBYREF );
but reads through
p = aTmp; goto start;
in that stmt incorrectly do not alias
--- Comment #5 from bonzini at gnu dot org 2008-05-09 13:36 ---
Created an attachment (id=15620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620action=view)
patch for cris problem
This patch should fix the CRIS problem. However, we should also check that it
does not make
--- Comment #6 from bonzini at gnu dot org 2008-05-09 13:37 ---
Richard (Sandiford), could you look at the patch? You are the varasm.c expert.
:-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2008-05-09 13:37 ---
not wrong-code, it fails to assemble.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 13:56 ---
Created an attachment (id=15621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15621action=view)
more minimized testcase
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.2.3 4.4.0
Target Milestone|--- |4.3.1
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-09 14:09 ---
The following aborts with -O2 --param max-aliased-vops=N with N in [19, 25]
on x86_64-unknown-linux-gnu. Symptom is still lim being wrongly applied.
If you cannot reproduce it search for the correct N with
for n
--- Comment #11 from ubizjak at gmail dot com 2008-05-09 14:17 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00562.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #31 from jakub at gcc dot gnu dot org 2008-05-09 14:18 ---
Alternate patch to #c12 that doesn't touch at all rs6000_legitimate_address,
just changes print_operand_address:
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-09 14:26 ---
We don't properly mark all fields of the union as base_for_components. But
the real problem is probably that field-sensitive PTA doesn't consider
structs with unions but we still create SFTs for them. If we didn't
--- Comment #32 from jakub at gcc dot gnu dot org 2008-05-09 14:32 ---
Actually find_constant_pool_expr can be simplified, given that
constant_pool_expr_1 had to return 1 each time.
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++
--- Comment #8 from dje at gcc dot gnu dot org 2008-05-09 14:36 ---
The TOC anchor SYMBOL_REF does not have an associated DECL, so the new patch
crashes with a segfault. I'm not sure if there is a safe section to assume for
SYMBOL_REFs without DECLs.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 15:04 ---
Kenny, that's your PURE/CONST patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
int f(int lay)
{
static int syncsize, init;
if (init == 0)
syncsize = 1344, init = 1;
return syncsize;
}
store-ccp should handle that.
--
Summary: missed CCP
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 15:35 ---
A get_symbol_constant_value at the right place and time should do the trick.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-09 15:39 ---
I thought I had a bug filed already ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
--- Comment #33 from bonzini at gnu dot org 2008-05-09 15:51 ---
I now think that fixing it in the target is better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #9 from bonzini at gnu dot org 2008-05-09 16:03 ---
I'll revert my patch on Monday even if no alternative solution for PR36090 is
found during the weekend. It opened too big cans of worms for a release
branch, even though it fixed a serious regression.
--
program foo
implicit none
common /mycom/ arr(2)
!$omp threadprivate (/mycom/)
integer i
real*8 arr
do i=1,2
write(*,*) i
arr(i)=0.0d0
enddo
end program
compiled with -S -O2 -fopenmp with gcc 4.1/4.2 generates invalid:
movabsq [EMAIL PROTECTED], %rbp
@TPOFF should be used for
In a recent change gcc became more strict on where trapping instructions can be
placed. They are no longer valid on condexprs. This introduced some
regressions. The tests have been changed to use -fno-trapping-math. We should
investigate if we could optimize them even with trapping math.
The
If the program
---
__complex__ double f (__complex__ double x, double y) {
try {
return x / y;
} catch (char *s) {
return x;
}
}
--
is compiled with cc1plus bug.cc -fnon-call-exceptions, it fails with the
error:
/home/espindola/bug.cc:7:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-09 17:08 ---
Note this is most likely a regression from 3.4.0.
Though -fnon-call-exceptions really is only heavily used in java and java does
not use complex types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36191
--- Comment #34 from dje at gcc dot gnu dot org 2008-05-09 17:14 ---
Subject: Bug 36090
Author: dje
Date: Fri May 9 17:13:30 2008
New Revision: 135118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135118
Log:
PR target/36090
* config/rs6000/rs6000.c
--- Comment #10 from dje at gcc dot gnu dot org 2008-05-09 17:14 ---
Subject: Bug 36182
Author: dje
Date: Fri May 9 17:13:30 2008
New Revision: 135118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135118
Log:
PR target/36090
* config/rs6000/rs6000.c
--- Comment #11 from rsandifo at nildram dot co dot uk 2008-05-09 17:17
---
Subject: Re: [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
bonzini at gnu dot org [EMAIL PROTECTED] writes:
I'll revert my patch on Monday even if no alternative solution for PR36090 is
[forwarded from http://launchpad.net/bugs/211255]
The attached program causes an ICE, seen with 4.1 and 4.3 from the branches;
4.2 instead of ICEing ends with:
Internal Error at (1):
compare_bound(): Bad expression
--
Summary: ICE: Segmentation fault
Product: gcc
--- Comment #1 from doko at ubuntu dot com 2008-05-09 17:47 ---
Created an attachment (id=15622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15622action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-09 18:04 ---
While gfortran should not ICE, this program is seriously flawed with
illegal Fortran. Just one example.
! Simulation parameters
real, parameter :: n = 2, d = 2
! Body masses
real, dimension(n), parameter ::
--- Comment #3 from kargl at gcc dot gnu dot org 2008-05-09 18:15 ---
Add -Wall to your compiler flags!
any(abs(v_hq - v_n precision_goal))) then
1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
You have messed up parentheses.
--
--- Comment #12 from uros at gcc dot gnu dot org 2008-05-09 18:21 ---
Subject: Bug 36129
Author: uros
Date: Fri May 9 18:21:05 2008
New Revision: 135123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135123
Log:
PR tree-optimization/36129
* tree-ssa-cpp.c:
--- Comment #6 from ubizjak at gmail dot com 2008-05-09 18:23 ---
Alexander, can you apply the patch at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00562.html to 4.3 branch and test
if it fixes your ICE? I would like to backport the patch to 4.3.
--
--- Comment #13 from ubizjak at gmail dot com 2008-05-09 18:25 ---
Fixed for 4.4, patch needs to be backported to 4.3 branch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-05-09 18:34 ---
(In reply to comment #6)
Another solution is to have status flags for allocated and associated in the
descriptor, IIRC at least Pathscale does this.
Aren't there actually free bits left in the dtype flag that
--- Comment #22 from aldot at gcc dot gnu dot org 2008-05-09 18:36 ---
$ gcc-4.4.orig-HEAD -O0 -frtl-abstract-sequences -fPIC -S foo.i -o /dev/null
foo.i: In function bazoo:
foo.i:4: error: unrecognizable insn:
(insn 23foo.i:4: internal compiler error: Segmentation fault
Please submit
t.cpp
---
templatetypename T
struct B : T {
enum {N};
static const int num = N;
void f() {num;}
};
---
$ g++ -v -c t.cpp
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--- Comment #1 from lhyatt at gmail dot com 2008-05-09 18:46 ---
Created an attachment (id=15623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15623action=view)
file producing the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-09 18:49 ---
Works at least in GCC 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On mips64-linux-gnu the following testcase aborts:
void abort (void);
__attribute__ ((noinline)) void
f (int i)
{
if (i != 0x87654321)
abort ();
asm ();
}
__attribute__ ((noinline)) void
g (long long a)
{
f (a);
asm ();
}
main ()
{
g
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 19:07 ---
Works with 4.1.2 and 4.0.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from hp at gcc dot gnu dot org 2008-05-09 19:18 ---
There has been some speculation that the back-ends where the bug
appear are *all* to blame by e.g. having a flawed
GO_IF_LEGITIMATE_ADDRESS. A gdb session shows that the back-end
validation hook that is used for the
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-09 19:20 ---
Subject: Bug 36187
Author: rguenth
Date: Fri May 9 19:19:33 2008
New Revision: 135125
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135125
Log:
2008-05-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-09 19:20 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from lhyatt at gmail dot com 2008-05-09 19:22 ---
thanks for looking into it, but I wanted to point out that it does not work on
4.1.2, at least not my build:
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
that is where I am testing it and getting the ICE.
but
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-09 19:24 ---
I will see what happens with this tomorrow when I get around to downloading the
tuples branch on to my laptop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-09 19:25 ---
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
That is a prelease and not a full release. The fix went into the 4.1 branch
after that date :).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from lhyatt at gmail dot com 2008-05-09 19:26 ---
Subject: Re: ICE when accessing static integer constant in
template class
OK thanks for the quick reply; I'll see if we can get updated over here.
-lewis
pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from
--- Comment #13 from hp at gcc dot gnu dot org 2008-05-09 19:28 ---
(In reply to comment #5)
Created an attachment (id=15620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620action=view) [edit]
patch for cris problem
This patch should fix the CRIS problem.
Looks fine
--- Comment #7 from ubizjak at gmail dot com 2008-05-09 19:29 ---
This is not the same failure as PR36129. It is similar, just happens in another
place.
It also fails on x86_64-linux-gnu. I'll look into it.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #8 from ubizjak at gmail dot com 2008-05-09 19:30 ---
Taking bug.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-09 20:05 ---
Subject: Bug 36187
Author: rguenth
Date: Fri May 9 20:04:57 2008
New Revision: 135126
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135126
Log:
2008-05-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-09 20:06
---
I can confirm that fixing the code as suggested does allow this to compile
fine. Also confirming this is an ICE on invalid
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from aurelien at aurel32 dot net 2008-05-09 20:19 ---
This bug is actually only fixed on Debian arm EABI gcc 4.3. The problem is
still present in oldABI.
I guess that the problem is actually still present in upstream gcc, as Debian
applies backports of libobjc and
--- Comment #1 from nemet at gcc dot gnu dot org 2008-05-09 20:46 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00591.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
Sometimes static function prototype declared with static function definition,
but function is never called before definition. So prototype in such cases are
definitely useless.
I think will be good idea to enhance -Wredundant-decls with reporting such
situation.
PS
May be this is already
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-09 21:11 ---
Ping. As the testcase in question is really simple some analysis is
appreciated.
On i686 the testcase is optimized to return 0 via inlining with the very first
CCP pass at -O2. So I don't see how this can fail at
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 21:25 ---
http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00694.html
doesn't have the failure. So, fixed?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from dje at gcc dot gnu dot org 2008-05-09 21:41 ---
HP,
If there is no CONST wrapping the difference of symbols, does the CRIS port
continue to believe the address is legitimate? In other words, Paolo's patch
without the CONST? I would not object to removing the
--- Comment #4 from danglin at gcc dot gnu dot org 2008-05-09 21:55 ---
Appears to be fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-09 22:17 ---
Subject: Bug 22231
Author: tromey
Date: Fri May 9 22:17:00 2008
New Revision: 135128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135128
Log:
gcc
PR preprocessor/22231:
* c-opts.c
--- Comment #5 from tromey at gcc dot gnu dot org 2008-05-09 22:18 ---
Fixed on trunk.
It is very unlikely that this will be back-ported, so I'm closing the bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2008-05-09 23:02 ---
I think we should give an error by default, and only *not* give an
error if -MG is passed. My reasoning is that -MG exists only to disable
this error. I couldn't think of a reason to disable it in other cases.
For
--- Comment #10 from tromey at gcc dot gnu dot org 2008-05-09 23:05 ---
On further reflection I think this is very minor and I'm unlikely
to back-port the fix. So, I am closing this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/ia32, I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr22231.c -MG -MD -c
-fno-show-column -S -m32 -o pr22231.s(timeout = 300)
cc1: error: -MG may
On Linux/ia32, gcc 4.4 revision 135109 gives
Executing on host:
/export/build/gnu/gcc/build-i686-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-i686-linux/gcc/testsuite/gfortran/../../
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/initialization_12.f90
99 matches
Mail list logo
