--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-08 07:09 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootst
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-08 07:15 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
To access a TLS variable in the local-exec model, gcc will emit three
instructions, for instance (for a 64-bit compile):
addis 9,13,[EMAIL PROTECTED]@ha
addi 9,9,[EMAIL PROTECTED]@l
lwz 3,0(9)
when two instructions would suffice:
addis 9,13,[EMAIL PROTECTED]@ha
lwz 3,[EMAIL PROTECTED]@l(9
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-08 07:30 ---
legitimate_lo_sum_address_p is most likely where the issue, it is returning
false for this case when it should be returning true, I might take more of a
look later today.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-08 07:42 ---
I bet this also can happen in C++ too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-08 07:45 ---
Confirmed.
;; basic block 3, loop depth 0, count 0
;; prev block 2, next block 4
;; pred: 2 [30.0%] (exec)
;; succ: 5 [50.0%] (true,exec) 4 [50.0%] (false,exec)
:;
# SFT.19 = V_MAY_DEF ;
# SFT.20
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-08 07:50 ---
Looks a lot like 26197.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDe
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-08 07:51 ---
Janis could you do a regression hunt for this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-08 07:54 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-08 07:54 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-05-08 07:56
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-08 07:57 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-08 07:57 ---
I am taking care about this one too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-08 07:58
---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-08 07:59 ---
Janis could you do a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-08 08:37
---
A good documentation for PROTECTED, in addition to the standard itself, is
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/protected.htm
--
fxcoudert at gcc dot
--- Comment #7 from mueller at gcc dot gnu dot org 2006-05-08 08:40 ---
Ah, just missed it by a few minutes :)
I've been using this patch:
=== CUT ===
--- c-common.c (revision 113532)
+++ c-common.c (working copy)
@@ -1077,7 +1077,7 @@ convert_and_check (tree type, tree expr)
tre
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:22
---
It appears that the original testcase, involving INT in as specification
expression, is valid F95 and F2003. It was not valid F90, however, because the
return type of INT is real. This is confirmed by the results
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:32
---
Andrew, what is the status on that bug? Do you still observe mismatch in the
testsuite, or can we close the PR?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-08 09:42 ---
This is really a PRE problem, much like the simplified testcase
char firstchar (const char *s)
{
if (!s)
s = "";
return s[0];
}
where it could record the fact that the load from s[0]
--- Comment #10 from anlauf at gmx dot de 2006-05-08 09:46 ---
(In reply to comment #9)
> It appears that the original testcase, involving INT in as specification
> expression, is valid F95 and F2003. It was not valid F90, however, because the
> return type of INT is real. This is confir
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:48
---
Humpf, I created a testcase for inclusion in the testsuite, but it reveals that
overlap of logical cases is not detected when they're separated from each
other:
select case (l)
case (.true.)
case (.false.)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-08 09:57 ---
Patch with discussion:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01038.html
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:57
---
(In reply to comment #10)
> I do not understand why you are closing this one as INVALID,
> since you just argued that it VALID F95 and F2003.
I'm saying that the bug report, which says "This illegal code is wron
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:59
---
Subject: Bug 18271
Author: fxcoudert
Date: Mon May 8 09:59:09 2006
New Revision: 113627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113627
Log:
PR libfortran/18271
* gfortran.dg/spec_
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:03
---
Subject: Bug 18271
Author: fxcoudert
Date: Mon May 8 10:03:11 2006
New Revision: 113628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113628
Log:
PR libfortran/18271
* gfortran.dg/spec_
--- Comment #5 from mueller at gcc dot gnu dot org 2006-05-08 10:06 ---
I'll try taking care.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22303
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-05-08 10:07
---
Doesn't really work, it misses support for STRING_CST. See PR22303.
static const char *foo = "?";
char foobar () { return foo[0]; }
Something like the following should fix it (once fold_read_from_constant_strin
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot
|dot org
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-05-08 10:08
---
Dirk, you may want to take this one, too.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mn
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:43
---
Subject: Bug 27378
Author: fxcoudert
Date: Mon May 8 10:43:18 2006
New Revision: 113629
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113629
Log:
PR fortran/27378
* parse.c (next_stateme
--- Comment #3 from tobi at gcc dot gnu dot org 2006-05-08 10:46 ---
reduced testcase (not valid, but this is another bug):
i = j; end
This bug has nothign to do with parsing of STOP, it needs:
* a statement preceding the end statement, and
* the end statement must follow a semicol
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:46
---
Fixed on 4.1 and mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2006-05-08 10:49 ---
woops, of course I decided to make a valid testcase after I wrote that it
wouldn't be valid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20440
--- Comment #1 from laurent at guerby dot net 2006-05-08 10:49 ---
This is probably because of my run_all.sh patch, sorry about that.
Could you try replacing testsuite/ada/acats/run_all.sh line 242 by:
if [ -z "$main" ]; then
And tell us wether it fixes the problem or not?
I'm testin
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-08 10:49 ---
Fixed with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rakdver at gcc dot gnu dot org 2006-05-08 11:18
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00290.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-08 12:39 ---
It looks like it was easy. (so, I have a patch)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tobi at gcc dot gnu dot org 2006-05-08 12:59 ---
Wow. This is actually a bad bug, but after trying some stuff, I believe that
it only does bad things when the code is non-standard anyway (lines beginning
with ';').
E.g.
[EMAIL PROTECTED]:~/src/pr/20440> cat t.f
The following code snippet causes an ICE:
===
subroutine FOO
X :: I
equivalence (I,I)
end
===
In file bug4.f90:2
X :: I
1
Error: Unclassifiable statement at (1)
bug.f90:0: internal compiler error: Segmentation fault
Please submit a
The following invalid code snippet causes an ICE since GCC 4.1.0:
extern double frexp (double x, int *e);
extern double fabs (double x);
void foo(int *p)
{
fabs(frexp(0.., p));
}
bug.c:6
--- Comment #6 from hjl at lucon dot org 2006-05-08 14:00 ---
It isn't fixed in 4.1.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
The following invalid code snippet causes an ICE since GCC 4.1.0:
==
void foo()
{
switch (,) { }
}
==
bug.c: In function 'foo':
bug.c:3: error: expected expression before ',' token
bug.c:3: internal compiler error: tree check: expected class 'type
The following invalid code snippet causes an ICE since GCC 4.1.0:
==
void foo()
{
sizeof(,);
}
==
bug.c: In function 'foo':
bug.c:3: error: expected expression before ',' token
bug.c:3: internal compiler error: tree check: expected class 'type', h
The following valid code snippet causes an ICE (segfault) since GCC 4.1.0:
int i = (int){i};
--
Summary: [4.1/4.2 regression] ICE on variable initialization
Product: gcc
Version: 4.2.0
Status: UNCONFI
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-08 14:23
---
The patch looks good - are you going to test and submit it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-08 15:06 ---
This is unrelated to that patch I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22303
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-05-08 15:07
---
But that is not related to the orginal bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from janis at gcc dot gnu dot org 2006-05-08 15:08 ---
Very odd; I do nightly builds of mainline on two different systems. On one of
them this failure stopped on 20060430 and on the other it stopped on 20060503,
but failed on 20060502.
--
http://gcc.gnu.org/bugzilla/
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-08 15:12 ---
So what this is not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet causes an ICE since GCC 4.0.3:
=
struct A {};
class B : A
{
virtual A* foo();
};
struct C : virtual B
{
virtual C* foo();
};
C* C::foo() { return 0; }
struct D : C {};
=
bug.cc:10: error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-08 15:19 ---
Confirmed, I know I saw this before.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-08 15:22
---
> Confirmed, I know I saw this before.
You're probably thinking of PR 23172.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27491
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-08 15:26 ---
Can we close this PR now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25496
The following invalid code snippet causes an ICE on mainline:
===
template void foo()
{
struct A {};
}
===
bug.cc:1: error: expected identifier before 'operator'
bug.cc:1: error: expected `>' before 'operator'
bug.cc: In function '
The following invalid code snippet causes an ICE since GCC 3.4.0:
===
struct A
{
template void foo() {}
template void bar() {}
};
===
bug.cc:3: error: expected identifier before 'operator'
bug.cc:3: error: declaration of 'ope
--- Comment #8 from roger at eyesopen dot com 2006-05-08 15:29 ---
I've now reconfirmed that this has been fixed on the gcc-4_1-branch by
Jakub's backport of Zdenek's patch. Thanks to you both.
--
roger at eyesopen dot com changed:
What|Removed |A
The following invalid code snippet causes an ICE since GCC 3.4.3:
===
struct A
{
template void foo();
void bar() { this.A::foo<0>(); }
};
===
bug.cc: In member function 'void A::bar()':
bug.cc:4: internal compiler error: tree
The following invalid code snippet causes an ICE since GCC 3.0:
===
template struct A
{
template friend class X;
};
A<0> a;
===
bug.cc:3: error: 'void' is not a valid type for a template constant parameter
bug.cc: In instantiati
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-08 15:38
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #4 from stephen at marenka dot net 2006-05-08 15:39 ---
Subject: Re: [m68k] Compiled Code Segfaults
On Mon, May 08, 2006 at 03:26:13PM -, kazu at gcc dot gnu dot org wrote:
> Can we close this PR now?
Can't say I like the segfault much, but it doesn't seem to show up
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-08 15:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #15 from kazu at gcc dot gnu dot org 2006-05-08 15:41 ---
I cannot reproduce the problem even with -O2 -fno-trapping-math.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-08 15:41 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.0.4
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27495
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-08 15:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.2.0
http://
--- Comment #16 from kazu at gcc dot gnu dot org 2006-05-08 15:47 ---
Disregard my last comment.
The original testcase still fails if I use -fno-trapping-math.
The testcase in #3 doesn't fail with or without -fno-trapping-math.
--
kazu at gcc dot gnu dot org changed:
Wha
Testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
static const char f[3] = "?";
int foo()
{
int i = 0;
return f[i] != '?';
}
/* { dg-final { scan-tree-dump "return 0;" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
Problem is two-fo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-08 15:53 ---
This is a dup of bug 22303.
*** This bug has been marked as a duplicate of 22303 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-08 15:53 ---
*** Bug 27497 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22303
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-08 15:55 ---
Not reproducible on mainline.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from kazu at gcc dot gnu dot org 2006-05-08 16:00 ---
Andreas, are you going to submit your patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-08 16:01 ---
(In reply to comment #4)
> Patch with discussion:
> http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01038.html
This is unrelated to that patch, PR 26781 references (in passing) what that
patch fixes.
--
http://gcc
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-08 16:04 ---
The mainline works fine.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-08 16:09 ---
Not reproducible with mainline.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-08 16:10 ---
Not reproducible with mainline.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
void zconfdump(void)
{
char *p, *p2;
for (p2 = p; p2; )
{
char __a0, __a1, __a2;
__a0 = ((__const char *) ("\"\\"))[0];
if (__a0)
return;
}
}
we do not fold the read from "\"\\". Me & Dirk have a fix.
--
Summary: fold does not fold reads from co
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-08 16:14 ---
Not reproducible with mainline.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-08
16:18 ---
Subject: Re: Thousands of run_all.sh[242]: ==: A test command parameter is not
valid
> Could you try replacing testsuite/ada/acats/run_all.sh line 242 by:
>
> if [ -z "$main" ]; then
>
> And tell us weth
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-08 16:19 ---
Created an attachment (id=11409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11409&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27498
--- Comment #18 from kazu at gcc dot gnu dot org 2006-05-08 16:19 ---
Not reproducible with mainiline.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-08 16:21 ---
Closed as the submitter agrees.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from laurent at guerby dot net 2006-05-08 16:27 ---
Patch submitted.
--
laurent at guerby dot net changed:
What|Removed |Added
URL|
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-08 16:29 ---
According to Andreas, this works as of 4.0.2.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-08 16:31 ---
[ "x${main}" != "x" ] should also work and maybe a little more portable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27476
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #8 from kazu at gcc dot gnu dot org 2006-05-08 16:32 ---
Works as of 4.1 according to #7.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Now that the really baad OpenMP bugs seem to be fixed (thanhsk for that!) I
have a hopefully easy one: I get an ICE (svn from today) for the following C
code (and the C++ equivalent as well):
void f()
{
unsigned int i;
int dummy;
#pragma omp parallel for
for (i = 0; i < 5;
>-- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-08 16:31 ---
> [ "x${main}" != "x" ] should also work and maybe a little more portable.
That's also fine, although overkill these days.
All host OSes supported by GNAT (and more) accept the following simpler
and cleaner syntax:
--- Comment #5 from charlet at adacore dot com 2006-05-08 16:35 ---
Subject: Re: ACATS: Ada testsuite Bourne shell compatibility problem on hpux
>-- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-08 16:31 ---
> [ "x${main}" != "x" ] should also work and maybe a little
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-08 16:44 ---
Not reproducible.
I built a m68k-elf toolchain on x86_64-pc-linux-gnu and compiled the testcase.
No ICE was observed.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from guerby at gcc dot gnu dot org 2006-05-08 16:50 ---
Subject: Bug 27476
Author: guerby
Date: Mon May 8 16:50:40 2006
New Revision: 113630
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113630
Log:
2006-05-08 Laurent GUERBY <[EMAIL PROTECTED]>
PR tes
--- Comment #7 from laurent at guerby dot net 2006-05-08 16:51 ---
Should be fixed now.
--
laurent at guerby dot net changed:
What|Removed |Added
Status|NEW
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-08 16:55 ---
Still reproducible with mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23695
1 - 100 of 154 matches
Mail list logo
