--- Comment #2 from steven at gcc dot gnu dot org 2010-04-13 06:59 ---
The patch of comment #1 is not the right thing to do. What it means, is that
recog_data finds an operand for which the insn has no df_ref.
Caused by http://gcc.gnu.org/viewcvs?view=revision&revision=158187
--
ste
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-04-13 06:56 ---
Looks that Christian's patch pic-cp.patch
http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794
in PR target/42841 can fix the problem. Could you
please try it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-04-13 06:34 ---
Confirmd.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #1 from iwamatsu at nigauri dot org 2010-04-13 06:12 ---
Created an attachment (id=20376)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20376&action=view)
source code that can reproduce problem
This is the source code that can reproduce a problem.
--
http://gcc.g
$ gcc-4.4 -c -D_GNU_SOURCE -D_REENTRANT -Wall -g -O2 -fPIC -DPIC db4.8-x.c
../dist/../lock/lock_deadlock.c: In function '__lock_detect':
../dist/../lock/lock_deadlock.c:123: warning: 'idmap' may be used uninitialized
in this function
../dist/../lock/lock_deadlock.c:124: warning: 'bitmap' may be u
--- Comment #41 from davek at gcc dot gnu dot org 2010-04-13 06:01 ---
Thanks everyone for all the help with testing and validation :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #40 from davek at gcc dot gnu dot org 2010-04-13 05:58 ---
Submitted to -patches list at:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from spop at gcc dot gnu dot org 2010-04-13 05:41 ---
This commit causes the bootstrap to fail at -O3.
c26ce8a90a7c8ef9b6587959083d12f6edbc5e01 is first bad commit
commit c26ce8a90a7c8ef9b6587959083d12f6edbc5e01
Author: rguenth
Date: Wed Apr 7 12:31:32 2010 +
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-13 05:40 ---
(In reply to comment #4)
> Looking at latest gfortran, we have raw_init and buf_init functions which set
> the style of I/O. I think it would be relatively easy now to create a Gnu
> extension as an intrinsic procedu
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-04-13 04:31
---
With current trunk (4.6) I see this:
$ valgrind --leak-check=full f951 parameter_array_init_4.f90
--- snip ---
==12209== 48 bytes in 6 blocks are definitely lost in loss record 21 of 352
==12209==at 0x4A05
--- Comment #1 from ian at airs dot com 2010-04-13 04:21 ---
I forgot to mention that I was using -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
On 32-bit x86 I compiled this test case with -msse2 -mmmx:
#include
__m64 foo (int *p)
{
__m64 m1 = _mm_cvtsi32_si64 (*p++);
__m64 m2 = _mm_cvtsi32_si64 (*p);
return _mm_unpacklo_pi8 (m1, m2);
}
Note that all operations are MMX functions defined in mmintrin.h. The
resulting assembler code
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-13 04:10
---
Looking at latest gfortran, we have raw_init and buf_init functions which set
the style of I/O. I think it would be relatively easy now to create a Gnu
extension as an intrinsic procedure call that will force a f
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2010-04-13
01:54 ---
Interestingly, if you examine clang/lib/Driver/Tools.cpp from the upcoming 2.7
release, you find...
// FIXME: For some reason GCC passes -lgcc before adding
// the default system libraries. Just m
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-04-13 01:40 ---
Created an attachment (id=20375)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20375&action=view)
A reduced test case
It fails also on sh-elf with -m4 -O -funroll-loops.
I've confirmed that the patch below ca
sh4-unknown-linux-gnu failed to build during compiling libgfortran
with
/exp/ldroot/dodes/xsh-gcc-orig/./gcc/xgcc
-B/exp/ldroot/dodes/xsh-gcc-orig/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/
--- Comment #2 from danglin at gcc dot gnu dot org 2010-04-13 01:30 ---
Compiler must be miscompiled as stage1-gcc/cc1 doesn't have fault.
Starting program: /mnt/gnu/gcc/objdir/gcc/cc1 -iprefix
/mnt/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.5.0/ -isystem
/mnt/gnu/gcc/objdir/gc
--- Comment #1 from danglin at gcc dot gnu dot org 2010-04-13 01:17 ---
asm processing is broken causing several tests to fail
for the same reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-04-13 01:16 ---
Created an attachment (id=20374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20374&action=view)
a reduced test case
xxx.ii: In constructor 'std::ios_base::Init::Init()':
xxx.ii:161:3: error: insn does not sa
Unified build on sh-unknown-elf with enabling c++ ICEs during
compiling libstdc++-v3/src/ios_init.cc with -m2a. It starts
to fail my recent change
r158208 | kkojima | 2010-04-12 07:59:36 +0900 (Mon, 12 Apr 2010) | 7 lines
* config/sh/sh-protos.h (sh_legitimize_reload_address): Declare.
--- Comment #42 from iains at gcc dot gnu dot org 2010-04-13 01:07 ---
actually,
The logic in libgcc_s/libgcc_ext is working properly - libgcc_s.10.5 =>
/usr/libgcc_s.1.dylib => /usr/libSystem.dylib. The function is named in
/usr/lib/libgcc_s.10.5.
What is happening is Bad [at least
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c -O1
-fdump-tree-alias-v
ops -S -o 20031015-1.s(timeout = 300)
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c: In function
'main':
/mnt/gnu/gcc/
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr43643.c -O2 -pg -lm -o ./pr43643.exe
(timeout = 300)
Warning: consider linking with `-static' as system libraries with
profiling support are only provided in archive format
--- Comment #1 from sherpya at netfarm dot it 2010-04-12 23:36 ---
FIONREAD is defined by winsock header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Version|unknown |4.3.0
http:/
basic_file_stdio.cc in __basic_file::showmanyc()
uses ioctl with FIONREAD, but the equivalent on win32 is ioctlsocket,
perhaps not usable here, because I think there is not support for socket here
in gcc (I'm wrong?)
anyway it does not compiles
I solve this by commenting out that part
int __r
--- Comment #4 from fang at csl dot cornell dot edu 2010-04-12 21:39
---
Plz? :)
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
CC|
--- Comment #6 from mikpe at it dot uu dot se 2010-04-12 21:38 ---
Created an attachment (id=20373)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20373&action=view)
proposed 4.4 fix for PR43722
Turns out r147577 contains a few redundant changes wrt this bug. The attached
patch ba
--- Comment #9 from mrs at gcc dot gnu dot org 2010-04-12 21:32 ---
Agreed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
I was trying to bootstrap GCC rev. 158136 with a different BOOT_CFLAGS:
--- a/Makefile.in
+++ b/Makefile.in
@@ -352,7 +352,7 @@ BUILD_PREFIX_1 = @BUILD_PREFIX_1@
# Flags to pass to stage2 and later makes. They are defined
# here so that they can be overridden by Makefile fragments.
-BOOT_CFLAG
--- Comment #6 from erik at ejohansson dot se 2010-04-12 20:50 ---
Tested with latest Debian gcc-snapshot on the code where I originally saw the
problem and it works now. Thank you very much.
Tested with:
gcc (Debian 20100408-1) 4.5.0 20100408 (prerelease) [gcc-4_5-branch revision
15813
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 20:48 ---
OVERRIDE_OPTIONS is called after the printing out the --help message.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from fabien dot chene at gmail dot com 2010-04-12 20:45
---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00604.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
--- Comment #2 from dougsemler at gmail dot com 2010-04-12 20:44 ---
FWIW:
I realized that I have been playing around with newer ppl and the compiler is
dynamically linking against ppl 0.11 and gmp 5 rather than ppl 0.10 and gmp 4.
When I get rid of the experimental libs in my link pat
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 20:44 ---
I think this is really an issue of how --help=target is displaying the
enable/disable part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43718
--- Comment #5 from mikpe at it dot uu dot se 2010-04-12 20:35 ---
Created an attachment (id=20372)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20372&action=view)
reduced test case in plain C
Reduced test case. This one ICEs both 4.4 and 4.3 but not 4.5.
Using the reduced test
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 20:28 ---
This is the standard if(a) x=,y=,z=; . if (a) use(x,y,z); uninitialized
warning issue (I cannot find a bug about this really).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43736
--- Comment #5 from marcus at jet dot franken dot de 2010-04-12 20:25
---
gcc version 4.5.0 20100331 (experimental) [trunk revision 157870] (SUSE Linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
Invalid warnings about uninitialized variables are given when compiling the
following code at -O3 with gcc 4.4.3 (I see it in 4.5 as well). If I remove
the loop then the warning disappears. This is a contrived example based on
binutils/dwarf.c (which errors out when building with -Werror -Wall -O
--- Comment #17 from ubizjak at gmail dot com 2010-04-12 20:02 ---
(In reply to comment #15)
> GNU as 2.15 doesn't believe you :-)
>
> $ echo sahf > test.s
> $ /usr/sfw/bin/gas test.s
> $ /usr/sfw/bin/gas --64 test.s
> test.s: Assembler messages:
> test.s:1: Error: suffix or operands
--- Comment #9 from jason at gcc dot gnu dot org 2010-04-12 19:59 ---
Subject: Bug 43641
Author: jason
Date: Mon Apr 12 19:58:49 2010
New Revision: 158241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158241
Log:
PR c++/43641
* semantics.c (maybe_add_lambda_conv
--- Comment #13 from jason at gcc dot gnu dot org 2010-04-12 19:58 ---
Subject: Bug 25811
Author: jason
Date: Mon Apr 12 19:58:27 2010
New Revision: 158239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158239
Log:
PR c++/25811
* cp-tree.h (diagnose_uninitialized
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|build |patch
Summary|[4.4 Regression] bootstrap |[4.4 Regression]
--- Comment #28 from steven at gcc dot gnu dot org 2010-04-12 19:56 ---
Triggers in 4.4 with an out-of-tree port.
See http://gcc.gnu.org/ml/gcc/2010-04/msg00243.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/ia32, revision 158227 gave:
FAIL: gcc.dg/guality/inline-params.c -O2 -fwhopr execution test
Revision 158222 is OK. Revision 158225:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00329.html
may be the cause.
--
Summary: [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
--- Comment #34 from mikpe at it dot uu dot se 2010-04-12 19:03 ---
Created an attachment (id=20371)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20371&action=view)
eliminate use of _Unwind_GetRegionStart on ARM, take 2
The previous patch to eliminate _Unwind_GetRegionStart on AR
--- Comment #8 from zsojka at seznam dot cz 2010-04-12 18:55 ---
Created an attachment (id=20370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20370&action=view)
execution tests that FAIL with -fno-ira-share-spill-slots
r158225, x86_64-linux, languages=c,c++,lto,fortran
$ make c
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-12 18:53 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00584.html
for an updated patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25766
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 18:50 ---
Yes you say use the system zlib so if you don't have it installed, well you get
what you deserve.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|lm32-rtems* ICE |[4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
--- Comment #16 from ubizjak at gmail dot com 2010-04-12 18:42 ---
Can you try this (untested) patch?
Index: acinclude.m4
===
--- acinclude.m4(revision 158225)
+++ acinclude.m4(working copy)
@@ -452,6 +452,9
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host tr
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 18:38 ---
And as of:
gcc version 4.6.0 20100408 (experimental) [trunk revision 158138] (GCC)
So confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:34 ---
Still ICEd as of 20100401.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-12 18:21 ---
(In reply to comment #14)
> > Why is that instruction being issued when compiling amd64/libgfortran?
>
> Don't worry about this insn, it works for core2.
GNU as 2.15 doesn't believe you :-)
$ echo sahf > test.s
$ /
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-12 18:20 ---
Well -ffixed-reg-r20 is also broken the same way :) See the duplicated bug
which has a patch which I have not looked into to see if it is the correct fix
yet or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 ---
*** This bug has been marked as a duplicate of 43700 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 ---
*** Bug 43732 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from ubizjak at gmail dot com 2010-04-12 18:16 ---
(In reply to comment #13)
> I can't read or write assembler, but searching the interweb tells me that sahf
> is not valid in 64-bit mode, e.g.
> http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also
> "I
--- Comment #13 from redi at gcc dot gnu dot org 2010-04-12 18:08 ---
I can't read or write assembler, but searching the interweb tells me that sahf
is not valid in 64-bit mode, e.g.
http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also
"Introduction to 80x86 Assembly L
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-04-12 18:06 ---
Committed at revision 158232.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from redi at gcc dot gnu dot org 2010-04-12 18:05 ---
(In reply to comment #3)
> (In reply to comment #1)
> > I'm currently trying another bootstrap without --with-arch=core2
>
> That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and
> arch=core2 t
--- Comment #11 from redi at gcc dot gnu dot org 2010-04-12 18:02 ---
(In reply to comment #10)
> (In reply to comment #9)
>
> > Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while
> > /usr/ccs/bin/ld
> > doesn't?
>
> Well, /usr/ccs/bin/as, of course.
>
gas barfs on it,
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-12 17:58 ---
What happens if you do:
g++ -v -save-temps -G -o libfoo.so foo.C -fPIC
aka add -fPIC when building the shared library?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
--- Comment #10 from ubizjak at gmail dot com 2010-04-12 17:57 ---
(In reply to comment #9)
> Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while
> /usr/ccs/bin/ld
> doesn't?
Well, /usr/ccs/bin/as, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
--- Comment #9 from ubizjak at gmail dot com 2010-04-12 17:56 ---
(In reply to comment #6)
> running the failing command with -save-temps shows that sahf isused here:
>
> .LM312:
> fprem
> fnstsw %ax
> sahf
> jp .L103
> fstp%st(1)
> fstpl -56(%rbp)
>
--- Comment #8 from ubizjak at gmail dot com 2010-04-12 17:47 ---
(In reply to comment #3)
> (In reply to comment #1)
> > I'm currently trying another bootstrap without --with-arch=core2
>
> That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and
> arch=core2 that
--- Comment #5 from bergner at gcc dot gnu dot org 2010-04-12 17:45 ---
Subject: Bug 25972
Author: bergner
Date: Mon Apr 12 17:44:59 2010
New Revision: 158231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158231
Log:
Backport from ibm/gcc-4_3-branch
2009-06-11
--- Comment #2 from paul dot shaklan at solipsys dot com 2010-04-12 17:39
---
Created an attachment (id=20369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20369&action=view)
.ii file associated with main.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
--- Comment #1 from paul dot shaklan at solipsys dot com 2010-04-12 17:38
---
Created an attachment (id=20368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20368&action=view)
.ii file associated with foo.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
Version of GCC:
4.4.3
System Type:
SunOS 5.10 Generic_139555-08 sun4u sparc SUNW,SPARC-Enterprise
Source Code:
// foo.C //
#include
// main.C /
#include
int main()
{
std::cerr << "Hello, World!" << std::endl;
return 0;
}
Build Options:
g++ -v -save-temps -G -o libfo
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-12 17:30 ---
the failure is while building the 64bit libgfortran, is sahf valid in 64-bit
mode?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-12 17:25 ---
running the failing command with -save-temps shows that sahf isused here:
.LM312:
fprem
fnstsw %ax
sahf
jp .L103
fstp%st(1)
fstpl -56(%rbp)
movsd -56(%rbp), %xmm1
ucomisd %xmm1
--- Comment #5 from ubizjak at gmail dot com 2010-04-12 17:24 ---
Looks to me that this is libgfortran messing with choosen assembler.
The bootstrap would die way before libgfortran is touched otherwise.
I'm changing component to libgfortran in the hope that fortraners will confirm
(an
--- Comment #15 from ramana at gcc dot gnu dot org 2010-04-12 17:21 ---
(In reply to comment #12)
> A git bisect between the ranges suggested by Dave in Comment #6, gave me
> r149470 this as the first broken commit using a cross-compiler to
> arm-linux-gnueabi with qemu as the simulator
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-12 17:15 ---
configure:22928: checking assembler for sahf mnemonic
configure:22937: /usr/sfw/bin/gas -o conftest.o conftest.s >&5
configure:22940: $? = 0
configure:22951: result: yes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-12 17:15 ---
(In reply to comment #1)
> I'm currently trying another bootstrap without --with-arch=core2
That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and
arch=core2 that files
--
http://gcc.gnu.or
--- Comment #2 from ubizjak at gmail dot com 2010-04-12 17:11 ---
configure should detect if assembler supports sahf mnemonic.
In your build directory, check gcc/config.log for:
configure:23019: checking assembler for sahf mnemonic
configure:23028: /usr/local/x86_64-unknown-linux-gnu/b
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-12
17:11 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8
also contains a short list of some of the required code changes for MachO LTO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 ---
(In reply to comment #35)
> So if I understand correctly, the "state of things" at the moment is this:
>
> Without LTO:
> > Time: 419.938 sec (6 m 59 s)
>
> with LTO incl linker flags:
> > Time: 443.047 sec (7 m 23 s)
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-12 16:51 ---
P.S. I'm using in-tree gmp 4.4.3 and mpfr 2.4.2
I'm currently trying another bootstrap without --with-arch=core2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
../gcc-4.4.3/configure --prefix=/opt/gcc-4.4.3-64/gcc-4.4.3
--enable-languages=c,fortran --with-system-zlib --with-arch=core2
--with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
--without-gnu-ld
Bootstrap fails with
gmake[5]: Entering directory
`/var/tmp/gcc/tmp/i386-pc-solaris2.10
With gcc 4.4.3 and 4.3.4 and MIPS target, code is incorrectly generated to
save/restore registers specified as "fixed" via the "-ffixed-reg" command-line
option to gcc. This also applies to register globals (which should be treated
as "fixed".)
Test code (test.c):
register int foo asm ("$23")
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-12 16:38
---
Confirmed with mac os x gcc build.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-12 16:29 ---
-Wredundant-decls is a non-default warning already, not enabled with -Wall nor
-W and I certainly don't want to enable it by default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
When compiling a Win64 i686-w64-mingw32 compiler with multilib, ada fails to
build with similar errors as reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993 There is currently no
selection on the i686 side for multilib, as the gcc/gcc-interface/ada Makefile
assumes that no ix86 mingw* t
--- Comment #4 from jason at gcc dot gnu dot org 2010-04-12 16:16 ---
...and then after removing the prototype, compiling with -DD would fail. I
don't object to having such a flag, but I don't think we want it in -Wall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-12 16:15 ---
For the Mach-O file format, follow this link:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
First step for Mach-O support would be figuring out w
Compilation of this test file with versions of gcc-4.5 dated 20090528 to
20100107 produce a fatal internal compiler error; comparable versions of
gcc-4.3 and gcc-4.4 do not have this problem:
% cat bug003.c
extern int (isinfl)(long double);
int
bugfun(long double x, long double y)
{
int resul
--- Comment #38 from ro at gcc dot gnu dot org 2010-04-12 16:10 ---
Could be interesting for Tru64 UNIX, which uses ECOFF, too.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-12
16:02 ---
Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test;
formatted read - wrong numbers
> A git bisect between the ranges suggested by Dave in Comment #6, gave me
> r149470 this as th
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-12 15:59 ---
>From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 :
> Can we use a similar approach for Mach-O [as for PE-COFF]?
I don't speak Mach-O, but yes, the approach should work. You'd start by
saying lto_binary_
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-12 15:59
---
(In reply to comment #12)
> A git bisect between the ranges suggested by Dave in Comment #6, gave me
> r149470 this as the first broken commit using a cross-compiler to
> arm-linux-gnueabi with qemu as the simulato
--- Comment #37 from steven at gcc dot gnu dot org 2010-04-12 15:58 ---
LTO for Mach-O is now being tracked in bug 43729.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
E
This bug report is a placeholder for discussing the changes required for LTO
via collect2 on darwin. It exists to have a distinct discussion about darwin
since we don't use either ELF or binutils. It would be optimal if the required
changes would not involve modifications to the darwin linker since
--- Comment #12 from ramana at gcc dot gnu dot org 2010-04-12 15:50 ---
A git bisect between the ranges suggested by Dave in Comment #6, gave me
r149470 this as the first broken commit using a cross-compiler to
arm-linux-gnueabi with qemu as the simulator .
2009-07-02 Richard Guenther
--- Comment #4 from froydnj at gcc dot gnu dot org 2010-04-12 15:41 ---
FWIW, I cannot reproduce with 'gcc version 4.5.0 20100205'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
--- Comment #3 from manu at gcc dot gnu dot org 2010-04-12 15:38 ---
If you are going to add such a warning, please be more explicit. I suggest:
"redundant prototype for static function %qD because it is never used before
its definition"
--
manu at gcc dot gnu dot org changed:
1 - 100 of 151 matches
Mail list logo
