--- Comment #21 from bonzini at gnu dot org 2008-02-21 08:13 ---
fixed in 4.4.0
--
bonzini at gnu dot org changed:
What|Removed |Added
Known to work|4.0.2
--- Comment #2 from ludo at gnu dot org 2008-02-21 09:00 ---
(In reply to comment #1)
The only time I can think this comes up is that the sentinel is -1.
As another example, GNU Guile has a number of variadic functions (e.g.,
`scm_list_n ()') whose sentinel is `SCM_UNDEFINED' (which
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
I think Part I: Invoking GNU Fortran of the gfortran documentation should
have a section on Compiling (and linking) mixed-language programs. Whether
this should be a section or a subsection I don't know, but it's really a
commonly asked question and we ought to have explanations and examples of
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-21 10:07
---
I've posted explanations and examples on comp.lang.fortran that might be used
as a starting point:
http://groups.google.com/group/comp.lang.fortran/msg/a62f1aa0c1592838
Linking to C++ and other languages might
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-21 09:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The following code produces an error on the second line inside of main:
error: no match for 'operator' in 'std::cout Cint::E()'
C++ frontend fails to find the templetized operator.
-- begin code
#include iostream
using namespace std;
templatetypename T
struct C {
struct
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-21 09:56 ---
Summary slightly changed. There are two issues now:
- We still do not allow re-association by default, even if we would honor
PAREN_EXPR
- There is no way to allow re-association in the face of PAREN_EXPR
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
--- Comment #3 from cnstar9988 at gmail dot com 2008-02-21 10:26 ---
confirmed.
Checked out revision 132515
gcc version 4.3.0 20080221 (prerelease) (GCC)
gcc -O1 -m32 test.c
aborted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35264
--- Comment #5 from matz at gcc dot gnu dot org 2008-02-21 12:39 ---
Subject: Bug 35264
Author: matz
Date: Thu Feb 21 12:38:35 2008
New Revision: 132521
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132521
Log:
PR target/35264
* config/i386/i386.c
--- Comment #6 from matz at gcc dot gnu dot org 2008-02-21 12:41 ---
Fixed in 4.3 and trunk.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2008-02-21 12:30 ---
Subject: Bug 35264
Author: matz
Date: Thu Feb 21 12:30:00 2008
New Revision: 132520
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132520
Log:
PR target/35264
* config/i386/i386.c
--- Comment #2 from tege-gcc at swox dot com 2008-02-21 13:49 ---
Created an attachment (id=15196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15196action=view)
Alignment test
This is not a strictly correct test case, it may fail even if
the compiler aligns the stack properly,
--- Comment #4 from tege-gcc at swox dot com 2008-02-21 13:57 ---
(From update of attachment 15196)
#include stdlib.h
long align;
foo (int flag)
{
int variable;
if (flag == 0)
return (((long)variable ^ align) 0xf);
align = (long)variable;
foo (flag - 1);
}
main ()
{
if
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-02-21 14:12
---
Still there with on trunk (4.4) and MacOS 10.5.2:
$ cat s.c
int main (void)
{
long double x;
double y;
x = -0.24; y = x;
__builtin_printf (%g %g %g\n, (float) __builtin_asinl(x),
--- Comment #28 from fxcoudert at gcc dot gnu dot org 2008-02-21 13:50
---
That 27-headed (and counting!) monster PR is really hard to deal with. Here is
some more information:
-- On powerpc-apple-darwin-9.2.0 (MacOS 10.5.2), the testcases in comments #0
(original report) and #10
--- Comment #5 from tege-gcc at swox dot com 2008-02-21 14:01 ---
The attachment is not the right file.
I tried to edit it but I cannot find out how to do it.
The proper test case is in the comment before this one.
Sorry, I am bugzilla challenged.
--
--- Comment #3 from tege-gcc at swox dot com 2008-02-21 13:53 ---
Testcase? Because we do align it for both x86_64-* and i386-darwin.
Well, not as mandated in the 64-bit ABI.
Now the SVSV i386 ABI says it should be aligned at 4 (word)
bytes boundary.
This is hardly
This might be a dumb user error but since it works on 32-bit Fedora's, I
thought it best to file a PR and let you folks decide.
On Fedora 7 or 8, when you configure like this, the libgcc_s.o files do not
end up in an install directory that gcc can find afterwards. So you end up
getting a link
--- Comment #1 from rwild at gcc dot gnu dot org 2008-02-21 15:32 ---
*** This bug has been marked as a duplicate of 32415 ***
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-21 15:32 ---
*** Bug 35277 has been marked as a duplicate of this bug. ***
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2008-02-21 15:41 ---
(In reply to comment #1)
Prototype untested patch. Produces
Paolo, do you plan to test your patch and submit it to gcc-patches@ ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-02-21 15:48
---
How does the header manage to fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #3 from loki at gcc dot gnu dot org 2008-02-21 15:48 ---
I can confirm the infinite loop too (r132521).
I am going to look into it.
--
loki at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-02-21 15:50
---
(In reply to comment #14)
How does the header manage to fix this?
The normal functions have the asm extension on them which causes the builtins
to change also.
-- Pinski
--
--- Comment #5 from bonzini at gnu dot org 2008-02-21 15:52 ---
I want to clear 17236 first (and Jakub's tweaks are needed anyway).
Feel free to beat me to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-21 15:53 ---
int variable;
This variable does not have be aligned 16byte.
long long ebi, windowsize, last_windowsize;
Or even these.
The first one is word aligned. The second one just has to be 8 byte aligned.
--
--- Comment #16 from bonzini at gnu dot org 2008-02-21 16:32 ---
So this line of add_builtin_function
tree libname = get_identifier (library_name);
should instead invoke a target hook (defaulting to get_identifier)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #4 from aldot at gcc dot gnu dot org 2008-02-21 16:44 ---
-frtl-abstract-sequences should IMHO be turned on per default for at least -Os
in 4.4
Otherwise literally nobody will notice if it's broken.
thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
--- Comment #7 from pcarlini at suse dot de 2008-02-21 17:06 ---
I understand this is fixed now. Otherwise, please reopen (and sorry ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
The following program correctly generates an error:
---
int g_foo;
---
$ ~/gcc/bin/g++ -c -Wall test.cpp
test.cpp:1: error: 'g_foo' declared as reference but not initialized
The following program fails to generate an error (which seemingly is a
violation of the C++ standard) but also doesn't even
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-02-21 16:52 ---
Mine. I need to redo this page anyway.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-21 18:44
---
gfortran-4.0.1 is really old, this code works fine for 4.3.0 so I suggest we
close it as WONTFIX. Please reopen if you can reproduce this with a more recent
compiler.
Thanks for the bug report.
--
fxcoudert
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2008-02-21 18:47
---
(In reply to comment #16)
Our positron branch has the fix for this in it. We should dig it out and
submit it.
Mike, any news on that? You can still make it in time for the 5th anniversary
of this PR! :)
--
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-21 19:34 ---
Yes, it was approved by Jakub.
To be precise, approved by Paolo in
http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html
and acked for 4.3 by me.
Anyway, AFAIK the http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00877.html
--- Comment #18 from mrs at apple dot com 2008-02-21 19:48 ---
Nope.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
With -O3, I get an apparently incorrect array subscript is above array bounds
warning when a multidimensional array is passed to a function and accessed in a
loop:
$ /home/tmp/u/rjpeters/gcc-svn-install/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #1 from rjpeters at klab dot caltech dot edu 2008-02-21 19:47
---
Created an attachment (id=15197)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15197action=view)
test case; compile with -Wall -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35279
--- Comment #5 from rwild at gcc dot gnu dot org 2008-02-21 19:57 ---
Subject: Bug 35273
Author: rwild
Date: Thu Feb 21 19:56:23 2008
New Revision: 132529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132529
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to
If you leave out the format of a print statement, as in
program test
integer, parameter :: n = 2
print n
end program test
...you get an ICE instead of an error message. I can't run the latest version
of gfortran now, so please close if this is already fixed.
--
--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-21 20:05 ---
Subject: Bug 35273
Author: rwild
Date: Thu Feb 21 20:05:11 2008
New Revision: 132530
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132530
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to
--- Comment #7 from rwild at gcc dot gnu dot org 2008-02-21 20:07 ---
(In reply to comment #3)
Yes, it was approved by Jakub.
To be precise, approved by Paolo in
http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html
and acked for 4.3 by me.
Yes, sorry for being imprecise.
Anyway,
--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-21 19:56 ---
Subject: Bug 35273
Author: rwild
Date: Thu Feb 21 19:55:39 2008
New Revision: 132528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132528
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to
/usr/local/gcc43/bin/gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --prefix=/usr/local/gcc43
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls
--- Comment #11 from reichelt at gcc dot gnu dot org 2008-02-21 21:07
---
Adjust target milestone.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
GCC
The following valid testcase is rejected on mainline and 4.3 branch:
=
templateint struct A
{
templateint void foo();
};
template templateint void A0::foo() {}
=
The regression was introduced
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
--- Comment #17 from ubizjak at gmail dot com 2008-02-21 21:28 ---
(In reply to comment #16)
So this line of add_builtin_function
tree libname = get_identifier (library_name);
should instead invoke a target hook (defaulting to get_identifier)?
And IMO
--- Comment #1 from ubizjak at gmail dot com 2008-02-21 21:35 ---
I know that the test sources are probably trivial, but can you post them here
for reference?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
--- Comment #21 from ubizjak at gmail dot com 2008-02-21 21:54 ---
(In reply to comment #20)
Here are 2 alternatives I've been playing with:
Any news on this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-21 21:58 ---
Confirmed ICE with 4.1.2 and 4.2.4. However, 4.3 (20080210) gives:
pr35280.f90:3.7:
print n
1
Error: Constant expression in FORMAT tag at (1) must be of type default
CHARACTER
Closing.
--
dfranke at
--- Comment #2 from astrange at ithinksw dot com 2008-02-21 21:58 ---
Created an attachment (id=15199)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15199action=view)
source
Oh, I forgot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
--- Comment #7 from tege-gcc at swox dot com 2008-02-21 22:01 ---
Sorry, but you ought to read and understand what I write before
you comment, otherwise it becomes rather pointless.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
As reported in http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html, I
am seeing a few hundred failures for ACATS on i386-rtems4.9. The failure set
appears to be about the same for 5.3.4, 4.3-branch, and SVN trunk. I am trying
to debug
this on the SVN trunk. I have finally captured the
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-21 22:10 ---
Created an attachment (id=15200)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15200action=view)
QEMU trace up to branch to 0x0
Search for ^0x and then scroll backwards to see the indirect call in
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-21 22:11 ---
Created an attachment (id=15201)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15201action=view)
numerically sorted symbol table matching qemu.log
This is the numerically sorted symbol table matching the attached
--- Comment #3 from laurent at guerby dot net 2008-02-21 22:32 ---
The great majority of FAIL are tests with an Ada task so my guess is that
tasking is broken.
I'm not a specialist but GNAT soft links are pointers to function which are set
by the elaboration code to point to tasking or
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-21 22:52 ---
Runs OK on powerpc/psim and sparc/sis built from the same source tree for GCC
and RTEMS.
Fails like a99006a on i386.
Are there only ~300 tests which rely on tasking? I posted this URL:
--- Comment #5 from joel at gcc dot gnu dot org 2008-02-21 22:53 ---
Created an attachment (id=15202)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15202action=view)
generated from Laurent's t.adb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #1 from pcarlini at suse dot de 2008-02-21 22:25 ---
Please double check, but I don't think it's my patch: I tried quickly reverting
it and interestingly nothing changes: 28743 doesn't ICE and this one is
rejected. It seems something new is going on in this area... Maybe
--- Comment #2 from pcarlini at suse dot de 2008-02-21 23:13 ---
Never mind, I did something wrong in my quick check. I can confirm it's my
patch. I'll try to look a bit into it, but beyond reverting it, I cannot
promise to be able to fix the present issue without regressing on 28743...
I noticed today (gcc version 4.4.0 20080221) two failures in FM827 when running
the NIST test suite with -m64. I have reduced the code to:
PROGRAM FM827
DOUBLE PRECISION AVD, BVD, CVD, DVD, DVCORR
IVPASS = 0
IVFAIL = 0
IVDELE = 0
IVINSP = 0
--- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 ---
Could you post the exact backtrace on my testcase? It purposely doesn't use the
complex Text_IO so things should be clearer. Also if you could use gdb to get
an understanding of what is done during adainit execution
--- Comment #7 from joel dot sherrill at oarcorp dot com 2008-02-21 23:55
---
Subject: Re: Branch to 0x0 from Ada run-time
laurent at guerby dot net wrote:
--- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 ---
Could you post the exact backtrace on my testcase?
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2008-02-22 00:34
---
Created an attachment (id=15203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15203action=view)
Partial patch
Another approach, maybe more efficient, is to offer a target hook to fix
builtins after
--- Comment #1 from hutchinsonandy at aim dot com 2008-02-22 01:22 ---
This appears to be due to avr_rtx_costs not assigning same cost to SYMBOL_REF
and CONST_INT. So SYMBOL_REF looks expensive - so is held in register to avoid
recalculating it.
Quick change to make SYMBOL_REF same
--- Comment #2 from hutchinsonandy at aim dot com 2008-02-22 01:43 ---
We have not gotten around to adding support for tail calls for avr. So nothing
happens. So it is not a bug - but a still a valid feature request.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34790
--- Comment #12 from janis at gcc dot gnu dot org 2008-02-22 01:56 ---
Subject: Bug 34526
Author: janis
Date: Fri Feb 22 01:55:40 2008
New Revision: 132537
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132537
Log:
PR target/34526
* config/rs6000/rs6000.c
--- Comment #13 from janis at gcc dot gnu dot org 2008-02-22 01:58 ---
Subject: Bug 34526
Author: janis
Date: Fri Feb 22 01:57:56 2008
New Revision: 132538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132538
Log:
PR target/34526
* config/rs6000/rs6000.c
--- Comment #3 from eric dot weddington at atmel dot com 2008-02-22 04:02
---
Can you try using linker relaxation?:
-Wl,--relax
Linker relaxation is implemented in ld for the AVR port, even though the
documentation doesn't say so. IIRC, tail call optimization is implemented in
linker
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2008-02-22
04:08 ---
FX,
I posted a modified version of Andrew's proposed patch awhile back...
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01809.html
which had additional changes to gcc/config/rs6000/darwin.h and
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-22 06:18 ---
Subject: Bug 1
Author: rwild
Date: Fri Feb 22 06:17:46 2008
New Revision: 132540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132540
Log:
gcc/:
PR c/1
* c-typeck.c (build_binary_op): Warn about
--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-22 06:19 ---
Fixed in 4.4.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-02-22 06:22
---
Subject: Bug 34907
Author: jvdelisle
Date: Fri Feb 22 06:21:47 2008
New Revision: 132541
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132541
Log:
2008-02-20 Jerry DeLisle [EMAIL PROTECTED]
PR
This was discussed with Dan Berlin. File this report as a place holder for the
problem. In the following example, load of g1.a at return statement is fully
redundant, but not removed.
int g2;
struct A {
int a; int b;
}g1;
int foo(int a, int b)
{
if (a 0)
{
g1.a = a+ b;
}
Daniel is aware of the problem.
In the followign example, *gp at return is partially redundant. Not eliminated.
int *gp;
int g, g2;
int foo(int p)
{
int t = 0;
if (p)
t = *gp + 1;
return (*gp + t);
}
--
Summary: Missing PRE for indirect load
Product: gcc
double a,b,c,d,e,f;
// int a,b,c,d,e,f;
void foo()
{
e = b*c/d;
f = b/d*a;
}
Compile with -O3 -ffast-math, b/d should be CSEed.
--
Summary: missing CSE of division (lack of reassociation)
Product: gcc
Version: unknown
Status: UNCONFIRMED
The second instance of a1+a2 is not PREed due to missing expression
reassociation.
int foo(int a1, int a2, int a3)
{
int b1,b2;
b1 = a3 + a2 + a1;
b2 = a1 + a2;
return b1 + b2;
}
--
Summary: Expression reassociation problem
Product: gcc
Version:
union U {
struct C
{
char c[4];
}cc;
int ii;
} u ;
void foo(int i)
{
u.cc.c[0] = 10; // Dead
u.cc.c[1] = 10; // Dead too
u.cc.c[i] = 10; // Dead too
u.ii = 20;
}
--
Summary: Missing DCE for union fields
Product: gcc
Version:
union U {
struct C
{
char c[4];
}cc;
int ii;
} u ;
int foo(int i)
{
u.ii = 20;
return u.cc.c[0] + u.cc.c[1]; // Const prop target -- not performed
}
--
Summary: Missing Const Prop -- union fields
Product: gcc
Version: unknown
--- Comment #20 from ubizjak at gmail dot com 2008-02-22 06:54 ---
(In reply to comment #18)
call this single target hook: Paolo, Uros, could you work that bit out? (It's
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
void foo(int*p, int*q)
{
*p = 10; // --- dead, but not removed
*q = 20;
*p = 30;
}
int g;
void bar(int* p)
{
*p = 10; // Dead -- not removed.
g = 1;
*p = 10;
}
--
Summary: Missing dead store elimination
Product: gcc
Version: unknown
With a commit in the range 132503:132513, gfortran.dg/streamio_11.f90
gfortran.dg/streamio_3.f90 and gfortran.dg/streamio_4.f90 started to fail,
besides
the new test gfortran.dg/streamio_15.f90. The failure is just a call to abort.
The patch exposing the failure seems to be
85 matches
Mail list logo
