Frank Ch. Eigler [EMAIL PROTECTED] wrote:
libmudflap needs to know the know the name of the entry point symbol,
to enable one of its heuristics. See the ENTRY_POINT area in
configure.ac, and update it for your own runtime. Be aware that
libmduflap's libc-wrapper functions may need porting for
On Jun 4, 2007, at 12:09 AM, Deepen Mantri wrote:
Frank Ch. Eigler [EMAIL PROTECTED] wrote:
libmudflap needs to know the know the name of the entry point symbol,
to enable one of its heuristics. See the ENTRY_POINT area in
configure.ac, and update it for your own runtime. Be aware that
Hi,
Now, i wanna generate a switch table just like ARM tbb instruction.
The switch table should be located at .rdata section, so I should use
.L3-.L8_1, but not .L3-.L8.
How could i implement this? Any target macro can do it?
Please look at the following code fragment. (.L3-.L8_1)/2 is what i
Thanks for the reply.
I did remove --enable-libmudflap option from the build script and
followed following steps for libmudflap configuration:
Why on earth would you do this?
I created a separate build folder and from there
a) [libmudflap source path]/configure --target=sh-elf
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
If I can reproduce it I'll see if I can find some webspace.
If you mail me a SSH public key you can also put it on
git.infradead.org.
--
dwmw2
David Woodhouse wrote:
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
If I can reproduce it I'll see if I can find some webspace.
If you mail me a SSH public key you can also put it on
git.infradead.org.
Come visit git.infradead.org and its GCC development fork.
--
// Bernardo
I will greatly appreciate any suggestions regarding the following
problem I have with the ccp propagator. I am testing the new store
ccp patch which propagates constants by walking the virtual use-def
chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
encountered the
Eric Christopher wrote:
No, at the toplevel (just like your normal build of the compiler and
target libraries):
configure --enable-languages=c --disable-multilib --enable-libmudflap
--target=sh-elf ; make -j8 all-gcc all-target
and you'll get this:
configure: error: none of the known symbol
Hi -
which means that libmudflap needs to be ported to sh-elf.
How should I start the porting? Do you have any document related to such
porting? [...]
First thing is to get past that autoconf error. Check your linker
script for the default entry point symbol's name, and give it to
phew, a few of the cygwin failures show up like this:
Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
(timeout = 300)
spawn
On Mon, 2007-06-04 05:17:17 -0400, Bernardo Innocenti [EMAIL PROTECTED] wrote:
David Woodhouse wrote:
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
If I can reproduce it I'll see if I can find some webspace.
If you mail me a SSH public key you can also put it on
On 6/1/07 3:45 PM, Seema S. Ravandale wrote:
int b; //local variable
array[b] = c
will be translated to
b.0 = b;
array[b.0] = c
anything to do with SSA?
Is 'b' an addressable variable or is it a regular local stack variable?
If the latter, then this is a buglet in the conversion to
On 6/4/07, Revital1 Eres [EMAIL PROTECTED] wrote:
I will greatly appreciate any suggestions regarding the following
problem I have with the ccp propagator. I am testing the new store
ccp patch which propagates constants by walking the virtual use-def
chain
-Original Message-
From: Timothy C Prince [EMAIL PROTECTED]
To: gcc@gcc.gnu.org
Date: Mon, 04 Jun 2007 16:20:34 +
In the message
http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html
Dave Korn wrote:
So, am I correct to believe that we need to use plain 'inline' for c99 after
gcc
On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
On Sun, 3 Jun 2007, Ben Elliston wrote:
Are they mentioned in any gcc changes.html?
No, they're not. They probably should be.
Do you think we could talk the submitters/maintainers into donating a
patch? :-)
Support for the
On Mon, Jun 04, 2007 at 01:23:16PM -0700, Janis Johnson wrote:
On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
On Sun, 3 Jun 2007, Ben Elliston wrote:
Are they mentioned in any gcc changes.html?
No, they're not. They probably should be.
Do you think we could talk the
Snapshot gcc-4.1-20070604 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
-Original Message-
From: Mark Mitchell [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 9:05 AM
To: Joseph S. Myers
Cc: Fu, Chao-Ying; Richard Henderson; GCC
Subject: Re: Fixed-point branch?
Joseph S. Myers wrote:
I haven't examined it. When the branch maintainers
[EMAIL PROTECTED] wrote:
phew, a few of the cygwin failures show up like this:
Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
Jan-Benedict Glaw wrote:
Come visit git.infradead.org and its GCC development fork.
*cough* No reason to fork. At least I'm just too used to GIT these
days and like it quite a lot, that's why I work on getting the
toolchain repos converted (and kept up-to-date!) somewhere as GIT
repos.
Can someone explain why libjava *must* commit binary files to the
repository? A merge of trunk to the fortran-experiments branch
generated 70 conflicts that I need to resolve. This is a complete
waste of time that would have been spent towards cutting a diff
of the branch against trunk for patch
Currently, it is not possible to use SSE 4.1 variable blend instructions in asm
statements. These instructions require the third argument to be in %xmm0, but
gcc fails to allocate correct register even when (new) z constraint is used.
--cut here--
typedef float V4SFmode
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 07:22 ---
How can this be a regression if the constraint is new?
Also it seems like you could use register asm(xmm0) to get the correct
register to be used.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from ubizjak at gmail dot com 2007-06-04 07:39 ---
(In reply to comment #1)
How can this be a regression if the constraint is new?
This is the same failure as PR32189, and that one is marked as a regression.
Also it seems like you could use register asm(xmm0) to get
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-04 07:50 ---
Also it seems like you could use register asm(xmm0) to get the correct
register to be used.
But please note that c argument is passed to the function via xmm2.
So this is why GCC has register asm() extension is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-04 07:58 ---
Note local allocate should be able to figure the z constraint is only one
register and assign it to that pesdu-register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
--- Comment #5 from ubizjak at gmail dot com 2007-06-04 08:06 ---
Created an attachment (id=13655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13655action=view)
Local alloc RTL dump
RTL dump of .c.163r.lreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
--- Comment #4 from jbglaw at lug-owl dot de 2007-06-04 08:18 ---
That was already known in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563 ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537
--- Comment #4 from rob1weld at aol dot com 2007-06-04 08:30 ---
Results:
Results for 4.3.0 20070602 (libc6_2.3.6.ds1-13) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00168.html
Results for 4.3.0 20070602 (libc6_2.6~20070518-2) testsuite on
Please read first portion of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
to see the where and how of obtaining and installing new libc6, then come back
here.
After upgrading my library I did a diff of the make -i check test results of
the build before I upgraded and after I upgraded. It was
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 ---
No need because this failure is a random failure anyways.
*** This bug has been marked as a duplicate of 32057 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 ---
*** Bug 32202 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-04 08:44 ---
Subject: Re: Upgrading GNU/Linux to libc6_2.6~20070518-2
fails gfortran.dg/secnds.f
No need because this failure is a random failure anyways.
Afterall not so random: most of the failures are due to the fact
that
--- Comment #7 from rob1weld at aol dot com 2007-06-04 08:58 ---
[EMAIL PROTECTED]
IEEE 754 does not discuss any of the functions you list above. In fact,
IEEE 754 places requirements on exactly one function in libm, and that is
sqrt(), which must be exact in all rounding modes.
--- Comment #8 from rob1weld at aol dot com 2007-06-04 09:07 ---
[EMAIL PROTECTED]
Can you suggest a download URL?
Mine is from ATT. I didn't save the URL. Your output is certainly a few pages
shorter than mine. There is a Paranoia test included in Ucbtest that has output
similar to
--- Comment #9 from rob1weld at aol dot com 2007-06-04 09:16 ---
There is a wiki here - your contributions are appreciated.
http://en.wikipedia.org/wiki/IEEE_754r
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
As requested: http://gcc.gnu.org/ml/fortran/2007-06/msg00013.html
timef() allows one easily to track elapsed time. It is supported by a couple of
vendors such as IBM and Intel, but not by gfortran, g95, g77, sunf95, NAG f95.
--- Comment #1 from dominiq at lps dot ens dot fr 2007-06-04 11:25 ---
As far as I can tell this bug seems to affect only darwin7.
The ICE occurs with RESHAPE and EOSHIFT with character arrays and a third
optional argument:
The following code
character(len=1) :: tempn(1,2)
X-Bugzilla-Reason: CC
First: I apologize if this report is missing something but I did not find
enough information in the guidelines to be more accurate. Furthermore, I have
only gcc 4.1.2 prerelease available (from Suse Linux 10.2), so I will be glad
if somebody tells me the bug has been fixed
--- Comment #8 from ubizjak at gmail dot com 2007-06-04 12:27 ---
A bit of debugging leads to following findings:
build_common_builtin_nodes() defines supported complex mul/div functions
depending on lang_hooks.types.type_for_mode(). This langhook defaults to
c_common_type_for_mode().
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
Consider the following code:
% cat unused.cpp
static int GetFoo() { return 17; }
static int foo = GetFoo();
void bar()
{
}
This compiles without warnings:
% g++ -Wall -c unused.cpp
%
However if any error is introduced, like e.g. removing the closing brace of the
bar() function, then we get
--- Comment #12 from mec at google dot com 2007-06-04 13:35 ---
Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for
the fast fix!
--
mec at google dot com changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-06-04 13:51 ---
Likely, the code for parsing template arguments is not clever enough to stop as
soon as something goes awry and report it correctly.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #165 from rguenth at gcc dot gnu dot org 2007-06-04 14:02
---
The lates patch fixes the FreePOOMA testsuite regressions. I'll give it a
performance testing spin on vangelis tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 ---
Well, in my ignorance, I'd say that the symptoms are consistent with scanning
forward to the next , regardless of what gets scanned over, such an
unmatched or statement-lists.
--
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-04 15:28
---
solution_set_add () looks like the culprit (thx micha). So, the following will
fix it in case we have offsets only from COMPONENT_REFs, not from regular
pointer arithmetic (which is not true):
Index:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-04 15:45
---
We can make it safe if we only really handle + in pointer arithmetic. Like
with
@@ -3258,7 +3255,7 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
unsigned int i = 0;
unsigned int j = 0;
VEC (ce_s, heap)
--- Comment #15 from sje at gcc dot gnu dot org 2007-06-04 15:58 ---
Subject: Bug 31733
Author: sje
Date: Mon Jun 4 15:58:12 2007
New Revision: 125312
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125312
Log:
PR target/31733
* cfgrtl.c (rtl_verify_flow_info):
--- Comment #16 from sje at cup dot hp dot com 2007-06-04 16:03 ---
Fixed now. All testcases are working with ToT.
--
sje at cup dot hp dot com changed:
What|Removed |Added
# of unsupported tests 46
/Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.3.0
20070604 (experimental)
--
Summary: gfortran testsuite - unexpected failures
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 ---
Only semi unexpected, the issue hasto do with fp rounding,
*** This bug has been marked as a duplicate of 32057 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-04 16:11
---
*** Bug 32206 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
the following testcase express one condition in three different ways.
in fact, gcc produces only two different warnings.
extern void z();
void f() { if ( z ) z(); }
void g() { if ( z != 0 ) z(); }
void h() { if ( z != (void*)0 ) z(); }
t.c: In function 'f':
t.c:2: warning: the address of 'z'
--- Comment #4 from aldot at gcc dot gnu dot org 2007-06-04 17:20 ---
fx, are you still working on this?
yet another reason why -M as an alias for -J should be dropped and instead
proper -M dependency handling should be added is this:
$ echo end foo.f90 gfortran -o main foo.f90 -v
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-04 17:32 ---
(In reply to comment #7)
[EMAIL PROTECTED]
IEEE 754 does not discuss any of the functions you list above. In fact,
IEEE 754 places requirements on exactly one function in libm, and that is
sqrt(), which must
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39
---
(In reply to comment #4)
fx, are you still working on this?
Not actively. It's probably not so hard, though: read the file, like we do with
-fsyntax-only mode, and parse #file headers.
yet another reason why
--- Comment #9 from ubizjak at gmail dot com 2007-06-04 17:42 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00188.html
(Please do not open new bugreport for missing _multc3 and _divtc3. These will
be added as a follow-up patch).
--
ubizjak at gmail dot com changed:
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ubizjak at gmail dot com|
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-04 18:12 ---
(In reply to comment #8)
I suspect (unless I'm overlooked something) that this problem cause wrong
statistics when using jointly the -fopenmp and -profile-* flags.
I tried that and seen
[EMAIL PROTECTED]:~/exp-43-redux$ cat vector-fill.cc
// Copyright 2007, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
#include vector
std::vectorint my_vector (117);
===
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070601/install/bin/g++
-Wall
-S
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./cfgloopanal.o differs
./expmed.o differs
./df-problems.o differs
./combine.o differs
./ebitmap.o differs
./emit-rtl.o differs
./reload.o differs
./cgraphunit.o differs
./c-typeck.o differs
./recog.o differs
--- Comment #10 from uros at gcc dot gnu dot org 2007-06-04 20:07 ---
Subject: Bug 32191
Author: uros
Date: Mon Jun 4 20:07:37 2007
New Revision: 125314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125314
Log:
PR c/32191
* gcc/c-common.c (c_define_builtins):
--- Comment #11 from ubizjak at gmail dot com 2007-06-04 20:08 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from andreast at gcc dot gnu dot org 2007-06-04 20:09
---
can you post the config flags? Did you may use --disable-checking ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
In the following testcase:
#include new
#include stdlib.h
#include stdio.h
class c1
{
public:
char m1 : 17;
//char m2;
};
void printbytes(void * p, int size)
{
printf(Printing an object on %i bytes\n,size);
for (int i=0; isize; i++)
printf(Byte %i is %i\n,i, ((char*)p)[i]);
While compiling KDE 3.5.7, this appears:
-
Making all in interfaces
make[5]: Entering directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail/interfaces'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
--- Comment #2 from malitzke at metronets dot com 2007-06-04 20:42 ---
Confirmation on different architecture (powerpc-linux-gnu G4) doing an *.nm
comparison as follows: on c-common.o
16c16
00017d5c t add_tlist
---
00017d60 t add_tlist
60c60
00018ca0 T c_add_case_label
---
00018ca4
--- Comment #3 from malitzke at metronets dot com 2007-06-04 20:56 ---
Took the liberty of adding Prof Sikora and the release manager, Could not add
MR
Zedenek Dvorak (refusla by [EMAIL PROTECTED]
This seems to be a case Maintainers no doing the required bootstraps. I am
amazed that
--- Comment #6 from rep dot dot dot nop at gmail dot com 2007-06-04 20:50
---
Subject: Re: gfortran should be able to output Makefile dependencies with -M*
options
On Mon, Jun 04, 2007 at 05:39:48PM -, fxcoudert at gcc dot gnu dot org
wrote:
--- Comment #5 from fxcoudert at
--- Comment #50 from manu at gcc dot gnu dot org 2007-06-04 21:12 ---
Subject: Bug 25241
Author: manu
Date: Mon Jun 4 21:11:51 2007
New Revision: 125317
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125317
Log:
2007-06-04 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #18 from hjl at lucon dot org 2007-06-04 21:14 ---
(In reply to comment #12)
Maybe someone should timings without the second reassoc.
Jeff mentioned the loop optimizers cause new reassociations:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html
And Daniel Berlin
--- Comment #19 from hjl at lucon dot org 2007-06-04 21:39 ---
Can anyone show that the newly added dce_loop anything useful? Can we disable
it or move it after the second reassoc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #4 from malitzke at metronets dot com 2007-06-04 21:56 ---
Here is the build machinery used on the powerpc: There were two changes made to
prior runs that caused no boot failures:
BUILD was incresed from 11 to 12
form enable-languages c++, fortran were removed as being
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:15 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if there is
--- Comment #21 from hjl at lucon dot org 2007-06-04 22:19 ---
(In reply to comment #20)
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a
loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-04 22:01 ---
So you found a bug that was only exposed with --disable-checking which
usually means two thing, a gcc_assert really has side effects or something is
being micompiled now. Also by the way since the trunk works
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:39 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-06-04 23:01
---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
On 4 Jun 2007 22:15:46 -, rakdver at kam dot mff dot cuni dot cz
[EMAIL PROTECTED] wrote:
--- Comment #20 from rakdver at
--- Comment #24 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
23:23 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if
I want to build a gcc 4.3.0 fresh from svn for the fr30-elf target.
Binutils 2.17 are already installed in /usr/local/fr30-elf-new/.
In the gcc source directory I do:
# ./configure --target=fr30-elf --prefix=/usr/local/fr30-elf-new/
[...]
# make
[...]
The build fails with the
--- Comment #26 from rakdver at gcc dot gnu dot org 2007-06-04 23:35
---
Created an attachment (id=13656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656action=view)
patch preventing reassociation across loop boundaries
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 23:37 ---
Building in the source directory is one of the least tested features of GCC,
you should try building in a different directory as recommended by
http://gcc.gnu.org/install .
--
pinskia at gcc dot gnu dot org
--- Comment #25 from rakdver at gcc dot gnu dot org 2007-06-04 23:34
---
Reassoc should be fixed, we should not consider workarounds like this.
Either fix or remove reassoc2 works for me :)
One possible fix is attached; it prevents us from reassociating across loop
boundaries.
The web page:
http://gcc.gnu.org/onlinedocs/libiberty/
Indicates that libiberty is LGPL. The directory for libiberty also contain
only a COPYING.LIB, again indicating it should be LGPL to me.
However, at least make-relative-prefix.c indicates that it is part of
libiberty, but is GPL, not LGPL.
--- Comment #2 from tk at maintech dot de 2007-06-05 00:06 ---
Ok, if I build outside the source tree, the problem doesn't appear.
I'm not sure if this is still a bug or not, so I'm leaving the ticket open.
Thanks for the hint!
--
tk at maintech dot de changed:
What
--- Comment #1 from joseph at codesourcery dot com 2007-06-05 00:07 ---
Subject: Re: New: License for libiberty
See http://gcc.gnu.org/ml/gcc/2003-06/msg01286.html; I don't recall
seeing the SC's/FSF's answer to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-06-05 00:12
---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
On 4 Jun 2007 23:35:19 -, rakdver at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #26 from rakdver at gcc dot
--- Comment #28 from hjl at lucon dot org 2007-06-05 00:15 ---
(In reply to comment #25)
So probably this restriction should be applied only in reassoc2 (or reassoc2
should be removed, if Daniel believes it is not useful).
My SPEC CPU 2000 resutls in comment #18 shows reassoc2
description test
--
Summary: summary test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #6 from malitzke at metronets dot com 2007-06-05 01:29 ---
Fantastic; My stupidity in copying the disable-checking from one of the dozen
top distributors (which make experimental gcc-4.x.y available, patched them
with gcc-3.x.y stuff and referred users to contact gcc
--- Comment #1 from fang at csl dot cornell dot edu 2007-06-05 01:57
---
g++: Internal error: Killed (program cc1plus)
... suggests that some external force terminated g++. Did you perhaps run out
of memory? (If so, try 'ulimit')
--
fang at csl dot cornell dot edu changed:
--- Comment #7 from andreast at gcc dot gnu dot org 2007-06-05 04:48
---
still broken for disable-checking
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
95 matches
Mail list logo