--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-09-13 06:06
---
Another problem, GNAT Bug Box, is resulted with the tree updated as shown
[...]
c-4.3-20070907/gcc/ada/a-chlat1.ads -o ada/a-chlat1.o
/home/voax/linux/build-4.3.x/./prev-gcc/xgcc
--- Comment #2 from ubizjak at gmail dot com 2007-09-13 06:32 ---
(In reply to comment #0)
$ g++ -c -O2 -g -fPIC -c libkformulalib_la.all_cc.iiIn file included from
libkformulalib_la.all_cc.cc:45:/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc:
In member
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-13 06:39 ---
The (spurious?) warning is also present in 4.3.
The patch here is clearly wrong. If you don't like the warnings, you should
work out why they are being output and fix the underlying bug, rather than
gnoring them
--- Comment #4 from charlet at adacore dot com 2007-09-13 07:47 ---
Subject: Re: ACATS cxa5a09, cxa5a10 and controlled2.adb failure
Your tree is very likely skewed, the Ada compiler bootstraps fine on x86,
x86-64, IA-64 and SPARC at least.
Right. I got a similar failure and fixed
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-09-13
08:22 ---
rechecked with r128456
the compiler is configure with --with-arch=i686 --with-tune=i586 i686-linux
I can reproduce it with -march=i686, not with -march=i486.
Matthias
--
--- Comment #4 from ubizjak at gmail dot com 2007-09-13 09:26 ---
(In reply to comment #3)
the compiler is configure with --with-arch=i686 --with-tune=i586 i686-linux
I can reproduce it with -march=i686, not with -march=i486.
Still no luck there to reproduce segfault. These were my
--- Comment #5 from ubizjak at gmail dot com 2007-09-13 09:28 ---
(In reply to comment #4)
1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu) using
../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
--with-march=i686 --with-tune=i586
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-13 09:33
---
I'm coming back to that issue...
(In reply to comment #4)
I guess we could try to provide a graceful degradation for such systems...
The use of dup() can probably be avoided if dup() isn't available
without
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-13 09:36 ---
Yes, this was an idea I had as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
As I need to port my project to vs2005, and the source code contain some UTF-8
string which is not suitable to represent by escaping, I have to add UTF-8 BOM
to make vs2005 recognize it. But after I added the UTF-8 BOM, gcc can't compile
it anymore, even using -finput-charset=UTF-8, it still say
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-09-13 10:10
---
Subject: Bug 33309
Author: fxcoudert
Date: Thu Sep 13 10:10:11 2007
New Revision: 128457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128457
Log:
PR driver/33309
* gcc.c (xputenv): Make
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-09-13 10:10
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-13 10:33
---
(In reply to comment #2)
I cannot reproduce this on x86-64 (Rev. 128440 of today).
Hum, the only compiler I have right now is a month old (20070814) but I see a
different segfault on x86_64-linux:
Program
--- Comment #8 from arno at heho dot snv dot jussieu dot fr 2007-09-13
10:46 ---
Since January commits to boehm-gc for handling amd64/x86-64 cpu under
GNU/kFreeBSD, I confirm that libgcj-support is OK for x86_64*freebsd
IMHO this PR can be closed
I propose a last 'patch' to hook it
--- Comment #9 from arno at heho dot snv dot jussieu dot fr 2007-09-13
10:48 ---
Created an attachment (id=14201)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14201action=view)
No longer exclude libgcj on x86_64.
--
arno at heho dot snv dot jussieu dot fr changed:
freebsd-spec.h is a bit out of date with what FreeBSD bundle in their gcc.
Attached is a patch to sync things up.
--
Summary: [PATCH] Sync FreeBSD target with upstream
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from uberlord at gentoo dot org 2007-09-13 11:00 ---
Created an attachment (id=14202)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14202action=view)
sync freebsd-spec.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33416
FreeBSD libc now supports dl_iterate_phdr. Instead of hardcoding glibc tests,
maybe it would be better to autotool a test for it instead?
--
Summary: [PATCH] FreeBSD libc now supports dl_iterate_phdr
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #1 from uberlord at gentoo dot org 2007-09-13 11:02 ---
Created an attachment (id=14203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14203action=view)
Test libc for dl_iterate_phdr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33417
--- Comment #25 from hubicka at gcc dot gnu dot org 2007-09-13 11:27
---
Thanks a lot for tracking down this issue. The patch looks correct to me, can
you please send it into gcc-patches?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #6 from ubizjak at gmail dot com 2007-09-13 12:26 ---
(In reply to comment #5)
1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu)
using
../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
--with-march=i686
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-09-13
13:07 ---
This issue is eliminated in Xcode 3.0 of Leopard. I've updated my original
radar bug report to ask that the fix be backported to Xcode 2.5 so that it is
available on Tiger as well but I wouldn't hold my
Linux linker version is reported as 2.18.50.0.2.20070912. configure failed
to parse it.
--
Summary: [4.1/4.2/4.3]: Gcc failed to detect Linux linker version
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #3 from patchapp at dberlin dot org 2007-09-13 13:20 ---
Subject: Bug number PR 33343
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01168.html
--
--- Comment #7 from debian-gcc at lists dot debian dot org 2007-09-13
13:34 ---
sorry, I did make a mistake as well (omitted the -B when checking). The
segfault is gone with this revision.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-13 13:36 ---
12.7.3 Elemental subroutine actual arguments
An elemental subroutine is one that has only scalar dummy arguments, but may
have array actual arguments. In a reference to an elemental subroutine, either
all actual
--- Comment #1 from hjl at lucon dot org 2007-09-13 13:40 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from hjl at gcc dot gnu dot org 2007-09-13 14:12 ---
Subject: Bug 33418
Author: hjl
Date: Thu Sep 13 14:12:37 2007
New Revision: 128465
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128465
Log:
2007-09-13 H.J. Lu [EMAIL PROTECTED]
PR bootstrap/33418
--- Comment #3 from hjl at gcc dot gnu dot org 2007-09-13 14:14 ---
Subject: Bug 33418
Author: hjl
Date: Thu Sep 13 14:13:49 2007
New Revision: 128466
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128466
Log:
2007-09-13 H.J. Lu [EMAIL PROTECTED]
PR bootstrap/33418
Revision 122896, more specifically the change in tree-scalar-evolution.c,
causes a regression on bfin-elf when compiling libiberty's hashtab.c. This
change eliminated a piece of code that examined the cost of a change before
modifying the code. As a result, there are now additional (expensive)
--- Comment #1 from bernds_cb1 at t-online dot de 2007-09-13 15:54 ---
Created an attachment (id=14205)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14205action=view)
Preprocessed source
Use this input file to reproduce the problem.
--
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-13 16:04 ---
Fixed for 4.2.2 and 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2007-09-13 16:05 ---
Fixed for 4.2.2 and 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from jason at gcc dot gnu dot org 2007-09-13 16:06 ---
Fixed for 4.2.2 and 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from hjl at lucon dot org 2007-09-13 16:09 ---
(In reply to comment #25)
Thanks a lot for tracking down this issue. The patch looks correct to me, can
you please send it into gcc-patches?
Honza
Posted at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01178.html
--- Comment #27 from hjl at gcc dot gnu dot org 2007-09-13 16:34 ---
Subject: Bug 33389
Author: hjl
Date: Thu Sep 13 16:33:49 2007
New Revision: 128469
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128469
Log:
2007-09-13 James E. Wilson [EMAIL PROTECTED]
PR
--- Comment #2 from patchapp at dberlin dot org 2007-09-13 17:40 ---
Subject: Bug number PR33231
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01184.html
--
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-13 17:58 ---
Subject: Bug 33412
Author: burnus
Date: Thu Sep 13 17:58:10 2007
New Revision: 128471
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128471
Log:
2007-09-13 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-13 17:59 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-13 18:08 ---
Subject: Bug 33343
Author: burnus
Date: Thu Sep 13 18:08:04 2007
New Revision: 128473
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128473
Log:
2007-09-13 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-13 18:10 ---
FIXED in the trunk (4.3.0). Thanks for the bug report.
The error message is now:
tmpAcc(:,:) = Mul(angles(:,:),ax)
1
Error: Incompatible ranks in elemental procedure (1 and
SomefunctionReturningPointer is actually named Focus. There is also a procedure
of the same name in the package; if the procedure is commented out, the crash
does not happen. The test case is the best description of the problem. It is
short enough to be easily comprehensible.
--
--- Comment #1 from jdgressett at amli-denton dot com 2007-09-13 18:32
---
Created an attachment (id=14206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14206action=view)
Ada source code demonstrating the problem, suitable for gnatchop
This is a complete test case demonstrating
This program:
character*20 a(3)
namelist / nam / a
read (4, nml=nam)
write(6, nml=nam)
end
given the following input (fort.4):
nam
a(1)='aap noot mies wim zus jet',
a(2)='surf.pressure',
a(3)='apekool',
/
produces the following output:
NAM
A=aap noot mies
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-13 18:40 ---
Another example. With gfortran 4.3.0 it print the following, with NAG f95, g95,
ifort and gfortran 4.2.2 the expected.
b1: AAP NOOT MIES WIM ZUS JET
b2: b(2)='SURF.PRESSURE'
This program:
character*20 a(3)
namelist / nam / a
read (4, nml=nam)
write(6, nml=nam)
end
given the following input (fort.4):
nam
a(1)='aap noot mies wim zus jet',
a(2)='surf.pressure',
a(3)='apekool',
/
produces the following output:
NAM
A=aap noot mies
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:43 ---
G, bugzilla
*** This bug has been marked as a duplicate of 33421 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:43 ---
*** Bug 33422 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:44 ---
Two witnesses should be enough ...
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #2 from jdgressett at amli-denton dot com 2007-09-13 18:48
---
+===GNAT BUG DETECTED==+
| 4.2.2 20070909 (prerelease) (i686-pc-linux-gnu) Assert_Failure atree.adb:812|
| Error detected at test2.adb:12:60
--- Comment #4 from hjl at gcc dot gnu dot org 2007-09-13 19:12 ---
Subject: Bug 33418
Author: hjl
Date: Thu Sep 13 19:12:30 2007
New Revision: 128478
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128478
Log:
2007-09-13 H.J. Lu [EMAIL PROTECTED]
PR bootstrap/33418
[EMAIL PROTECTED] rrs]$ cat foo.c
static union {
char buf[((sizeof (long long)) + 15 + (sizeof (long long)))];
long long align_int;
long double align_fp;
} u2;
void
test6 (void)
{
int len;
char *p;
for (len = 0; len 15; len++)
{
p = __builtin___memset_chk (u2.buf, '\0',
I just tried to compile Suse Linux package mysql-5.0.45-18
with the GNU C compiler version 4.3 snapshot 20070907.
The compiler said
if gcc -DHAVE_CONFIG_H -I. -I../../strings -I.. -I../include -I../../include
-DDBUG_OFF -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -DPIC -fPIC
--- Comment #1 from dcb314 at hotmail dot com 2007-09-13 20:09 ---
Created an attachment (id=14207)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14207action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33424
GCC compiles and links a program with a function that should return a value,
yet doesn't. This violates the definition of a value-returning function. See
pp. 148 in The C++ Programming Language: 3rd ed..
GCC information:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-13 20:57 ---
main.cpp: In function 'bool Func1(int)':
main.cpp:43: warning: control reaches end of non-void function
Actually in C++, this is only undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33425
When comparing run time on some (floating point) CPU intensive code, we find
that Intel's ICC (9.1) compiler runs significantly faster (30 - 50%) for some
programs - this seems to stem (large) part from ICC's ability to take advantage
of #pragma ivdep. There may be some other differences of
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-13 21:12 ---
Confirmed. Zdenek, we should now be able to attach this to loop information
and preserve it until data dependence analysis, right?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-13 21:14 ---
What are the exact semantics of ivdep?
Please provide them before asking if we support it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-13 21:21 ---
#pragma ivdep
Says the compiler may assume the following loop nest does not have loop carried
data dependenices.
Supported at least by SGI CC and the Intel compiler.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-13 21:23 ---
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/Pragmas/sgi_html/ch08.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-13 21:25 ---
The SGI compiler restricts the pragma to innermost loops. The Intel compiler
restricts the pragma to affect assumed data-dependencies only, that is, if
data dependence analysis statically can prove a
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-13 21:26 ---
http://www.intel.com/cd/ids/developer/asmo-na/eng/65774.htm?page=4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-13 21:27 ---
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00166.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-09-13 21:52 ---
Revision 116656:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00026.html
causes this regression.
--
hjl at lucon dot org changed:
What|Removed |Added
When comparing run time on some (floating point) CPU intensive code, we find
that Intel's ICC (9.1) compiler runs significantly faster (30 - 50%) for some
programs - this seems to stem (large) part from ICC's ability to take advantage
of #pragma ivdep. There may be some other differences of
--- Comment #8 from gjunk at sapience dot com 2007-09-13 22:21 ---
*** Bug 33427 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
--- Comment #2 from bobby_miesen at yahoo dot com 2007-09-13 22:21 ---
Subject: Re: GCC Compiles C++ program containing value-returning
functions that don't return a value
The reference I'm reading (The C++ Programming Language, 3rd ed., pp.
148) says in section 7.3, A value must be
--- Comment #1 from gjunk at sapience dot com 2007-09-13 22:21 ---
Oops - clicked refresh by mistake- feel free to delete this - sorry.
*** This bug has been marked as a duplicate of 33426 ***
--
gjunk at sapience dot com changed:
What|Removed
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-13 22:56
---
Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html. I'd
be glad if some with access to cris-axis-elf (or another similar newlib target)
could try and build libgfortran with this patch.
gcc.c-torture/execute/loop-15.c fails with -O1 -ftree-vectorize:
loop-15.c: In function 'main':
loop-15.c:40: internal compiler error: in expand_simple_binop, at optabs.c:1306
#0 fancy_abort (file=0xdd5390 /home/ssb/src/r/gcc43/gcc/optabs.c,
line=1306, function=0xdd5870
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-13 23:51 ---
That book is wrong when it comes to the standard.
The standard says (6.6.2/2, last sentence):
Flowing off the end of a function is equivalent to a return with no value; this
results in ___undefined behavior___ in a
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2007-09-14
00:10 ---
Also miscompiled by 4.2 and above: scalarize2.f90
Miscompiled by current trunk: alloc_comp_assign_2.f90 pr19928-2.f90 where_1.f90
where_6.f90
--
belyshev at depni dot sinp dot msu dot ru changed:
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2007-09-14
00:02 ---
I can bootstrap current trunk (r128479) with -ftree-vectorize on
x86_64-unknown-linux-gnu for some time now, and, according to
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00327.html, this problem is
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-14 00:35 ---
Finger trouble.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-09-14 04:12 ---
Please attach a testcase. See
http://gcc.gnu.org/bugs.html
for more information.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #18 from ubizjak at gmail dot com 2007-09-14 05:41 ---
*** Bug 33428 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-09-14 05:41 ---
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #19 from ubizjak at gmail dot com 2007-09-14 05:49 ---
Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as
cofirmed by a couple of dupes. From PR 33428:
gcc.c-torture/execute/loop-15.c fails with -O1 -ftree-vectorize (x86_64):
loop-15.c: In function
80 matches
Mail list logo
