1a. If I type ./configure with no additional options and type make then
I get a default build of the toolchain.
2a. If I type ./configure with no additional options and type make
profiledbootstrap
then I get a profiled, default build of the c and ada portion toolchain.
(a bug report about that is
I'm building gcc 4.4.0 20090109 on i386-pc-solaris2.11 (OpenSolaris 2008.11)
using gcc version 4.4.0 20090104. I have configured using
--enable-coverage=noopt.
# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran
I downloaded a opengl source tutorial from
http://nehe.gamedev.net/data/lessons/linuxsdl/lesson40.tar.gz and compiled it
twice. The first time with the default Makefile as provided in the tarball. The
program then worked as described in the tutorial, a simulation of a string fell
down the ground
--- Comment #1 from rob1weld at aol dot com 2009-01-09 08:27 ---
Adding ../prev-i386-pc-solaris2.11/libgcc/libgcov.a to the link:
# (OLD)
# /usr/share/src/gcc_build/prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-
gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -DIN_GCC -g -O2
I use different options to compile and excute the same programs, most of the
results are the same, however, their are some are different, which are with the
same problem.
the same problem occurs in 4.1.2, 4.2.0, 4.2.1, 4.2.2., 4.2.3, 4.2.4, but the
others are right.
the test case is (automation
--- Comment #1 from yu19820428 at 163 dot com 2009-01-09 08:32 ---
and when all optimizations are on, the results are right. but when only
tree-loop-linear on, no matter the strict-aliasing is on or off, the result is
error when the index reached the upbound.
--
yu19820428 at 163
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-09 08:54 ---
fold_unary bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-09 09:04 ---
Created an attachment (id=17063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17063action=view)
gcc44-pr38771.patch
Fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38771
--- Comment #8 from schwab at suse dot de 2009-01-09 09:09 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from arthur dot loiret at gmail dot com 2009-01-09 09:15
---
I can reproduce it on Debian unstable. The problem is in Debian's fastjar on
ia64:
(cd classes; \
/usr/bin/fastjar cf ../tools.zip `find . -name .svn -prune -o -type f
-print`; \
cd ..)
using gcc-4.3 and 4.4, with -O1 -fschedule-insns, leads to an ICE. gcc-4.2
compiles the code fine:
Source/server/scsynth_main.cpp: In function 'int main(int, char**)':
Source/server/scsynth_main.cpp:364: error: unable to find a register to spill
in class 'SIREG'
--- Comment #1 from tim at klingt dot org 2009-01-09 09:28 ---
Created an attachment (id=17064)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17064action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38779
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-09 09:36 ---
Seems to work on x86_64-linux. The error message is different if the program
doesn't exist:
./xgcc -b nonexistent-target -B ./ -v
./xgcc: error trying to exec './nonexistent-target-gcc-4.4.0': execvp: No such
file or
--- Comment #8 from paolo dot carlini at oracle dot com 2009-01-09 09:41
---
As I said, I'm seeing the expected final size, that is 1002. Also, I don't
think your testcase is correct, you don't want do_always_no_conv to return
true, nothing takes care in your codecvt of packing of
I just tried to compile the following C++ code
with the GNU C++ compiler version 4.4 snapshot 20090102.
extern int f();
void
g()
{
f + 27; // should fail
}
The compiler said
bug50.cc: In function 'void g()':
bug50.cc:9: warning: pointer to a function used in arithmetic
Here is gcc
In the testsuite for C is the file gcc.c-torture/execute/pr38151.c
I just tried to compile this file with the GNU C compiler
version 4.4 snapshot 20090102 using valgrind.
The debug output was
==32071== Conditional jump or move depends on uninitialised value(s)
==32071==at 0x8A1544:
While building gcc 4.4.0 20090109 on OpenSolaris 2008.11 there is an error
during the build which does not terminate make. The error comes from
binutils 2.19's 'ld' program but make does not 'see' it and the build
continues.
# /usr/local/bin/ld -V
GNU ld (GNU Binutils) 2.19
Supported
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-01-09 09:55 ---
(In reply to comment #4)
Created an attachment (id=17052)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17052action=view) [edit]
Replace execvp with pex_one in process_command
Patch uses pex_one as per Ian
--- Comment #9 from paolo dot carlini at oracle dot com 2009-01-09 09:56
---
... and, by the way, exactly because your codecvt is broken - doesn't properly
convert each in-memory wchar_t to a single external char - you maintain to see
1 / 4 of the expected Forecast strings: actually
--- Comment #10 from radhika dot ganganna at oracle dot com 2009-01-09
10:09 ---
Hi,
I'm afraid if it's an issue with codecvt as such. The same code generates the
expected ouput on all other unix platforms except Linux.
The expected output is not 1002 bytes as suggested. Even if I
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-09 10:11 ---
Bug in do_jump_by_parts_zero_rtx.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2009-01-09 10:15
---
Sorry, but I don't think your codecvt can wrok in any meaningful way as-is.
Either you provide more information as to why - basing on the exact citations
from the Standard - it should work, or we are not
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-09 10:25 ---
Please preprocess the testcase. Whether a header was a system header or not is
recorded in # linenum directives in the preprocessed output.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, wrong-code
Priority|P3
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 10:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 10:34 ---
Try -fno-strict-aliasing -fno-strict-overflow. This is likely a program bug.
Hard to say without a testcase though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38777
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-09 10:38 ---
Also, if it is floating point using app on i?86, -msse2 -mfpmath=sse or
-ffloat-store.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38777
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-09 10:39 ---
I can't see the light with all these options, but a quick test with GCC 4.2.4
yields the same output with -O3 -ftree-loop-linear as with -O0. On
x86_64-linux
and x86_64-linux with -m32.
Turning random
The triplet (or quad) i386-pc-solaris2.11 is ambiguous.
Try a bit of Googling for i386-pc-solaris2.11 :
http://www.google.com/search?q=i386-pc-solaris2.11rls=com.microsoft:en-us:IE-SearchBoxie=UTF-8oe=UTF-8sourceid=ie7rlz=1I7HPIA
The first hit:
sang-suan gam - Results for 4.2.2 testsuite on
--- Comment #3 from dov dot grobgeld at gmail dot com 2009-01-09 10:46
---
The only flag that had any affect was the -ffloat-store option, which made the
problem disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38777
--- Comment #15 from markus dot schoepflin at comsoft dot de 2009-01-09
10:57 ---
Patch for current trunk has been posted as requested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-09 12:25 ---
Subject: Bug 38721
Author: rguenth
Date: Fri Jan 9 12:25:00 2009
New Revision: 143200
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143200
Log:
2009-01-09 Richard Guenther rguent...@suse.de
--- Comment #2 from zadeck at naturalbridge dot com 2009-01-09 12:41
---
i will have my best people work on it.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #9 from doko at ubuntu dot com 2009-01-09 13:32 ---
yes, fastjar is segfaulting for the test
fastjar -cf conftest.jar existing file
seen as well, when building with current 4.1 and 4.2 branches. a fastjar built
with 3.4.6 works ok.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-09 13:41 ---
Subject: Bug 38771
Author: jakub
Date: Fri Jan 9 13:41:08 2009
New Revision: 143202
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143202
Log:
PR middle-end/38771
* fold-const.c (fold_unary):
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-09 13:43 ---
Subject: Bug 38347
Author: jakub
Date: Fri Jan 9 13:43:14 2009
New Revision: 143204
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143204
Log:
PR middle-end/38347
* dojump.c
--- Comment #3 from yu19820428 at 163 dot com 2009-01-09 14:00 ---
the options is to turn off all other optimizations while only to turn on the
-ftree-loop-linear. the result is right when -O3, but not right when only
-ftree-loop-linear is on.
--
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-09 14:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-09 14:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from jakub at gcc dot gnu dot org 2009-01-09 14:30 ---
This is an obvious bug in fastjar-0.97:
ub4
unix2dostime (time_t *unix_time)
{
struct tm *ltime = localtime (unix_time);
int year = ltime-tm_year - 80;
...
}
int make_manifest(int jfd, const char *mf_name, int
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-09 14:45 ---
Subject: Bug 37877
Author: jakub
Date: Fri Jan 9 14:45:44 2009
New Revision: 143206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143206
Log:
PR c++/37877
* parser.c
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-09 14:46 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
I'm building gcc 4.4.0 20090109 on i386-pc-solaris2.11 (OpenSolaris 2008.11).
I configured using --enable-coverage=noopt (and complained here that it
breaks
the build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38776 ) and made by
simply typing gmake.
First there is a stage with -fprofile-arcs
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-09 15:37 ---
That is a too weird situation. For 4.2 anyway, which is nearly
out-of-maintainance.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
After merging ARCompact support into gcc 4.4.0 20081210, we noticed that
cycle count is up by 155% compared to gcc 4.2.1 for ARC700 on the eembc
bitmnp01
benchmark. There are long sequences of putting integer constants on the stack,
and shufflink stack locations / registers around in the inner
--- Comment #1 from rob1weld at aol dot com 2009-01-09 15:46 ---
I re-checked _which_ gcov was actually being ran it was Sun's. Fixed,
by 1 and 2 invalid (old gcov does not read new files).
The third Bug is valid still:
'gcov can't find xgcc.gcno and xgcc.gcda because they are being
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-09 15:55 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-01-09
16:28 ---
Jerry,
Your test program doesn't produce an error under ifort 10.1.015. I'll try
to pinpoint the exact failure this weekend. At the moment, the problem appears
to be in the code that reads the
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-01-09 16:39 ---
(In reply to comment #1)
Testcase?
Unfortunately, the EEMBC benchmarks are not freely redistributable.
See http://www.eembc.org .
I'm not sure yet which parts of the benchmark are intrinsic to the problem
and
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-09 16:47 ---
Subject: Bug 35742
Author: jakub
Date: Fri Jan 9 16:46:47 2009
New Revision: 143209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143209
Log:
PR c/35742
* c-pretty-print.c (pp_c_expression):
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-09 16:52 ---
Subject: Bug 35335
Author: jakub
Date: Fri Jan 9 16:51:55 2009
New Revision: 143210
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143210
Log:
PR c++/35335
* error.c (dump_expr): Handle
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-09 16:53 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-09 16:53 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Compiling with -O2 -fgraphite-identity -floop-block the program below,
cc1 fails with:
image.c:11: error: definition in block 10 does not dominate use in block 28
for SSA_NAME: D.1621_16 in statement:
# VUSE SMT.13_53(D)
D.1713_120 = *D.1621_16;
image.c:11: internal compiler error: verify_ssa
--- Comment #12 from sebor at roguewave dot com 2009-01-09 16:57 ---
(In reply to comment #3)
Created an attachment (id=17044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17044action=view) [edit]
As others have mentioned, the codecvt facet in your test case is broken.
The
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-09 16:58 ---
This test also fails with only -O2 -fgraphite-identity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38786
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-09 17:13 ---
Subject: Bug 38686
Author: jakub
Date: Fri Jan 9 17:12:40 2009
New Revision: 143211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143211
Log:
PR target/38686
PR target/38708
*
--- Comment #12 from jakub at gcc dot gnu dot org 2009-01-09 17:13 ---
Subject: Bug 38708
Author: jakub
Date: Fri Jan 9 17:12:40 2009
New Revision: 143211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143211
Log:
PR target/38686
PR target/38708
*
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-09 17:13 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
This report is similiar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30976 ,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29493
Problem is that the bogus rep ret is still being generated, but it is
accepted by assembler now.
As shown in
--- Comment #3 from amylaar at gcc dot gnu dot org 2009-01-09 17:34 ---
(In reply to comment #1)
Testcase?
Ok, I now have a testcase that is almost, but not quite, entirely unlike
fbital. About the only characteristic it shares with fbital is that it has
a loop which provides
version 4.4.0 20090109 (experimental) (GCC)
My guess is that ./configure is getting fed shared, -shared
or --with-shared somehow. Investigating.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38776
--- Comment #7 from vmakarov at gcc dot gnu dot org 2009-01-09 17:52
---
Subject: Bug 38495
Author: vmakarov
Date: Fri Jan 9 17:52:03 2009
New Revision: 143214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143214
Log:
2008-01-09 Vladimir Makarov vmaka...@redhat.com
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-09 17:56 ---
rep ret isn't bogus, please see
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02117.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38787
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-09 17:57 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00463.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
GCC host triplet|x86_64-suse-linux |
GCC target triplet||x86_64-*-linux-gnu
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-09 17:58 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-09 17:59 ---
It's indeed partial-PRE that performs these insertions. Steven has some
patches
to tune down regular insertion that may also apply to partial insertion.
See also PR38401.
--
rguenth at gcc dot gnu dot org
--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com 2009-01-09
18:00 ---
Created an attachment (id=17065)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17065action=view)
Second part of the combined patch
Additional check to avoid returning a NULL base. This is a
--- Comment #2 from zsojka at seznam dot cz 2009-01-09 18:21 ---
(In reply to comment #1)
rep ret isn't bogus, please see
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02117.html
Thank you, I didn't know (or forgot) AMD recommends this. Hopefully the rep
retn opcode won't have any
--- Comment #4 from dodji at gcc dot gnu dot org 2009-01-09 19:10 ---
Created an attachment (id=17066)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17066action=view)
A better patch
I believe this patch should be better that the previous one because it seems to
be more generic. I
--- Comment #4 from pluto at agmk dot net 2009-01-09 19:39 ---
as mentioned, gcc is correct.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-01-09 19:40 ---
Any chance I could get a generated c++config.h from a native HPUX 10.x build as
well?
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pluto at agmk dot net 2009-01-09 19:52 ---
Created an attachment (id=17067)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17067action=view)
preprocessed testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-09 20:09 ---
The gcov data is based on the source name and not the executable now. So this
is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 20:10 ---
This is a bug in either config.guess or uname so this is not a GCC issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 20:11 ---
This is a bug in binutils and not in GCC. See
http://sourceware.org/ml/binutils/2008-09/msg00124.html .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-09 20:21 ---
This is not really a regression, -fschedule-insns never really worked correctly
for x86.
*** This bug has been marked as a duplicate of 38403 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-09 20:21 ---
*** Bug 38779 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-09 20:22 ---
Confirmed. Also note -fschedule-insns is basically broken for x86 anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 20:24 ---
pedwarn (input_location, pedantic ? OPT_pedantic : OPT_Wpointer_arith,
pointer to a function used in arithmetic);
So what happened is that -pedantic-errors is off by default in 4.4. You can
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-09 20:25 ---
Just remove the const from the function definition and the warning will go
away. The warning is correct as the const here is applying to the pointer
type.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 20:25 ---
Confirmed, I noticed this also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On Wed, Jan 7, 2009 at 11:25 AM, Juan Linietsky redu...@gmail.com wrote:
This code doesn't compile. It complains that A::_say is protected when
in reality it's being used from B. calling A::_say works fine, but
obtaining the address fails compilation.
This is not a bug since A::_say is
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-01-09 20:27
---
*** Bug 38762 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 20:27 ---
*** This bug has been marked as a duplicate of 16635 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-09 20:30 ---
The pic library is not used while compiling gcc so this warning is ok and not a
bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-09 20:41 ---
Then this is most likely a dup of bug 323 which will be fixed for 4.5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38776
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-09 20:55 ---
Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see [1].
An extension to this patch that we tested on x86 machines, is to disable PRE
for scalar integer registers, via SMALL_REGISTER_CLASSES.
I'm building gcc 4.4.0 20090109 on i386-pc-solaris2.11 (OpenSolaris 2008.11)
using gcc version 4.4.0 20090104. I added --enable-intermodule to my list
of configure options and
# prev-gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38765
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 21:11 ---
--enable-intermodule is not well tested at all. And second --combine is way
broken and really should be removed along with --enable-intermodule.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from rob1weld at aol dot com 2009-01-09 21:23 ---
Perhaps if the -combine command for gcc had a complementary -split=
command that would attempt to make optimal splits of the tree at split
sized chunks.
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-09 21:28 ---
You told the compiler to compile everything at the same time what do you expect
to cause out of memory issues?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gcc (GCC) 4.4.0 20090109 (experimental) [trunk revision 143212]
On x86_64-unknown-linux-gnu (FC9)
Configured as: ../trunk/configure --prefix=/home/ddaney/gccsvn/native-install
--disable-multilib --enable-languages=c
Consider the following program:
---foo.c8
void bar(int
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-09 21:45 ---
Jump threading in VPR is causing this and not really fully VPR.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rob1weld at aol dot com 2009-01-09 21:49 ---
After the build breaks typing gmake simply restarts from the _begining_!
# gmake
...
gmake[2]: Entering directory `/usr/share/src/gcc_build'
Configuring stage feedback in ./intl
...
and all is well (for a few hours,
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-09 21:51 ---
I wouldn't consider this a bug. It's similar to
inline void foo(int i) { if (__builtin_constant_p (i)) you_loose(); }
void bar()
{
foo (1);
foo (2);
}
where the code is duplicated twice and both cases are
1 - 100 of 118 matches
Mail list logo
