Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50), though.
I've looked at
Hi,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50), though.
what LLVM version
LLVM? From what I know llvm-gcc is an alternative for gcc. Are any
parts of LLVM used in current GCC? None of what I know.
Sorry, I confused my mailing lists and thought you had asked on
the LLVM mailing list. This explains why I didn't understand
your questions :)
Sorry about the noise,
Sergei Poselenov writes:
Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1
Sergei Poselenov writes:
No, all results are for the GCC project. Mainline here means the
current development version of GCC. For it, the sum of the test code
size is 3503061, vs. 3542052 for the gcc_4_0_0 branch. But again,
this performance is achieved by the significant regression for
When a loop is vectorized, some statements are removed from the basic
blocks, but the vectorizer information attached to these BBs is never
freed. This is because the attached information is freed by walking
the statements of the basic blocks: see tree-vectorizer.c:1750, but
the transformed
Hello,
I've just noted an error in my calculations: not 40%, but 10%
regression (used gdb to do the calculations and forgot to convert
inputs to float). Sorry.
But the problem still persists for me - I'm building an embedded
firmware (U-Boot) and it doesn't fit into the reserved space
anymore.
From the last GCC Summit we learned about (Fortran) Frontend Based
Optimizations from Toon and it was suggested to tackle one issue by
promoting arrays to a first-class middle-end type. Discussion with
Sebastian also reveals that this makes sense to ease the analysis
of the into-GRAPHITE
Sergei Poselenov writes:
Hello,
I've just noted an error in my calculations: not 40%, but 10%
regression (used gdb to do the calculations and forgot to convert
inputs to float). Sorry.
But the problem still persists for me - I'm building an embedded
firmware (U-Boot) and it
Hello Andrew,
Now, I sympathize that in your particular case you have a code size
regression. This happens: when we do optimization in gcc, some code
bases will lose out. All that we can promise is that we try not to
make it worse for most users.
What we can do is compare your code that has
Sergei Poselenov writes:
Hello Andrew,
Now, I sympathize that in your particular case you have a code size
regression. This happens: when we do optimization in gcc, some code
bases will lose out. All that we can promise is that we try not to
make it worse for most users.
Kaveh == Kaveh R GHAZI [EMAIL PROTECTED] writes:
Kaveh + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
On Wed, 16 Jan 2008, Dorit Nuzman wrote:
From the last GCC Summit we learned about (Fortran) Frontend Based
Optimizations from Toon and it was suggested to tackle one issue by
promoting arrays to a first-class middle-end type. Discussion with
Sebastian also reveals that this makes
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R GHAZI [EMAIL PROTECTED] writes:
Kaveh + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind suppression only silences the error for valgrind. What
Kaveh R. Ghazi writes:
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R GHAZI [EMAIL PROTECTED] writes:
Kaveh + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind
Kaveh == Kaveh R Ghazi [EMAIL PROTECTED] writes:
Kaveh A valgrind suppression only silences the error for valgrind. What if
Kaveh someone uses another memory checking tool? Better to fix it for real
Kaveh IMHO.
Add suppressions for all of them. Any decent memory checker has to
account for
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R Ghazi [EMAIL PROTECTED] writes:
Kaveh A valgrind suppression only silences the error for valgrind. What
if
Kaveh someone uses another memory checking tool? Better to fix it for
real
Kaveh IMHO.
Add suppressions for all of them. Any
On Wed, 16 Jan 2008, Andrew Haley wrote:
Kaveh R. Ghazi writes:
A valgrind suppression only silences the error for valgrind. What if
someone uses another memory checking tool? Better to fix it for real IMHO.
Because it's not a bug? You're changing the code to silence a false
Snapshot gcc-4.2-20080116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080116/
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
Andreas, Jeff,
The documentation for `-malign-int' on m68k hints that 16-bit int
alignment was the prominent alignment chosen by m68k ABI's of the era.
Why is 16-bit int alignment the default for m68k in gcc?
Which ABIs influenced this decision?
Should Coldfire targets default to 16 or 32-bit
On 1/16/08 4:16 PM, Andrew Haley wrote:
Because it's not a bug? You're changing the code to silence a false
negative, which this is what we here in England call putting the cart
before the horse. If we clean up all the memory regions on closedown
we'll be wasting CPU time. And for what?
I
Carlos O'Donell [EMAIL PROTECTED] writes:
Why is 16-bit int alignment the default for m68k in gcc?
Which ABIs influenced this decision?
The original ABI was defined by Sun PCC. Note that the SysV ABI
actually uses natural alignment for all types, but that came only much
later.
You can find
Kaveh R. GHAZI [EMAIL PROTECTED] writes:
For what is to save developer time, which is way more valuable than cpu
time.
If you are the only person running the compiler, then developer time
is far more valuable than CPU time. But tens of thousands of people
run the compiler, and they run it
On Wed, 16 Jan 2008, Tom Tromey wrote:
Kaveh A valgrind suppression only silences the error for valgrind. What if
Kaveh someone uses another memory checking tool? Better to fix it for real
Kaveh IMHO.
Add suppressions for all of them. Any decent memory checker has to
account for the reality
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-16 08:00 ---
(In reply to comment #1)
It is sufficient that BA_T is referenced in tests; eg. by PRINT *, BA_T for the
problem to go away. Thus the problem is that the symbol is not being set as
referenced. I will try to find out
Building the attached file (extracted and reduced from the uclibc) with
-O[1,2,3,s] -fPIC fails :
test.c: In function _start:
test.c:14: error: unable to find a register to spill in class R0_REGS
test.c:14: error: this is the insn:
(insn 16 28 17 0 (set (mem/c/i:SI (plus:SI (reg:SI 12 r12)
--- Comment #1 from chrbr at gcc dot gnu dot org 2008-01-16 08:47 ---
Created an attachment (id=14945)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14945action=view)
Test case
build with sh-superh-elf-gcc -O1 -fPIC test.c -S
--
--- Comment #1 from af804 at bfn dot org 2008-01-16 09:02 ---
tried fresh build with --libexecdir=/usr/lib, problem disappeared, suspect
contamination from previous build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34748
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-16 09:14 ---
Subject: Bug 34669
Author: burnus
Date: Wed Jan 16 09:13:39 2008
New Revision: 131567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131567
Log:
2008-01-16 Steven Bosscher [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-16 09:19 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenther at suse dot de 2008-01-16 09:23 ---
Subject: Re: [4.1/4.2/4.3 Regression] templates, enumerations,
overflow, ice
On Tue, 15 Jan 2008, tbptbp at gmail dot com wrote:
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 ---
I keep
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 09:45 ---
Subject: Bug 34768
Author: rguenth
Date: Wed Jan 16 09:44:23 2008
New Revision: 131568
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131568
Log:
2008-01-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 09:47 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-16 09:47 ---
Subject: Bug 33819
Author: rguenth
Date: Wed Jan 16 09:46:29 2008
New Revision: 131569
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131569
Log:
2008-01-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 09:51 ---
Fixed on the trunk. Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 10:16 ---
On IRC we concluded to XFAIL this warning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-16 10:28 ---
Looks good on the trunk. Also looks good for 4.2.
Can you provide an executable testcase that abort()s if the miscompile happens?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 10:33 ---
Confirmed on x86_64-unknown-linux-gnu.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-16 10:47
---
So, this is still a P1 regression for 4.3. Ping!
(I expect Linux distributors will deal with this problem, but I also expect
our customers to scream bloody murder at us for this change)
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 10:52 ---
Ian, is there any chance you can look at this? Your fix for PR29286 could be
extended to handle this as well, right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-16 11:11 ---
Subject: Bug 34249
Author: uros
Date: Wed Jan 16 11:10:27 2008
New Revision: 131570
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131570
Log:
PR debug/34249
* debug.h
--- Comment #7 from ubizjak at gmail dot com 2008-01-16 11:15 ---
Fixed for 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from chrbr at gcc dot gnu dot org 2008-01-16 11:15 ---
Created an attachment (id=14946)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14946action=view)
fails with 4.2.2 and 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
Starting program:
/scratch/obj.i686/br2/br.update.sh4/build_sh4/staging_dir/usr/libexec/gcc/sh4-linux-uclibcgnueabi/4.3.0/cc1
-fpreprocessed dbxout.i -quiet -dumpbase dbxout.i -auxbase-strip dbx.o -Os
-version -fno-tree-dominator-opts -o /tmp/ccb7b5R5.s
Failed to read a valid object file image
While building the Loki C++ library (http://loki-lib.sourceforge.net/), an
internal error is generated:
-- quote start --
gmake[2]: Entering directory `/home/duplaina/src/loki-0.1.6/test/ScopeGuard'
g++ -Wall -Wold-style-cast -Wundef -Wsign-compare -Wconversion -Wpointer-arith
-pedantic -g -O2
Hi,
G++ (gcc version 4.3.0 20080104 (experimental) (GCC)) accepts the following
code that Comeau rejects:
template typename T
struct Foo
{
void bar ()
{
typename FooT::Foo ();
}
};
--
Summary: G++ accepts wrong code
Product: gcc
Version: 4.3.0
--- Comment #7 from ubizjak at gmail dot com 2008-01-16 11:58 ---
(In reply to comment #6)
Fixed in mainline
Not yet:
FAIL: g++.dg/cpp0x/vt-34103.C (internal compiler error)
FAIL: g++.dg/cpp0x/vt-34103.C (test for excess errors)
--- Comment #3 from chris dot rimmer at antixlabs dot com 2008-01-16 12:08
---
I've just encountered the same issue. My reading of the standard says that it
is a bug.
15.3 [except.handle] paragraph 3
A handler is a match for an exception object of type E if
- The handler is of
The appeded code does not compile without errors:
(Verified on avr-gcc (gcc version 4.2.2)
$ avr-gcc -Wall c++_trial_1.cpp
c++_trial_1.cpp:29: error: uninitialized const 'sM'
Using Visual Studio 2005 Express the same code compiles on the highest
warninglevel without warnings or errors.
#include
--- Comment #6 from tkiernan at gmail dot com 2008-01-16 12:29 ---
Created an attachment (id=14947)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14947action=view)
TestCase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778
--- Comment #7 from tkiernan at gmail dot com 2008-01-16 12:32 ---
(From update of attachment 14947)
Attached is the source code and binary - issue is on gcc4.1.1 Linux redhat4.5,
IBM ppc64.
It aborts when tries to rethrow exception across shared libs.
Execute ./main
--
--- Comment #22 from manu at gcc dot gnu dot org 2008-01-16 12:36 ---
(In reply to comment #21)
(In reply to comment #20)
Anyway, if you really want to believe that printf(%s\n,s) and puts(s)
should
not have the same effect for defined behaviour, then we will have to agree
to
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2008-01-16 12:26
---
Not knowing the gcc code in question, I can't comment on how much potential
regression risk this fix will introduce. Assuming it's safe enough to apply
without worry to other releases, I'd hope this would
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-16 12:56 ---
Subject: Re: [4.3 Regression] FAIL:
gcc.dg/Warray-bounds.c
On IRC we concluded to XFAIL this warning.
Could the relevant parts of the IRC be added to this PR?
--
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-16 12:58 ---
I'm unable to reproduce this failure now. What platform are you on and what
configure flags did you use?
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from tbptbp at gmail dot com 2008-01-16 13:04 ---
Much helpful, many thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-16 13:21 ---
Created an attachment (id=14948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14948action=view)
slightly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:26 ---
EDG rejects this with
t.C(6): error: class template FooT has no member Foo
typename FooT::Foo ();
^
G++ accepts this even if you instantiate Foo. G++ also accepts
template typename T
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 13:28 ---
*** This bug has been marked as a duplicate of 31947 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 13:28 ---
*** Bug 33195 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:30 ---
Probably a dup of PR31947. Hard to say without preprocessed source.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 13:32 ---
EDG says:
t.C(27): error: const variable sM requires an initializer -- class
signalManager has no explicitly declared default constructor
} const sM ;
^
compilation aborted for t.C (code 2)
which
Revision 131565 generates:
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 66)
Revision 131501 is OK.
--
Summary: [4.3 Regression] gcc.dg/Warray-bounds.c
/local
--enable-languages=c,c++,fortran
gcc version 4.3.0 20080116 (experimental) [trunk revision 131569] (GCC)
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-16 13:41
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-16 13:42
---
Subject: Bug 34668
Author: rguenth
Date: Wed Jan 16 13:41:13 2008
New Revision: 131572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131572
Log:
2008-01-16 Jakub Jelinek [EMAIL PROTECTED]
Richard
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 13:17 ---
I also see those two ICEs on x86_64-unknown-linux-gnu. P2 as this shows in
testresults on a primary platform.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-16 14:01 ---
*** Bug 34812 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-16 14:01 ---
*** This bug has been marked as a duplicate of 34801 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kloedej at knmi dot nl 2008-01-16 14:11 ---
Dear people,
this comment is just to let you know that the problem is also solved on my side
now. My software compiles and runs again as expected.
thanks a lot for your effort and fast response.
Jos de Kloe
--
--- Comment #2 from olof dot tangrot at telia dot com 2008-01-16 14:16
---
I know about that. The class don't need a contructor, it does not have anything
that needs to be assigned upon creation. Why should the compiler link in code
that does not do anything? I eats memory. Surely that
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-16 14:38 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i?86-*-* (HWI64)
Target Milestone|---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 14:53 ---
There is a defect report about what is a dependent name. The DR causes some
things to be non dependent and not which were in the original standard and is
weird as it turns somestuff which really should be dependent
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-16 15:01 ---
This testcase does not work even without shared libraries:
terminate called after throwing an instance of 'char const*'
Abort
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-16 15:05 ---
(In reply to comment #2)
I know about that. The class don't need a contructor, it does not have
anything
that needs to be assigned upon creation. Why should the compiler link in code
that does not do anything?
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-01-16 15:07
---
I see the failure on i386-apple-darwin8.11.1 also.
(In reply to comment #8)
I'm unable to reproduce this failure now. What platform are you on and what
configure flags did you use?
Make sure you did not turn
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-16 15:25
---
I still see it on x86_64-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
$ cat ice.f90
MODULE kd_kd_tree_type
TYPE :: kd_tree_node
TYPE(kd_tree_node_private), POINTER :: p
END TYPE
TYPE :: kd_tree_node_private
INTEGER :: dummy
END TYPE
TYPE :: kd_tree
TYPE(kd_tree_node) :: root
END TYPE
CONTAINS
SUBROUTINE kd_tree_init_default(this)
Currently, SDmode (_Decimal32) types are not passed to and returned from
functions in FP registers as mandated by the ABI. Instead, they are passed via
the integer registers. This bugzilla will be used for tracking my work on
fixing this.
--
Summary: SDmode function args not passed
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-16 16:01 ---
Subject: Bug 34769
Author: rguenth
Date: Wed Jan 16 16:00:17 2008
New Revision: 131573
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131573
Log:
2008-01-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from hjl at lucon dot org 2008-01-16 16:16 ---
It isn't fixed. The error went from as to ld:
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-01-16 16:32
---
Subject: Bug 31396
Author: hubicka
Date: Wed Jan 16 16:32:05 2008
New Revision: 131576
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131576
Log:
PR rtl-optimization/31396
* regstat.c
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:33
---
Fixed on mainline.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-16 16:34 ---
Found the relevant part in the Fortran standard:
Fortran 2003: 12.4.1.2 Actual arguments associated with dummy data objects
If the actual argument is an array section having a vector subscript, the
dummy argument
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:46
---
Last time I looked into it, it was code
alignment affected by inlining in the string matching loop (longest_match).
This code is very atypical, since the internal loop
--- Comment #21 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:19
---
(In reply to comment #20)
Changing to NEW based on
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00858.html
Shouldn't the PR be closed now, after committing the patch from
--- Comment #9 from ubizjak at gmail dot com 2008-01-16 17:25 ---
(In reply to comment #8)
It isn't fixed. The error went from as to ld:
Here is my log:
Executing on host: /home/uros/gcc-build-all/gcc/xgcc
-B/home/uros/gcc-build-all/gcc/ /home/uros/gcc-svn/trunk/gcc/
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-16 17:33 ---
This regression enters between 4.1/20050803 and 4.2/20061221.
gfc_check_constructor_type is applying the wrong type, because the intrinsic
has not been resolved. (This is called from gfc_match_init_expr via
--- Comment #8 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:39
---
This is fixed in current mainline GCC (as per
http://gcc.gnu.org/gcc-4.3/porting_to.html).
--
tsarkov at cs dot man dot ac dot uk changed:
What|Removed |Added
--- Comment #10 from ubizjak at gmail dot com 2008-01-16 17:44 ---
(In reply to comment #9)
.LASFDE3:
.long .LASFDE3-.Lframe1
.long .LFB15
- .long .LFE15-.LFB15
+ .long .LHOTB1
+ .long .LHOTE1-.LHOTB1
+ .long .LCOLDB1
+
--- Comment #1 from bergner at gcc dot gnu dot org 2008-01-16 17:51 ---
I'll be posting a proposed patch today or tomorrow. The patch will allow us to
be binary compatible with XLC which is producing binaries that follow the ABI.
There have been some reload issues which have made
--- Comment #11 from hjl at lucon dot org 2008-01-16 18:23 ---
(In reply to comment #9)
GNU ld version 2.17.50.0.3-6 20060715
Your linker doesn't issue the error since it is too old. See
http://sourceware.org/bugzilla/show_bug.cgi?id=4454
--
hjl at lucon dot org changed:
--- Comment #12 from ubizjak at gmail dot com 2008-01-16 18:25 ---
Created an attachment (id=14949)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949action=view)
Patch to fix issue in Comment #8
H.J, could you test if attached patch fixes the problem from Comment #8?
--
[forwarded from http://bugs.debian.org/440287]
seen with current 4.1 and 4.2 branches, not seen on the trunk.
Matthias
While trying to compile the 2.6.23-rc4 snapshots from buildserver.net on hppa,
gcc went in some kind of endless loop over the following command
hppa64-linux-gnu-gcc-4.1
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-01-16
18:38 ---
Created an attachment (id=14950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14950action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
--- Comment #18 from bkoz at gcc dot gnu dot org 2008-01-16 18:46 ---
The ammount of breakage for this change is IMHO tolerable and will within the
tolerances of other breakages that nobody is talking about reverting, and
furthermore solutions for the API change are well documented.
--- Comment #19 from bkoz at gcc dot gnu dot org 2008-01-16 18:58 ---
I'm asking for a libstdc++ maintainer vote on this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-16 19:06
---
I still see people use the old deprecated headers all over the place, even in
newer bug reports. So it is hard to think they will be removed any time soon.
I am sorry but from a QA point of view, they should be
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 19:18 ---
This sounds like an exact duplicate of PR 31944 which was just fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
1 - 100 of 185 matches
Mail list logo
