Hello,
I have a fortran program compiled with the gfortran compiler (gfortran -v =>
gcc version 4.1.2) and build with the gcc compiler.
The program directly crashed with a floating point exception and gives the
message "Fortran runtime warning: IEEE 'denormal number' exception not
supported" wit
--- Comment #2 from pluto at agmk dot net 2009-01-12 09:02 ---
btw. this bug doesn't occur on x86-64. buggy vrp/array-checking?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38808
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-12 09:13 ---
For one, 4.1.2 is slightly outdated by now, try updating to 4.3.x (or
trunk/4.4.0 if you want to use the latest development sources). Depending on
your platform, you might want to try the binaries available from the
> g++ -c -O2 -m32 -fPIC -save-temps foo.cpp
foo.cpp: In member function virtual long int
AbcAbcdTracer::TestIsoAbcde(AbcZyParamType, double, int&):
foo.cpp:19864: internal compiler error: in compensate_edge, at reg-stack.c:2754
---
> uname -a
Linux yoda.intec.dom 2.6.18-92.1.22.el5 #1 SMP Tue De
--- Comment #1 from mario-baumann at web dot de 2009-01-12 09:34 ---
Created an attachment (id=17074)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17074&action=view)
bzipped foo.ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-12 09:42 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #6 from markus dot schoepflin at comsoft dot de 2009-01-12
09:53 ---
The problem is still there as of 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-12 09:57 ---
Confirmed. The following fails with -O2 -m32:
typedef unsigned long ULONG;
void iwos_ErrorMessage(long error, const char * const file_name,
ULONG line_num, const char * const message);
class
--- Comment #13 from radhika dot ganganna at oracle dot com 2009-01-12
10:48 ---
Hi,
Even if I avoid using our implementation of codecvt, i still get the same
output of missing data.
Regards,
Radhika
--
radhika dot ganganna at oracle dot com changed:
What|Removed
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-12 11:11 ---
Subject: Bug 38807
Author: jakub
Date: Mon Jan 12 11:11:40 2009
New Revision: 143289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143289
Log:
PR tree-optimization/38807
* tree-ssa-reassoc.c (
--- Comment #14 from paolo dot carlini at oracle dot com 2009-01-12 11:11
---
Then, post your new (correct, I hope) codecvt
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-12 11:14 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pkeller at globalphasing dot com 2009-01-12 11:30
---
Created an attachment (id=17075)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17075&action=view)
Output from gcj -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812
--- Comment #2 from pkeller at globalphasing dot com 2009-01-12 11:31
---
Created an attachment (id=17076)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17076&action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812
--- Comment #7 from markus dot schoepflin at comsoft dot de 2009-01-12
11:36 ---
gcc -v gives:
~/local/src/tests/gcc/4605> /opt/gcc-4.3.2/bin/gcc -v -c hello.c -o 'dir
test/hello.o'
Using built-in specs.
Target: alphaev56-dec-osf5.1b
Configured with: /net/homes/schoepf/local/src/gcc-4.
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-12 11:41 ---
Introduced by PR27102 patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #8 from markus dot schoepflin at comsoft dot de 2009-01-12
11:43 ---
I think the problem is with 'as':
~/local/src/tests/gcc/4605> ls -1
dir test
hello.c
~/local/src/tests/gcc/4605> as -g -oldas -c -nocpp -O0 -o 'dir test/hello.o'
/tmp//ccTogmGX.s
~/local/src/tests/gcc/4605
On OS X 10.5 (Leopard), compile/link HelloWorld:
class HelloWorld {
static public void main( String args[] ) {
System.out.println( "Hello World!" );
}
}
as follows:
gcj --main=HelloWorld HelloWorld.java
Then strip and run a.out:
strip a.out
./a.out
dyld: Symbol not
--- Comment #4 from rob1weld at aol dot com 2009-01-12 12:47 ---
(In reply to comment #3)
> With 1400M (and 512M swap) it dies here:
>...
> -g -O2 -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF
> classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5392e4c270d4f3c7
The following program segfaults and valgrind shows:
==31102== Invalid read of size 4
==31102==at 0x4B3E31: gfc_conv_function_call (trans-expr.c:2451)
==31102==by 0x4B448A: gfc_conv_function_exp
--- Comment #9 from ubizjak at gmail dot com 2009-01-12 13:27 ---
Options should be wrapped in quotes, like:
COLLECT_GCC_OPTIONS='-O2' '-mtune=generic'
"/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1" "-quiet" "dir
test/hello.c" "-quiet" "-dumpbase" "hello.c" "-mtune=generic"
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-12 13:34 ---
> I think NAG f95 is right by rejecting it with:
> Error: line 9: The argument to C_LOC must not be an array pointer
Or maybe not: "15.1.2.5 C_LOC(X)" has for the result value:
"(2) If X is an array data entity, t
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-12 13:54 ---
I can't seem to compile the preprocessed source:
In file included from ./sys-headers/boost/mpl/int.hpp:21,
from
./sys-headers/boost/type_traits/detail/template_arity_spec
.hpp:11,
f
--- Comment #10 from ubizjak at gmail dot com 2009-01-12 13:57 ---
(In reply to comment #9)
> Options should be wrapped in quotes, like:
>
> COLLECT_GCC_OPTIONS='-O2' '-mtune=generic'
> "/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1" "-quiet" "dir
> test/hello.c" "-quiet" "-d
--- Comment #3 from rob1weld at aol dot com 2009-01-12 13:58 ---
I built gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] on
i386-pc-solaris2.11 (OpenSolaris 2008.11) and while I do have libssp I do NOT
have any Testsuite. Will those patches in the thread
http://gcc.gnu.
--- Comment #3 from rob1weld at aol dot com 2009-01-12 14:09 ---
(In reply to comment #2)
> The gcov data is based on the source name and not the executable now. So this
> is invalid.
That is what I am saying. There should be an exclusion for that one file only.
Rob
--
rob1weld at
--- Comment #11 from markus dot schoepflin at comsoft dot de 2009-01-12
14:17 ---
Here is the result of using -### instead of -v:
scho...@area51:~/local/src/tests/gcc/4605> /opt/gcc-4.3.2/bin/gcc -### -c
hello.c -o 'dir test/hello.o'Using built-in specs.
Target: alphaev56-dec-osf5.1b
C
--- Comment #1 from joel at gcc dot gnu dot org 2009-01-12 14:20 ---
Is this still happening? I accidentally did not commit the change to
lib/target-supports.exp and did it over the weekend (Saturday?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
--- Comment #2 from joel at gcc dot gnu dot org 2009-01-12 14:23 ---
It is not appearing here:
(powerpc-aix) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01087.html or
(powerpc-darwin) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01077.html
so it is fixed. Sorry for missed com
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-12 14:25
---
This isn't really a warning from system headers:
test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
rules
the location for the dereference is in test.cpp (if that is correct or not
is
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-12 14:30 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #13 from pluto at agmk dot net 2009-01-12 14:43 ---
(In reply to comment #12)
> This isn't really a warning from system headers:
>
> test.cpp:14: warning: dereferencing pointer '__x.13' does break
> strict-aliasing
> rules
>
> the location for the dereference is in test.cp
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-12 14:51
---
Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the
declaration are not from system-headers (this is then the default for -Wall)
and with -Wstrict-aliasing=2 (or =1) warn if either of the
--- Comment #12 from ubizjak at gmail dot com 2009-01-12 14:59 ---
Hm, on i686-pc-linux-gnu -v gives:
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic'
/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -quiet -v dir
test/hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello
--- Comment #6 from pluto at agmk dot net 2009-01-12 15:01 ---
Created an attachment (id=17077)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17077&action=view)
full testcase (src + .ii + mkefile)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
--- Comment #8 from carlos at systemhalted dot org 2009-01-12 15:02 ---
Dave,
I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
hppa because of bugs in DBR. I never filed a bug because it was almost
impossible for me to reduce the vfprintf code (large file,
--- Comment #4 from ubizjak at gmail dot com 2009-01-12 15:06 ---
-fno-ira fixes the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 ---
(In reply to comment #5)
> I can't seem to compile the preprocessed source:
i've attached a new full archive.
$ make
rm -f *.ii *.o *.s
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2
-g0 -fP
--- Comment #8 from rguenther at suse dot de 2009-01-12 15:16 ---
Subject: Re: [4.4 regression] warnings from -isystem
headers strikes back.
On Mon, 12 Jan 2009, pluto at agmk dot net wrote:
>
>
> --- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 ---
> (In reply t
--- Comment #6 from tomby at gcc dot gnu dot org 2009-01-12 15:37 ---
Subject: Bug 38385
Author: tomby
Date: Mon Jan 12 15:37:09 2009
New Revision: 143291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143291
Log:
PR middlend/38385
* tree-loop-distribution.c (pro
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-12 15:43 ---
Subject: Bug 38794
Author: jakub
Date: Mon Jan 12 15:43:22 2009
New Revision: 143292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143292
Log:
PR c++/38794
* decl.c (start_function): If grokde
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 15:45 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #21 from jakub at gcc dot gnu dot org 2009-01-12 16:18 ---
Created an attachment (id=17078)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17078&action=view)
gcc44-pr38245.patch
Patch I'm playing with. I don't see why changing CALL_INSN_FUNCTION_USAGE
to have only at m
--- Comment #20 from pault at gcc dot gnu dot org 2009-01-12 16:20 ---
Created an attachment (id=17079)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17079&action=view)
A preliminary patch for the PR
A slightly earlier version of this regtested OK. Will do it to this version
toni
version used for testing:
GNU Fortran (GCC) version 4.4.0 20090112 (experimental) [trunk revision 143288]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090112 (experimental) [trunk revision
143288], GMP version 4.2.2, MPFR version 2.3.1.
valgrind --tool=memcheck
/data03
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:39 ---
For quick reading, skip next part and continue below the * * *.
---
I think this applies still (at least partially) as libgfortran/config/fpu*.h's
set_cpu() still has the line. For GLIBC one finds:
/* gli
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:59 ---
For the diagnostics: I think it works, but we are checking in case of
C_LOC(Type%Comp) the symbol Type instead of Comp. Assume that Type is a
pointer and Comp is not then "gfc_is_data_pointer()" returns true for Type
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-12 17:27 ---
Is this an IRA bug?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #24 from aph at gcc dot gnu dot org 2009-01-12 17:36 ---
Subject: Bug 38396
Author: aph
Date: Mon Jan 12 17:35:48 2009
New Revision: 143301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143301
Log:
2009-01-12 Andrew Haley
PR libgcj/38396:
* libgc
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-12 17:39 ---
things really have a random flavor right now. I have a bt for a segfault from
gdb, within a couple of minutes now:
[ repeats about 4000 times]
#4011 0x0049267d in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fort
--
Summary: Taking the address of a __thread variable prevents the
r0 register from being loaded
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-12
18:01 ---
Subject: Re: [4.4 Regression] Incorrect delayed branch optimization
> I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
> hppa because of bugs in DBR. I never filed a bug becau
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-12
18:03 ---
The following code:
__thread long tl = 42;
long f(void)
{
long *l = &tl;
register long r0 __asm__ ("r0");
register long *r1 __asm__ ("r1");
r0 = 23;
r1 = l;
--- Comment #18 from amylaar at gcc dot gnu dot org 2009-01-12 18:09
---
(In reply to comment #17)
> I think enabling partial PRE to do it is appropriate (with at most inserting
> on one edge).
I think the abstraction with tree-ssa and cfglayout mode has gone too far.
We no longer have
The following code seems to be wrongly optimized by GCC:
int main(int argc, char **argv) {
unsigned int foo = 3;
return ((838237499u * foo - 2137600414u) % 11u);
}
always return 0 on my machine, it should return 7. GCC seems to be optimizing
the modulo operation (even with -O0).
GCC versio
+++ This bug was initially created as a clone of Bug #38465 +++
For 4.4, "info -f /usr/local/info/gccint.info -n Passes" needs to document
the 'Graphite Pass' in the "Passes" section. At minimum a link to a Doc.
--
Summary: [4.4 Regression] graphite undocumented
Product: g
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-12 19:29 ---
(In reply to comment #3)
> That is what I am saying. There should be an exclusion for that one file only.
Why? this is what should be done and how this has been implemented for a long
time.
-fprofile-arcs does n
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 19:44 ---
Subject: Bug 32041
Author: jakub
Date: Mon Jan 12 19:44:33 2009
New Revision: 143305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143305
Log:
PR c/32041
* c-parser.c (c_parser_postfix_express
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-12 19:45 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #13 from markus dot schoepflin at comsoft dot de 2009-01-12
19:51 ---
Strange, I seem to get something different on Linux with gcc 4.3.2:
~/src/tests/gcc/PR4605$ gcc -v -c hello.c -o "./dir test/hello.o"
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/c
--- Comment #14 from markus dot schoepflin at comsoft dot de 2009-01-12
20:01 ---
Just to recap what I think the problem is:
1) cc1 compiles the C file and creates input for the system assembler. The
assembler source is placed into the /tmp directory.
2) The system assembler is called
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-12 20:28 ---
Well for -m32/-m64 case, it might be difference in 32bit vs 64bit conversions
:).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38808
--- Comment #5 from aesok at gcc dot gnu dot org 2009-01-12 20:42 ---
Subject: Bug 29141
Author: aesok
Date: Mon Jan 12 20:41:57 2009
New Revision: 143306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143306
Log:
PR target/29141
* config/avr/t-avr (LIB1ASMFUNCS)
The following program seems to show a
compiler bug on x86 using 4.3.2 compilers
The correct output should be;
giChannelTiming0.Setup 0xff
giChannelTiming0.Recover 0xff00
which occurs only when no optimiser or -O is used.
When -O2 or greater is used the mask's are incorrectly
computed an
The following test wrongly fails with a floating point exception (division
by integer 0) when built with -O2 for i686-pc-linux-gnu. Based on an
example posted by Robert Seacord to the WG14 reflector. It works with 3.4 and
earlier, fails with 4.0 and later. The % operation may trap if it is % 0
(
--- Comment #16 from bkoz at gcc dot gnu dot org 2009-01-12 20:57 ---
Created an attachment (id=17080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17080&action=view)
for gcc-4_3-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
--- Comment #13 from jason at gcc dot gnu dot org 2009-01-12 21:07 ---
Subject: Bug 31488
Author: jason
Date: Mon Jan 12 21:07:46 2009
New Revision: 143308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143308
Log:
PR c++/31488
* tree.c (pod_type_p): Return 1 for
--- Comment #17 from bkoz at gcc dot gnu dot org 2009-01-12 21:32 ---
Subject: Bug 36801
Author: bkoz
Date: Mon Jan 12 21:32:19 2009
New Revision: 143310
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143310
Log:
2009-01-12 Benjamin Kosnik
Jonathan Larmour
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 21:36 ---
fixed for 4.4.x/4.3.x
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-12 21:37 ---
Subject: Bug 38515
Author: spop
Date: Mon Jan 12 21:36:58 2009
New Revision: 143311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143311
Log:
2009-01-12 Sebastian Pop
PR tree-optimization/38515
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:37 ---
*(unsigned long *)this=l;
You are violating C/C++ aliasing rules which invokes undefined behavior as you
are accessing a giChannelTiming as a unsigned long.
Either use -fno-strict-aliasing or memcpy or unions or th
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-12 21:38 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:56 ---
This was fixed for 4.3.3 by the patch for PR 36548.
*** This bug has been marked as a duplicate of 36548 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-12 21:56
---
*** Bug 38817 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from vmakarov at redhat dot com 2009-01-12 22:12 ---
Yes, it is an IRA bug. Code processing calls to functions can throw is
lost in IRA.
I'll submit a patch tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #2 from john dot spelis at 3dlabs dot com 2009-01-12 22:16
---
Subject: Re: C++ bitfield static initialisation problem
Thank you.
(I'm suitably humbled).
Cheers
On 12 Jan 2009, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #1 from pinskia at gcc dot gnu
--- Comment #2 from jlerouge at apple dot com 2009-01-12 22:22 ---
Verified fixed with 4.3.3.
--
jlerouge at apple dot com changed:
What|Removed |Added
Status
--- Comment #5 from dodji at gcc dot gnu dot org 2009-01-12 22:41 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:41:19 2009
New Revision: 143313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143313
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #6 from dodji at gcc dot gnu dot org 2009-01-12 22:44 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:44:13 2009
New Revision: 143314
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143314
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #7 from dodji at gcc dot gnu dot org 2009-01-12 22:48 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:47:49 2009
New Revision: 143315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143315
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-12 22:50 ---
Fixed in trunk, gcc-4_3 and gcc-4_2.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-12 23:00 ---
The 4.3 version seems to be the old one, with is_* prefixes and macro, while
trunk/4.2 are the new ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
--- Comment #2 from rob1weld at aol dot com 2009-01-12 23:35 ---
(In reply to comment #0)
> With --enable-languages=c,fortran, system trys to build gnattools and fails
> with this error:
> ...
> Cannot build gnattools while gnatlib is out of date or unbuilt
> ...
That may occur if you u
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38810
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 23:59 ---
Thanks for your help Dave: this should be fixed now. (FWIW, the 10.20 config is
correct, or mostly correct.) Still, it's nice to confirm.
Ranier, this should be working now. Can you try to cross-compile as before, bu
--- Comment #3 from rob1weld at aol dot com 2009-01-13 00:14 ---
In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have
the: "Cannot build gnattools while gnatlib is out of date or unbuilt" Bug.
# gmake clean-gcc
...
# gmake
...
gmake[4]: Leaving directory
`/usr/s
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:18 ---
>"Cannot build gnattools while gnatlib is out of date or unbuilt".
That bug is a different issue than this bug. Please don't confuse the two.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|i386-pc-solaris2.11 |
GCC h
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 ---
*** This bug has been marked as a duplicate of 33443 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 ---
*** Bug 38746 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-13 00:28 ---
Well you don't understand any of these options it seems.
First --enable-coverage=nopt does nothing except changes the CFLAGS really.
There is nothing in the toplevel makefile or configure which uses
--enable-coverag
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-13 00:31 ---
Nobody builds using --enable-intermodule, it uses too much memory in general
anyways so closing as won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:32 ---
You should not be bootstrapping a --enable-coverage=noopt build, you should
only need to build stage1 gcc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 ---
fixincludes is already registered as PR 25470.
And really PR 3415 is the original bug for it.
*** This bug has been marked as a duplicate of 3415 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 ---
*** Bug 38800 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 00:38 ---
Coverage builds should not be bootstrapped.
Profiled bootstrap means build stage1 with no opts and then stage2 with
generating the profiling data and then build some target libraries (not all
though) and the build s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||bug-classpath at gnu dot org
Severity|major
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:42 ---
a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is needed
for libgcc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 ---
Hmm, automake should have done the correct thing ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 ---
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs are.
if test $cross_compiling = no && test $multilib = yes \
&& test "x${with_multisubdir}" != x ; then
cr
1 - 100 of 126 matches
Mail list logo
