--- Comment #5 from laurent at guerby dot net 2009-01-27 19:12 ---
Note: C974013 was in the past victim of another miscompilation bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
It was about type based aliasing with a quite long discussion.
--
laurent at guerby dot net chang
(This might affect the C front end also, I have not tried).
Basically, there are situations where g++ -E accepts multi-line string literals
and glues them together into a proper string literal token. If the resulting
preprocessor output is compiled, there are no diagnostics. But if the compiler
is
--- Comment #1 from laurent at guerby dot net 2009-01-27 19:31 ---
This test has arrays of complicated Ada entities so I'm not surprised by stack
usage. Could you report at what task size it passes?
--
laurent at guerby dot net changed:
What|Removed
I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
--- Comment #9 from dj at redhat dot com 2009-01-27 19:38 ---
Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
--
http://gcc.
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-01-27 19:47 ---
4.2.1 arm-eabi doesn't show this:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00989.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15088
--- Comment #5 from paolo at gcc dot gnu dot org 2009-01-27 19:47 ---
Subject: Bug 37554
Author: paolo
Date: Tue Jan 27 19:47:28 2009
New Revision: 143711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143711
Log:
/cp
2009-01-27 Paolo Carlini
PR c++/37554
* c
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-27 19:48
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-01-27 19:55 ---
Created an attachment (id=17195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17195&action=view)
Patch to fix crtstuff.c failure
This patch fixes crtstuff failure with -mcmodel=large.
--
ubizjak at gmail dot co
--- Comment #6 from ubizjak at gmail dot com 2009-01-27 19:57 ---
Steve, can you test this patch if it fixes your bootstrap?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from aurelien at aurel32 dot net 2009-01-27 20:00 ---
Thanks a lot, I confirm it also fixes the original problem, that is problem in
glibc testsuite (test-float and test-ifloat failing on most of the complex
number functions).
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #7 from sje at cup dot hp dot com 2009-01-27 20:03 ---
Did you change cselib_hash_rtx too? I don't see that change in your patch but
I know I need it to get to the shared rtx bug that your patch will hopefully
fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
--- Comment #2 from joel dot sherrill at oarcorp dot com 2009-01-27 20:10
---
Subject: Re: How much stack space should c380004 take?
laurent at guerby dot net wrote:
> --- Comment #1 from laurent at guerby dot net 2009-01-27 19:31 ---
> This test has arrays of complicated Ada
--- Comment #3 from laurent at guerby dot net 2009-01-27 20:16 ---
in gcc/testsuite/ada/acats/run_all.sh there is already some handling of special
tests:
case $i in
cxb30*) EXTERNAL_OBJECTS="$dir/support/cxb30040.o
$dir/support/cxb30060.o $dir/support/cxb30130.o $dir/suppo
--- Comment #4 from joel dot sherrill at oarcorp dot com 2009-01-27 20:21
---
Subject: Re: How much stack space should c380004 take?
laurent at guerby dot net wrote:
> --- Comment #3 from laurent at guerby dot net 2009-01-27 20:16 ---
> in gcc/testsuite/ada/acats/run_all.sh t
$ cat /home/ryan/reduced.i
typedef unsigned int _Uint16t __attribute__((__aligned__(2)))
__attribute__((__mode__(__HI__)));
struct timeval { unsigned tv_sec; };
extern volatile struct timeval mono_time;
struct a { unsigned int time1; };
void sppp_input() {
struct
--- Comment #8 from ubizjak at gmail dot com 2009-01-27 20:28 ---
(In reply to comment #7)
> Did you change cselib_hash_rtx too? I don't see that change in your patch but
> I know I need it to get to the shared rtx bug that your patch will hopefully
> fix.
The fix is not necessary, sin
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-27 20:49 ---
Looks to me like the flipside of libstdc++/7439. More broadly speaking, C99
macros vs. C++98/0x. The current status on this issue is:
For 4.1/4.2/4.3/trunk, C99 macros should be visible with
1) -std=gnu99/c99 in "C
--- Comment #3 from pault at gcc dot gnu dot org 2009-01-27 20:53 ---
See http://gcc.gnu.org/ml/fortran/2009-01/msg00217.html and subsequent
postings.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from jifl-bugzilla at jifvik dot org 2009-01-27 21:07
---
I've just tried it on gcc 4.3.2 for arm-eabi, and can't reproduce it with
either 5.cc or 6.cc any more. -O0 or -O2 didn't make a difference either.
While the principle sort-of seems sound that you shouldn't push t
--- Comment #36 from rob1weld at aol dot com 2009-01-27 21:12 ---
(In reply to comment #33)
*** Bug 38820 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> If I have an old gcc 4.4 installed on my machine, will setting
> GCC_EXEC_PREFIX use the old installed gcc
--- Comment #37 from rob1weld at aol dot com 2009-01-27 21:26 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> > with installed gcc
> > hjl dot tools at gmail dot com wrote:
> > > They sound to me the ideal usage for
--- Comment #38 from rob1weld at aol dot com 2009-01-27 21:32 ---
Clearly, it is wrong:
# locate crtprec80.o
/mnt/drive2/gcc_build/gcc/crtprec80.o
/mnt/drive2/gcc_build/i386-redhat-linux/libgcc/crtprec80.o
/mnt/drive2/gcc_build/prev-gcc/crtprec80.o
/mnt/drive2/gcc_build/prev-i386-redhat
--- Comment #1 from rmansfield at qnx dot com 2009-01-27 21:36 ---
Also reproducible with gcc version 4.4.0 20090127 (experimental) [trunk
revision 143711] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38991
On RHEL5/ia32 and RHEL5/ia64, revision 143711 gave
/export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-27 22:00 ---
Yes this comes down to having the correct version of libelf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
--- Comment #2 from dnovillo at gcc dot gnu dot org 2009-01-27 22:10
---
The libelf included in Red Hat based distros is different than the one we used
to develop LTO. There was a thread on IRC recently where Jakub proposed a way
of working around this:
(16:27:18) jakub: dnovillo: ver
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-27 22:17 ---
I will give it a try.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
--- Comment #10 from rob1weld at aol dot com 2009-01-27 22:28 ---
(In reply to comment #1)
Note that some of the tests require specific features (such as denormalized
long doubles) and are ...
(In reply to comment #4)
> (In reply to comment #3)
> > This is not so much an error in Fortr
When using gfortran 4.3.1 with Fortran modules compiled by older, incompatible
releases like 4.2.4, the error message emitted is vague and does not attempt to
point out the possible incompatibility between compiler and Fortran module.
Many users keep Fortran modules around and would encounter this
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #11 from rob1weld at aol dot com 2009-01-27 22:45 ---
(In reply to comment #9)
> Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
> failing tests that worked previously
>
>
> I think adding a printf() clone to libiberty is WAY overkill just to
> sile
When I configured gcc with --enable-languages=c,c++,fortran, lto1
wasn't built.
--
Summary: [LTO] lto1 isn't built when configured with --enable-
languages=c,c++,fortran
Product: gcc
Version: lto
Status: UNCONFIRMED
Sever
--- Comment #1 from dnovillo at gcc dot gnu dot org 2009-01-27 23:00
---
No, of course not. This is by design. The lto1 binary is the front end for
GIMPLE, as with any other front end, it has to be specifically requested when
configuring the compiler. You have to add 'lto' to the li
--- Comment #5 from jason at redhat dot com 2009-01-27 23:25 ---
Subject: Re: [4.4 Regression] g++.dg/init/const7.C XFAILed
rguenth at gcc dot gnu dot org wrote:
> I just found this, I tried to fix this in fold but in the end agreed with
> Andrew that the C++ FE should do what the C FE
--- Comment #12 from rob1weld at aol dot com 2009-01-27 23:26 ---
(In reply to comment #11)
> (In reply to comment #9)
> Two alternatives are:
I guess there is three.
3. The gcc Testsuite is testing 'outside of gcc' and exercising the
libraries of the Operating System (maybe GNU libc /
--- Comment #7 from rob1weld at aol dot com 2009-01-27 23:33 ---
Added "Known to work" 4.4.0 (gcc version 4.4.0 20090126 (experimental) [trunk
revision 143680]).
Tested on OpenSolaris 2008.11 i386-pc-solaris2.11 and Fedora 10
i386-redhat-linux-gnu .
Rob
--
rob1weld at aol dot com c
--- Comment #9 from sje at cup dot hp dot com 2009-01-27 23:45 ---
Yes, your patch does fix my problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
--- Comment #13 from rob1weld at aol dot com 2009-01-27 23:47 ---
This post: http://gcc.gnu.org/ml/gcc/2008-12/msg00135.html says:
To get on the radar regressions have to be marked [4.4 Regression],
with the target milestone set to 4.4.0 ...
Changing "Summary" from / to:
[trunk regre
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 23:51 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01338.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
$ awk '/lto1.*unaligned access to/ {sub(/.*ip=/, ""); print}' testsuite/*/*.log
| sort -u | addr2line -e lto1
../../gcc/lto/lto.c:186
../../gcc/lto/lto.c:197
../../gcc/lto/lto.c:201
../../gcc/lto/lto.c:272
../../gcc/lto/lto.c:273
../../gcc/lto/lto.c:216
../../gcc/lto/lto.c:229
../../gcc/lto/lto.c:2
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-28 01:20 ---
data_ptr = (const uint32_t *) ((const char*) data + decl_offset);
num_decl_states = *data_ptr++;
So either decl_offset is unaligned. Are we storing this packed?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-01-28 01:41 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
[...@gnu-3 gcc]$ /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c
/exp
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-28 01:51 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01342.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #39 from rob1weld at aol dot com 2009-01-28 03:08 ---
H.J. Lu,
This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435#c25 ) requests
that Bug Report be modified "restore to P3 if it affects non-Ada testsuites
or any case where the compiler exports GCC_EXEC_PREFIX i
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-01-28 03:25 ---
Here are my thoughts on how to fix this. None of the presented options is
workable, IMHO.
The preferred end goal is to only have the compatibilty.cc and
compatibilty-ldbl.cc objects in the shared library, and not in
--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-28 03:38 ---
Subject: Bug 38941
Author: hjl
Date: Wed Jan 28 03:38:41 2009
New Revision: 143719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143719
Log:
2009-01-27 H.J. Lu
PR target/38941
* doc/extend.
--- Comment #11 from hjl dot tools at gmail dot com 2009-01-28 03:39
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFI
--- Comment #12 from rob1weld at aol dot com 2009-01-28 03:54 ---
On the Trunk using "-O2" or "-O3" can produce slower code.
I built gcc version 4.4.0 20090126 [trunk revision 143680] for
i386-redhat-linux
and was dismayed to find that libmudflaps had a few FAILs:
Results for 4.4.0 200
--- Comment #3 from pault at gcc dot gnu dot org 2009-01-28 06:21 ---
See http://gcc.gnu.org/ml/fortran/2009-01/msg00331.html
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from rob1weld at aol dot com 2009-01-28 06:23 ---
(In reply to comment #17)
> Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
> On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
>
> > > It's very clear to me by now that HOST_WIDE_INT should only depend on the
Consider:
char a[8][8];
char b[8];
void
foo (int i)
{
int j;
for (j = 0; j < 8; j++)
{
a[i][j] = 0;
b[j] = j;
}
}
I get:
$ ./cc1 -quiet -O2 -ftree-loop-distribution min.c
min.c: In function 'foo':
min.c:5: internal compiler error: in build2_stat, at tree.c:3298
Please su
--- Comment #10 from burnus at gcc dot gnu dot org 2009-01-28 07:11 ---
Someone (Toon?) mentioned a plan to make the GOMP backend infrastructure usable
for shared memory. I also found the following paper: "Prototyping the automatic
generation of MPI code from OpenMP programs in GCC" at
h
--- Comment #10 from uros at gcc dot gnu dot org 2009-01-28 07:58 ---
Subject: Bug 38988
Author: uros
Date: Wed Jan 28 07:58:07 2009
New Revision: 143720
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143720
Log:
PR target/38988
* config/i386/i386.md (set_rip_rex
101 - 155 of 155 matches
Mail list logo
