I hope this will be of use to someone. (At least it already helped find
some bugs in tm.texi.)
Usage: Run the script on a mainline GCC source directory. You'll get two
comment-only files, MACHINE.c and MACHINE.h. When you've converted these
into an actual working port, please eliminate *ALL* of
Bootstrap of current trunk on powerpc64-linux fails in libstdc++
building system_error.lo. The code that fails was added a few days
ago,
but the failure seems to be the same as the one reported in PR 31490.
I
verified that the patch from comment #10 of that PR allows bootstrap of
On 9/1/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
OK, great. Here's a draft patch for the trick; this works on the test
case I had, and I'll be testing it now. If it passes testing, and I add
testcases, does this look OK to you?
Thanks for the speedy and
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can guarantee any restricted
pointer that is stored into can't
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can guarantee any restricted
pointer that is stored into can't alias the other restricted pointers.
Those only
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can guarantee any restricted
pointer that is stored into can't
Daniel Berlin wrote:
Again, I'd love to just ignore this and say we don't care.
Ugh. I think you're right that the standard says that we only get to
assume non-aliasing when the pointed-to memory is modified, so
all-parameters-restrict is actually weaker than -fargument-noalias. How
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-09-02
08:24 ---
sorry for the noise, seems to be something else, closing the report.
Matthias
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O0 execution test
WARNING: program timed out.
FAIL:
--- Comment #1 from tbm at cyrius dot com 2007-09-02 08:40 ---
I can reproduce this with
gcc-4.1 -c -mabi=64 -msym32 -mno-abicalls -O
using Debian's gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #2 from tbm at gcc dot gnu dot org 2007-09-02 09:08 ---
I can confirm this with FSF gcc 4.1.3 20070902
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tbm at gcc dot gnu dot org 2007-09-02 09:26 ---
This happens with 4.0 - 4.3. gcc 3.4 didn't have the -msym32 option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #4 from tbm at gcc dot gnu dot org 2007-09-02 09:27 ---
Created an attachment (id=14149)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14149action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
When gcc is configured with, for example, --without-pkgversion, this part of
libjava configure script parses gcj -v output incorrectly, thus encoding
garbage as preprocessor macro and failing:
gcjversion=`$GCJ -v 21 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
An obvious fix would be:
Index:
--- Comment #1 from doko at ubuntu dot com 2007-09-02 11:21 ---
Subject: Re: New: [4.3 Regression] libjava fails to compile
if configure argument contains version
belyshev at depni dot sinp dot msu dot ru schrieb:
When gcc is configured with, for example, --without-pkgversion, this
--- Comment #4 from bonzini at gnu dot org 2007-09-02 11:29 ---
*** This bug has been marked as a duplicate of 32009 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #18 from bonzini at gnu dot org 2007-09-02 11:29 ---
*** Bug 32161 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 11:36 ---
I saw this also asn asked about it on IRC. Note please don't CC anyone unless
you know that they caused the bug. They don't want to be getting all bug
reports.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 11:41 ---
[18:22] apinski
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] apinski new failure
[18:23] apinski on ppc-linux-gnu
[18:23] apinski between
--- Comment #3 from manfred99 at gmx dot ch 2007-09-02 11:53 ---
Jerry, any news on this?
I have seen this pattern many times in legacy fortran77 code,
and the code authors seem to assume that ridiculously large loop
stop values do not compromize performance.
After all, in fortran77
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #14 from guillaume dot melquiond at ens-lyon dot fr 2007-09-02
11:56 ---
Created an attachment (id=14150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14150action=view)
Implements folding of (function 1)
I encountered the same issue with some heavy template code:
--- Comment #3 from hjl at gcc dot gnu dot org 2007-09-02 12:23 ---
Subject: Bug 33276
Author: hjl
Date: Sun Sep 2 12:23:04 2007
New Revision: 128024
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128024
Log:
gcc/fortran/
2007-09-02 H.J. Lu [EMAIL PROTECTED]
PR
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-02
12:28 ---
(In reply to comment #1)
doesn't look robust either; what about
gcjversion=`cat $srcdir/../gcc/BASE-VER`
Agreed, that's much better. To be even more robust, add quotes:
gcjversion=`cat
--- Comment #4 from hjl at lucon dot org 2007-09-02 12:36 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #10 from paolo at gcc dot gnu dot org 2007-09-02 13:02 ---
Subject: Bug 33208
Author: paolo
Date: Sun Sep 2 13:02:31 2007
New Revision: 128025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128025
Log:
/cp
2007-09-02 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2007-09-02 13:03 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
iterator_stack frame;
bar (frame.value);
x = frame.prev;
}
[EMAIL PROTECTED]
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
--- Comment #1 from pinskia at gmail dot com 2007-09-02 13:26 ---
Subject: Re: New: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 13:32 ---
As mentioned by me in comment #1, we cannot warn about this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2007-09-02 13:37 ---
Subject: Re: New: Failed to warn uninitialized stack variable
Not really because this is the same as
bar (frame.value[0]);
Where bar can do pointer tricks to get back to original struct and
then change prev, trust
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 ---
[18:23] apinski between 127935 and 128000
Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
regress, it can be narrowed between 127961 (working) and 127997 (non
working). Note that the
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:43 ---
bar (frame.value);
That call to bar causes the whole frame struct escapes here, not just the array
element.
void bar (mpz_t);
is really:
void bar(int*);
because of array decaying in parameters.
Again with
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42
---
[18:23] apinski between 127935 and 128000
Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:50 ---
Subject: Re: [4.3 Regression] Bootstrap check failures ICE's
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:
--- Comment #3 from dominiq at lps dot ens dot fr
--- Comment #5 from hjl at lucon dot org 2007-09-02 13:56 ---
(In reply to comment #4)
bar (frame.value);
That call to bar causes the whole frame struct escapes here, not just the
array
element.
void bar (mpz_t);
is really:
void bar(int*);
because of array decaying in
--- Comment #6 from hjl at lucon dot org 2007-09-02 13:58 ---
(In reply to comment #5)
What does bar get back to? Are you saying if a pointer is passed to bar,
it can get back to any original struct where the pointer is a field?
If you can write such a function, I can pass you a
On 2 Sep 2007 13:56:13 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
What does bar get back to? Are you saying if a pointer is passed to bar,
it can get back to any original struct where the pointer is a field?
It only matters at the context at the point bar is called with the
struct.
--- Comment #7 from pinskia at gmail dot com 2007-09-02 14:01 ---
Subject: Re: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:56:13 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
What does bar get back to? Are you saying if a pointer is passed to bar,
it can get
On 2 Sep 2007 13:58:23 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
If you can write such a function, I can pass you a pointer and your function
will be wrong.
yes so but that call would be undefined, not the one we are talking
about currently.
--Pinski
--- Comment #8 from pinskia at gmail dot com 2007-09-02 14:02 ---
Subject: Re: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:58:23 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
If you can write such a function, I can pass you a pointer and your function
will
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-02 14:03 ---
What does bar get back to? Are you saying if a pointer is passed to bar,
it can get back to any original struct where the pointer is a field?
No, but if you pass a pointer to a field of a struct the callee may
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/990404-1.c
-w
-O3 -fomit-frame-pointer -fno-show-column -lm -o
/home/dave/gcc-4.3/objdir
/gcc/testsuite/gcc/990404-1.x3(timeout = 300)
PASS:
I'm trying to run gfortran under Windows Vista. I ran into ld: crt2.o: No such
file. I've found several reports on this, but no solution... Is there a
solution available already?
--
Summary: gfortran crt2.o not found under Vista
Product: gcc
Version: 4.2.2
--- Comment #5 from michelin60 at gmail dot com 2007-09-02 15:23 ---
I am beginning to enjoy this:
There are about 34 hours between the first indication of failure on regress an
my report. There are about 8 hours between my report and the first
acknowledgment by GCC. This came by
--- Comment #2 from pcarlini at suse dot de 2007-09-02 15:23 ---
Currently 4_2-branch and 4_1-branch also give the same.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from yakov at emc dot com 2007-09-02 15:44 ---
Subject: Re: impossible constraint in asm
pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-01 19:51
---
-msoft-float disables the floating register stack so this
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-02 15:55 ---
I see this as well from time to time. SLES10-SP1 x86_64.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-02 16:08
---
Well, it has not been on my top burner. Looking at -fdump-tree-original the
problem can be seen easily. Fixing is not so straight forward. This will
probably not happen until 4.4.
--
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-02 16:38 ---
See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/11acfc0d9e65566e/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
The following Fortran 90 program crashes gfortran-4.2.1:
program test
real(kind=8),parameter :: beta0(3) = (/ 1.0, 1.0, 1.0 /)
integer :: i(3)
real(kind=8) :: beta(3), beta_coef
i = (/ 1, 2, 3 /)
beta_coef = 1.0
beta = beta0(i) * beta_coef
end program test
--- Comment #4 from pcarlini at suse dot de 2007-09-02 17:12 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-09-02 17:19
---
As mentioned by Richard and I, this bug is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-02 17:49 ---
Lets see, IBMers working on GCC: more than 11.
Intel folks working on GCC: ~3 or so.
AMDers working on GCC: at least 4 but growing (includes Michael Meissner).
Googlers: who knows any more :) (but at least 10).
[18:22] apinski
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] apinski new failure
[18:23] apinski on ppc-linux-gnu
[18:23] apinski between 127935 and 128000
[18:32] Rhyolite I guess it could be due to my predicate change
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
This shows up on both powerpc-linux-gnu and powerpc-darwin. Confirmed because
it shows up in many different testresults.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
I just filed a new bug without any of the extra crap: PR 33283.
*** This bug has been marked as a duplicate of 33283 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
*** Bug 33277 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I think the following is invalid, but not rejected:
SUBROUTINE a
intrinsic cos
entry cos(x)
real x
x = 0
end subroutine
end
NAG f95 shows:
Error: a.f90, line 5: Multiply defined symbol COS
Ifort shows:
fortcom: Error: a.f90, line 2: Conflicting attributes or multiple declaration
of name.
On Mandriva 2008 beta 2
[EMAIL PROTECTED] Ftest]$ gcc -v
Using built-in specs.
Target: x86_64-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-02 18:12 ---
Could you try with GCC gfortran 4.3.0? I can reproduce the problem with
gfortran 4.2.x but not with gfortran 4.3.0 which indicates that this has been
fixed meanwhile.
If you don't want to build GCC yourself (as you
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-02 18:27 ---
(In reply to comment #3)
No, the syntax is:
READ format[, io-list]
and ('f.3.3') as a constant-string expression for the format; this is similar
to PRINT ('f3.3'), a.
This should be distinguished from:
--- Comment #26 from marcus at jet dot franken dot de 2007-09-02 18:35
---
btw, this went latent again with commit r127834:
+2007-08-27 Daniel Berlin [EMAIL PROTECTED]
+
+ Fix PR tree-optimization/33173
+ * tree-ssa-alias.c (find_used_portions): Fix reversed test.
--- Comment #2 from rainy6144 at gmail dot com 2007-09-02 18:38 ---
Thank you. The bug appears to have been fixed in the latest 4.3.0 snapshot
(r128023).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-02 18:42 ---
(In reply to comment #4)
if the first item after the ( is a default-char-expression
(constant or not) and there is no ...= (e.g. fmt=) in there, then it is
also a READ format statement.
This is wrong. In
--- Comment #6 from tobi at gcc dot gnu dot org 2007-09-02 18:48 ---
(In reply to comment #5)
(In reply to comment #4)
if the first item after the ( is a default-char-expression
(constant or not) and there is no ...= (e.g. fmt=) in there, then it
is
also a READ format
--- Comment #3 from michelin60 at gmail dot com 2007-09-02 18:57 ---
Well here it is for interfering with Mr Guenther doing the reasonable thing.
This arbitrariness and unwarranted interference led me to do this.
It is also interesting to look a the GCC.mailing.list for June and July
All exception related tests fail on this target. For example,
Executing on host: /home/gnu/gcc/objdir/gcc/xgcc -B/home/gnu/gcc/objdir/gcc/
/xx
x/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-5.c -fexceptions -fno-show-column
-lm -o ./cleanup-5.exe(timeout = 300)
PASS: gcc.dg/cleanup-5.c (test
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-09-02 20:57
---
This is assuming that an asymmetric range is permitted in Fortran which I think
it is not. You can use -fno-range-check to disable this check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
--- Comment #2 from kargl at gcc dot gnu dot org 2007-09-02 21:04 ---
The number 2147483648 is too big. The minus sign is a unary operator.
Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1'
--
kargl at gcc dot gnu dot org changed:
What
class C1
{
public:
C1();
static int x;
};
#if 1
namespace C1
{
int x;
};
#else
int C1::x;
#endif
class C2
{
public:
C2();
C1 c; // ! error here
};
when the static field is defined inside the namespace block, the definition of
the C1 class is no longer
--- Comment #4 from pcarlini at suse dot de 2007-09-02 23:00 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from pcarlini at suse dot de 2007-09-02 23:29 ---
Humm, too tricky.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #3 from jlaw at uoguelph dot ca 2007-09-03 01:50 ---
(In reply to comment #1)
This is assuming that an asymmetric range is permitted in Fortran which I
think
it is not. You can use -fno-range-check to disable this check.
In the IBM XL Fortran 90 manual:
pg 19
I
--- Comment #4 from jlaw at uoguelph dot ca 2007-09-03 02:32 ---
(In reply to comment #2)
The number 2147483648 is too big. The minus sign is a unary operator.
Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1'
option: -fno-range-check is supposed to be
--- Comment #5 from kargl at gcc dot gnu dot org 2007-09-03 03:43 ---
(In reply to comment #4)
(In reply to comment #2)
The number 2147483648 is too big. The minus sign is a unary operator.
Either use the compiler option that Jerry mentioned or use 'k = - huge(k) -
1'
--- Comment #6 from kargl at gcc dot gnu dot org 2007-09-03 03:58 ---
(In reply to comment #3)
(In reply to comment #1)
This is assuming that an asymmetric range is permitted in Fortran which
I think
it is not. You can use -fno-range-check to disable this check.
In the IBM XL
80 matches
Mail list logo
