And why would you think (twice) that the best place for reporting this
is neither the gfortran mailing-list, nor bugzilla?
I suggest that you test the following patch and report back to us:
Index: libgfortran/runtime/error.c
===
Paolo Bonzini wrote:
a) if anyone propagates a value anywhere, she should check whether the
propagated value is part of a comparison in a COND_EXPR (and
explicitly fold the comparison, if so).
b) in case of a COND_EXPR, fold_ternary (...) in fold-const.c folds
the comparison before doing
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
odcctools 590-20060413 using a modified Fink script (working
with the previous snapshot) failed with:
...
Since the problem is still there in
Now I get:
some cleaning
make[1]: *** No rule to make target `clean'. Stop.
make: *** [clean-stage4-gcc] Error 2
It turns out I had a fix already approved, but never checked in. Fixed
(and my apologies).
Paolo
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with
On Thu, 9 Nov 2006, [EMAIL PROTECTED] wrote:
Author: echristo
Date: Thu Nov 9 23:56:57 2006
New Revision: 118633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118633
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR bootstrap/26892
PR bootstrap/27814
Geert Bosch wrote:
Given that CPU usage is at 100% now for most jobs, such as
bootstrapping GCC, there is not much room for any improvement
through threading.
Geert, I find this a bit incomprehensible, the whole point
of threading is to increase CPU availability by using
multiple cores.
I suggest that you test the following patch and report back to us:
I got the patch wrong (it's not a real printf function we have there):
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c (revision 118806)
+++
Thanks a lot. This is going to be a good starting point.
Ferad Zyulkyarov
On 11/13/06, Sebastian Pop [EMAIL PROTECTED] wrote:
On 11/13/06, Ferad Zyulkyarov [EMAIL PROTECTED] wrote:
Hi,
May you point me out some sources about writing new #pragma directives
in GCC. I looked at the internet
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
David
Compiling with --disable-bootstrap and using the resulting compiler to
bootstrap gcc solved the problem.
Rafael
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
Most people aren't waiting for compilation of single files.
If they do, it is because a single compilation unit requires
parsing/compilation of too many unchanging files, in which case
the primary concern is avoiding redoing useless compilation.
Snapshot gcc-4.2-20061114 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Nov 14, 2006, at 12:49, Bill Wendling wrote:
I'll mention a case where compilation was wickedly slow even
when using -j#. At The MathWorks, the system could take 45 minutes
to compile. (This was partially due to the fact that the files were
located on an NFS mounted drive. But also because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy
i'm trying to build gcc-4.1.1 (of release status) on my x86/Linux (it
is an RH 9.0).
I have tried the following two setups:
a) gcc-3.2.2 (as RH 9.0 is shipped with), glibc-2.3.2 (the same)
b) gcc-3.4.3 (custom built), glibc as above.
It
Dave Korn [EMAIL PROTECTED] writes:
The main place where threading may make sense, especially
with LTO, is the linker. This is a longer lived task, and
is the last step of compilation, where no other parellel
processes are active. Moreover, linking tends to be I/O
intensive, so a number
David Edelsohn wrote:
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
On 14 November 2006 18:30, Ian Lance Taylor wrote:
Dave Korn [EMAIL PROTECTED] writes:
The main place where threading may make sense, especially
with LTO, is the linker. This is a longer lived task, and
is the last step of compilation, where no other parellel
processes are active.
On 14 November 2006 15:38, Robert Dewar wrote:
Geert Bosch wrote:
Given that CPU usage is at 100% now for most jobs, such as
bootstrapping GCC, there is not much room for any improvement
through threading.
Geert, I find this a bit incomprehensible, the whole point
of threading is to
Dave Korn [EMAIL PROTECTED] writes:
It's irrelevant to the main discussion here, but in fact there is a
fair amount of possible threading in the linker proper, quite apart
from LTO. The linker spends a lot of time reading large files, and
the I/O wait can be parallelized.
That's not
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6, I'll use that.
-eric
On Tue, Nov 14, 2006 at 07:15:19PM -, Dave Korn wrote:
Geert's followup explained this seeming anomaly: he means that the crude
high-level granularity of make -j is enough to keep all cpus busy at 100%,
and I'm fairly persuaded by the arguments that, at the moment, that's
sufficient in
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be
H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
It was a
On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote:
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6,
On Tue, 14 Nov 2006, Eric Christopher wrote:
Done, sorry about that.
Thanks. Hopefully we can get a planned transition done (for gcc and src)
before 4.3. (I suspect the first step will be the move of toplevel to
2.59; I'm not sure what's holding that up now all subdirectories of gcc
and
On 14/11/2006, at 3:13 AM, Dominique Dhumieres wrote:
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
odcctools 590-20060413 using a modified Fink script (working
with the previous snapshot) failed
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
No failure should be expected. It is a bug and a regression and
should be fixed, with
On Tue, Nov 14, 2006 at 08:05:59PM +, Joseph S. Myers wrote:
On Tue, 14 Nov 2006, Eric Christopher wrote:
Done, sorry about that.
Thanks. Hopefully we can get a planned transition done (for gcc and src)
before 4.3. (I suspect the first step will be the move of toplevel to
2.59;
On Nov 12, 2006, at 3:21 PM, Jack Howarth wrote:
Can anyone confirm that the libffi shared libraries are properly
built in gcc 4.2 branch (or trunk)
No, they aren't built:
The following languages will be built: c,c++,java
*** This configuration is not supported in the following
While trying to clean, I noticed that
$ make -k -j6 clean
does:
make[5]: *** [insn-recog.o] Interrupt
make[5]: *** [s-attrtab] Interrupt
make[4]: *** [all-stage1-gcc] Interrupt
make[3]: *** [stage1-bubble] Interrupt
Reaping losing child 0x00383f20 PID 18728
make[2]: *** [all] Interrupt
On Tue, Nov 14, 2006 at 12:03:39PM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
No failure should be expected.
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it says that there is no data dependence graph
implemented. Also had a search throught the mailing list archives and
noticed that although ddg.c exists its not used much?
On 14 November 2006 19:40, Joe Buck wrote:
On Tue, Nov 14, 2006 at 07:15:19PM -, Dave Korn wrote:
Geert's followup explained this seeming anomaly: he means that the crude
high-level granularity of make -j is enough to keep all cpus busy at
100%, and I'm fairly persuaded by the arguments
On 11/14/06, Sashan Govender [EMAIL PROTECTED] wrote:
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it says that there is no data dependence graph
implemented. Also had a search throught the mailing list archives and
On 11/15/06, Daniel Berlin [EMAIL PROTECTED] wrote:
On 11/14/06, Sashan Govender [EMAIL PROTECTED] wrote:
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it says that there is no data dependence graph
implemented.
On 11/15/06, Sashan Govender [EMAIL PROTECTED] wrote:
On 11/15/06, Daniel Berlin [EMAIL PROTECTED] wrote:
On 11/14/06, Sashan Govender [EMAIL PROTECTED] wrote:
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it
the fix for PR middle-end/28915 causes a bootstrap failure with 4.1 20061113 on
i486 (using the Debian build); didn't yet check with a vanilla 4.1 branch or
the fedora 4.1 branch.
Matthias
./xgcc -B./ -B/usr/i486-linux-gnu/bin/ -isystem /usr/i486-linux-gnu/include
-isystem
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-11-14
08:18 ---
reverting the fix for PR28915 fixes the bootstrap error
2006-11-12 Jason Merrill [EMAIL PROTECTED]
Andrew Pinski [EMAIL PROTECTED]
PR middle-end/28915
* gimplify.c (gimplify_init_constructor): Don't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 08:21 ---
(In reply to comment #1)
reverting the fix for PR28915 fixes the bootstrap error
This patch should not have any affect on bootstrap as there are no vectors
usage inside GCC.
--
--- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 ---
it is supported, it is just buggy. Jean-Pierre, it seems like you have
something like a patch. Can you expand your idea more?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 08:26 ---
building a plain 4.1 branch to prove it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44
---
Created an attachment (id=12618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12618action=view)
Patch mentionned in previous comment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-11-14 09:03
---
Yep, and the aforementioned patch is indeed the culprit.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from vahtras at kth dot se 2006-11-14 09:42 ---
Subject: Re: integer assignment in hexadecimal fails
On 14 nov 2006, at 02.23, jvdelisle at gcc dot gnu dot org wrote:
Try -fno-range-check or use standard conforming methods.
Thank you, this was a learning experience
--- Comment #13 from bonzini at gnu dot org 2006-11-14 08:46 ---
Subject: Bug 29798
Author: bonzini
Date: Tue Nov 14 08:46:26 2006
New Revision: 118808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118808
Log:
2006-11-14 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #14 from bonzini at gnu dot org 2006-11-14 08:50 ---
still have to commit the patch on dataflow branch, but mainline is ok now
--
bonzini at gnu dot org changed:
What|Removed |Added
the exact version of GCC is 4.1.1
the system type is i686-pc-cygwin
the options given when GCC was configured/built:
--prefix=/tmp/local/unixutil/gcc-4.1.1
--with-local-prefix=/usr/local/myCompanyName
(myCompanyName is not the exact wording)
(also, there is a symlink
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-14 09:46 ---
So the problem is that loop.c creates a tree for:
(plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0xb7ce10b0 dwarf_reg_size_table)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-14 09:06 ---
Looking into it, a bit more. But as far as I can tell this is a latent bug in
the x86 back-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2006-11-14 09:06 ---
Subject: Bug 29798
Author: bonzini
Date: Tue Nov 14 09:06:42 2006
New Revision: 118809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118809
Log:
2006-11-14 Paolo Bonzini [EMAIL PROTECTED]
Merge from
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-14 09:57 ---
(In reply to comment #8)
Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an
offset?
gas accepts that as valid so I think GCC should accept this. I am now going to
bed but I am also going to say this
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-14 09:50 ---
I'm confused that for
type geodetic
real :: h
end type geodetic
gfortran is using a record type but still goes the scalar assignment path.
With
gfc_trans_scalar_assign changed to read
gcc_assert
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote:
--- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29
---
This change breaks bootstrap on x86_64-linux and i386-linux:
This is now PR 29825 and it is an x86 back-end issue about not accepting
the
--- Comment #3 from poellmann at nm dot hsd dot utc dot com 2006-11-14
10:10 ---
The problem maintains with gcc 4.1.1. The error-message is slightly different:
test.c: In function 'compare':
test.c:5: error: unrecognizable insn:
(insn 12 11 13 1 (set (reg:CCFP 123)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 09:40 ---
This is a bug in loop.c ... which is why it works in 4.2.0 and above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29 ---
This change breaks bootstrap on x86_64-linux and i386-linux:
/usr/src/gcc-4.1/obj/./gcc/xgcc -B/usr/src/gcc-4.1/obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/
--- Comment #12 from jakub at gcc dot gnu dot org 2006-11-14 11:43 ---
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are invalid,
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:39
---
I'll take that one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Assigning a function pointer with a char parameter to a pointer with an
undefined list causes gcc to emit a warning.
[EMAIL PROTECTED]:~/ntnative/loader$ cat x.c
void foo(char);
void (*f1)() = foo;
void bar(int);
void (*f2)() = bar;
[EMAIL PROTECTED]:~/ntnative/loader$ gcc -c x.c
x.c:2: warning:
--- Comment #8 from pault at gcc dot gnu dot org 2006-11-14 10:19 ---
FX,
In spite of this morning's posting to the list, I will not be submitting a
patch for %LOC but rather for %REF. I got stuck in vms space. Is there any
functional difference between %LOC and %REF, do you know?
See:
13.7.76 MIN (A1, A2 [, A3, ...])
For arguments of character type, the result is the value that would be selected
by application of intrinsic relational operators; that is, the collating
sequence for characters with the kind type parameter of the arguments is
applied. If the selected argument
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:37
---
%VAL, %REF and %DESCR have similar use and functionality, but %LOC is very
different. It should in fact be an alias for function LOC, but it simply adding
it in intrinsic.c with make_alias is not sufficient:
--- Comment #3 from patchapp at dberlin dot org 2006-11-14 10:00 ---
Subject: Bug number PR29642
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/2006-11/msg00923.html
--
--- Comment #25 from pinskia at gmail dot com 2006-11-14 10:02 ---
Subject: Re: [4.1 regression] ICE: tree check:
expected class 'constant', have 'declaration' (var_decl) in
build_vector,
at tree.c:973
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org
--- Comment #10 from jakub at gcc dot gnu dot org 2006-11-14 10:45 ---
The problem is in the make_tree change of PR28915.
make_tree is called with (const (unspec (something) ) ), before make_tree
would just create a dummy VAR_DECL with DECL_RTL set to this, but now
calls make_tree
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-14 10:16 ---
A long overdue patch for this will be submitted in the next 24hours.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
while working in a project in C++. I tried to use a forward declaration of a
class. Class is unders some name space. There I got the error message like
below.
arm-linux-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for
--- Comment #3 from jpvial at nerim dot net 2006-11-14 11:10 ---
Subject: Re: wrong directory in makefile for ada and libada
when building the src directory
bonzini at gnu dot org wrote:
--- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 ---
it is supported, it is
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-11-14 11:11
---
The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with
the same error.
At least (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2af3f74a6580 dwarf_reg_size_table) is not a valid
--- Comment #1 from jakub at gcc dot gnu dot org 2006-11-14 14:27 ---
lambda_loopnest_to_gcc_loopnest interchanges the loops and we get:
L12:;
lletmp.77_46 = 0;
lletmp.77_38 = lletmp.77_46 + 5;
lnivtmp.75_21 = lnivtmp.75_9 + 1;
lnivtmp.75_12 = lnivtmp.75_9 + 1;
if
--- Comment #7 from burnus at gcc dot gnu dot org 2006-11-14 15:49 ---
Fixed in trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-11-14 12:23 ---
Created an attachment (id=12616)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view)
patch to fix the bug
Please try this.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from Denis dot Excoffier at airbus dot com 2006-11-14 11:39
---
To be connected to Bug 29825.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-14 11:48
---
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are
--- Comment #1 from pluto at agmk dot net 2006-11-14 12:53 ---
this is a dup of PR29767
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
Hi,
I haven't found any related bug in the known bugs database.
Also I posted this problem to several forums to be shore that this code doesn't
violate the C++ standard. ~60% replies that this should work. Moreover two
other compilers can compile without any problem:
The simplified code:
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-14 14:17 ---
Confirmed.
Tobias,
What criterion are you chosing for the missing F2003 features? The reason that
I ask is that it is not clear to me when you stop; eg. should we have a PR for
polymorphism or for sub-modules?
--- Comment #2 from zjasz at yahoo dot com 2006-11-14 15:02 ---
(In reply to comment #1)
this is a dup of PR29767
Sorry for duplication, I haven't checked again after I posted to the gcc-help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-14 15:54 ---
What does adding '-v' to the compile command say? It seems Ubuntu is using a
default -march that enables 3dnow (k8 or opteron maybe) - it should use x86_64
instead.
--
rguenth at gcc dot gnu dot org changed:
Have built gcc with --prefix=/usr/local/gcc-4.1.1.
When /usr/local/gcc-4.1.1 is moved and symlinked to /stranger/gcc-4.1.1,
the include path order changes, so that fixed system headers are searched
before local headers.
In non-symlink case, where the searched include path is correct, I can see
gfortran.fortran-torture/execute/scalarize.f90 is miscompiled at least
on x86_64-linux with -O2 -ftree-loop-linear (other miscompiled fortran
tests with -ftree-loop-linear are forall_1.f90 and der_type.f90).
The only linear transformed loop in scalarize.f90 is the
b(:, 5:1:-1) = a
one (i.e.
int8
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-14 16:29 ---
Please file a bug with Ubuntu instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
--- Comment #2 from jakub at gcc dot gnu dot org 2006-11-14 14:28 ---
Forgot to mention, the problem is reproduceable also on gcc-4_1-branch
and gcc-4_2-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Actual version string from gcc: 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5)
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-14 16:30
---
*** Bug 29830 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-14 16:34
---
(In reply to comment #13)
While that can help in this case, I think letting make_tree/expand_expr
combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs
--- Comment #6 from Raimund dot Merkert at baesystems dot com 2006-11-14
15:52 ---
It does not seem to warn about unused functions. I also tried the following
test case where 4.0.0 (solaris) does not warn even about foo ( I guess because
it's referenced in Y's constructor?)
gcc
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-14 15:35 ---
Subject: Bug 29657
Author: burnus
Date: Tue Nov 14 15:35:36 2006
New Revision: 118812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118812
Log:
fortran/
2006-11-14 Tobias Burnus [EMAIL PROTECTED]
--- Comment #5 from wolfgang dot roemer at gmx dot net 2006-11-14 15:35
---
[EMAIL PROTECTED] wrote:
Usually the problem will get caught as soon as you try to invoke a method, but
if it's something like a guard object, without methods, then it can be a
problem.
At least in this case
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-14 15:56 ---
For SUSE 4.1.2 I get prefetcht0 generated. So this is an Ubuntu bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tla at thrane dot com 2006-11-14 16:28 ---
(In reply to comment #4)
What's the status of this patch?
The bug is also present in arm-elf-gcc version 4.1.0
However, adding the -fno-omit-frame-pointer parameter, make
the compiler emit the correct code in the mentioned
--- Comment #4 from thaytan at noraisin dot net 2006-11-14 16:09 ---
It's using -mtune=generic:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib
More cases where g++ apparently doesn't take
enough context into account when deciding that
something can be (and thus is) a declaration.
Compiled the following (legal) program using g++ -c
---
struct Doh
{
Doh( int ) {}
} ;
int x = 0 ;
int
f()
{
Doh(
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44
---
What about:
de.f90:4:
use foo, only : bar
1
Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden
My limited german knowledge seems to indicate that it's OK, but I'm not sure.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 16:30 ---
*** This bug has been marked as a duplicate of 14032 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from Jean-pierre dot vial at wanadoo dot fr 2006-11-14
17:11 ---
(In reply to comment #0)
when building ada on linux (x86-64)
building ada fails because the makefile looks for gnatbuild in
mydir/gcc-4.2-20061107/prev-gcc
instead of
--- Comment #1 from thaytan at noraisin dot net 2006-11-14 14:26 ---
Created an attachment (id=12617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12617action=view)
simple test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
1 - 100 of 169 matches
Mail list logo
