--- Comment #3 from iwamatsu at nigauri dot org 2010-03-19 06:11 ---
(In reply to comment #2)
Looks the same issue in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html
though I can't reproduce the problem with my gcc-4.4.3 and
4.4 head compilers for the test case in #1.
The -O0 result looks right. This behavior observed on x86 using r157445 and
x64 using r157542.
reg...@john-home:~$ current-gcc -O0 small.c -o small -Wall
reg...@john-home:~$ ./small
1
reg...@john-home:~$ current-gcc -O1 small.c -o small -Wall
reg...@john-home:~$ ./small
0
reg...@john-home:~$
--- Comment #1 from sezeroz at gmail dot com 2010-03-19 06:51 ---
Happened on x86_64-pc-linux and my gcc-4.4 was affected too, gcc-3.4.6 seemed
fine.
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:19
---
Subject: Bug 43106
Author: ebotcazou
Date: Fri Mar 19 07:18:47 2010
New Revision: 157558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157558
Log:
PR ada/43106
*
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:22
---
Presumably by the overhaul of the subtypes support.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kurt at garloff dot de 2010-03-19 08:03 ---
Well for 4.5, make sure you configured with --enable-checking=release;
otherwise it is not a fair comparison.
Did not change anything unfortunately :-(
(I have enabled --enable-lto in case this matters, though I have
--- Comment #2 from mikpe at it dot uu dot se 2010-03-19 09:46 ---
4.2.4/4.3.4/4.4.3 are affected, 4.1.2 and older seem to be Ok.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
I think gcc produce wrong location information of function argument.
/* sample source sub.c **/
int test(int first, int second)
{
return second;
}
//
The sample source is compiled as follows.
==
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-19 09:56
---
(In reply to comment #13)
Hi!
I was wondering if this bug is likely to be fixed in the next GCC release; is
this likely to be the case?
Unlikely. Backporting the one-line change will cause massive
--- Comment #14 from rguenther at suse dot de 2010-03-19 10:09 ---
Subject: Re: [4.3 Regression] very long
compile-time in PRE building gimp-plugin-registry
On Fri, 19 Mar 2010, kurt at garloff dot de wrote:
--- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 ---
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-03-19 10:14
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-03-19 10:15
---
(In reply to comment #14)
Subject: Re: [4.3 Regression] very long
compile-time in PRE building gimp-plugin-registry
On Fri, 19 Mar 2010, kurt at garloff dot de wrote:
--- Comment #11 from kurt at
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 ---
Subject: Bug 43415
Author: rguenth
Date: Fri Mar 19 10:18:25 2010
New Revision: 157562
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157562
Log:
2010-03-19 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 ---
Fixed for 4.5 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #13 from mrs at gcc dot gnu dot org 2010-03-19 10:20 ---
Subject: Bug 42554
Author: mrs
Date: Fri Mar 19 10:19:52 2010
New Revision: 157563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157563
Log:
PR ada/42554
* configure.ac: Only pass -c to ranlib
--- Comment #47 from rguenth at gcc dot gnu dot org 2010-03-19 10:26
---
(In reply to comment #46)
The answer to the question (b) in comment #35:
(b) why !optimize_size has been replaced with optimize_insn_for_speed_p ()?
seems to be
this patch replace some of optimize_size
--- Comment #48 from rguenth at gcc dot gnu dot org 2010-03-19 10:35
---
Untested patch doing 2):
Index: builtins.c
===
--- builtins.c (revision 157561)
+++ builtins.c (working copy)
@@ -2980,10 +2980,16 @@
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-19 11:02 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 11:29 ---
Combine breaks this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 11:35 ---
It combines
(insn 6 5 7 2 t.c:16 (parallel [
(set (reg:SI 59 [ D.2732 ])
(ior:SI (reg:SI 67 [ g_9 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-19 12:04 ---
Yes - haven't thought about it much, maybe the backend could give an error if a
frame were allocated for a naked function rather than ICE'ing in an awkward
place.
--
ramana at gcc dot gnu dot org changed:
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-19 12:06 ---
Breakpoint 7, combine_simplify_rtx (x=0x75ae6e58, op0_mode=VOIDmode,
in_dest=0) at /space/rguenther/src/svn/trunk/gcc/combine.c:4861
4861 enum rtx_code code = GET_CODE (x);
(set (reg:SI 69)
(and:SI
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 ---
Subject: Bug 43305
Author: matz
Date: Fri Mar 19 12:37:28 2010
New Revision: 157567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157567
Log:
PR 43305
* builtins.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-19 12:40 ---
make_extraction (mode=SImode, inner=0x75b48ac8, pos=0, pos_rtx=0x0, len=8,
unsignedp=1, in_dest=0, in_compare=0)
at /space/rguenther/src/svn/trunk/gcc/combine.c:6648
6648 enum machine_mode is_mode
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 12:53 ---
(In reply to comment #2)
Oh it might also need the patch for PR 29751 which I hope to submit for 4.6.
Note the patch in there still works and has been tested as of earlier this
week.
New mem-ref will make that
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** Bug 43429 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** This bug has been marked as a duplicate of 43426 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Function:
float y;
float foo(float x)
{
y = x * x + x;
asm volatile (vmov.i8 q0, #0 ::: q0);
asm volatile (vmov.i8 q1, #0 ::: q1);
asm volatile (vmov.i8 q2, #0 ::: q2);
asm volatile (vmov.i8 q3, #0 ::: q3);
asm volatile (vmov.i8 q4, #0 ::: q4);
asm volatile (vmov.i8 q5,
--- Comment #8 from eli dot osherovich at gmail dot com 2010-03-19 13:27
---
(In reply to comment #6)
Also: 1e22 is not exactly representable as a floating point number. By
consequence, 1e22 is different numbers when stored as a double or a
long double, and we should expect
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-03-19 13:27
---
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements. All such asms should be treated as
volatile.
--
--- Comment #9 from eli dot osherovich at gmail dot com 2010-03-19 13:29
---
(In reply to comment #7)
Subject: Re: sinl is not computed correctly
On Thu, 18 Mar 2010, bangerth at gmail dot com wrote:
Also: 1e22 is not exactly representable as a floating point number. By
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-19 13:30
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-19 13:32 ---
Yes, there is no easy way of describing the container relationship of the Neon
registers to the compiler at the minute. Thus the only work around at the
moment is to indicate that all the registers contained as part
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O2 -fexceptions -fnon-call-exceptions -fpeel-loops -c -o pr42427.o
/test/gnu/gc
c/gcc/gcc/testsuite/gcc.dg/pr42427.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c:5:21: fatal error: complex.h:
N
--- Comment #1 from nightstrike at gmail dot com 2010-03-19 14:25 ---
This is probably due to the way you built GCC. To have a completely
relocatable toolchain, you need to use the --with-sysroot option to configure,
and you need to set it equal to prefix or below prefix in the
--- Comment #6 from marti at juffo dot org 2010-03-19 14:46 ---
(In reply to comment #5)
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements.
This would break a lot of code; there are use cases where you want to
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-19 15:12 ---
Is this for Thumb1 or Thumb2 ? Can you check with trunk today ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-19 15:21 ---
Confirmed with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from dominiq at lps dot ens dot fr 2010-03-19 15:40 ---
A few remarks about comments #47 and #48
Note that this PR isn't too serious as -fwhole-file isn't the default
for Fortran so we do not run into this unfortunate interaction of
profile estimation and inlining.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-19 15:46 ---
Well, just fixed on the trunk. This fix looks simple enough that it should be
backportable.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldyh at gcc dot gnu dot org 2010-03-19 15:48 ---
Created an attachment (id=20141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20141action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
--- Comment #3 from aldyh at gcc dot gnu dot org 2010-03-19 15:58 ---
Reproduce with: ./cc1 -g -O a.i -mscore3
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ramana at gcc dot gnu dot org 2010-03-19 15:58 ---
Subject: Bug 43399
Author: ramana
Date: Fri Mar 19 15:58:37 2010
New Revision: 157574
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157574
Log:
Fix PR target/43399
2010-03-19 Ramana Radhakrishnan
While looking at PR43058, I've noticed that we generate tons of completely
useless location list elements. E.g. on the pr43058.c testcase with X2 instead
of X4 X4 and without the PR43058 patch applied, we generate extremely long
location list for the first a variable and then each loclist is 2
--- Comment #10 from zsojka at seznam dot cz 2010-03-19 16:08 ---
How does the test work, would it fail on non-patched trunk?
- extern int printf(const char *format, ...);
- printf(%d\n, foo(100));
+ if (foo(100) != 6)
+ __builtin_abort ();
I *think* this would do the job, but I
--- Comment #4 from nightstrike at gmail dot com 2010-03-19 16:16 ---
Can we fix this before 4.5 is released?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 ---
I'm not sure what you're asking. When the unpatched compiler the testcase
(with the printf or the x!=6-abort) will ICE with a checking compiler,
and produce wrong output (0 or an abort) with a nonchecking compiler.
--- Comment #12 from zsojka at seznam dot cz 2010-03-19 16:34 ---
Thank you for the answer. I didn't realise check is usually done only with
compilers built with checking. (and thank you for fixing the issue, of course)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 ---
Subject: Bug 43116
Author: matz
Date: Fri Mar 19 16:37:27 2010
New Revision: 157578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157578
Log:
PR c++/43116
* attribs.c (decl_attributes): When
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 16:38 ---
Created an attachment (id=20142)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20142action=view)
gcc45-pr43442.patch
Untested patch that cures the size of .debug_loc on the reduced pr43058.c
testcase even
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 ---
Fixed for 4.5. Unassigning myself.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 ---
Actually I have a patch for this, need to polish it somewhat.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 ---
How about not calling cselib_process_insn on DEBUG_INSNs (or better make
cselib_process_insn ignore them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 17:01 ---
Well, we have to call cselib_process_insn on DEBUG_INSNs at least during
var-tracking. As for other passes, such as DSE, haven't thought about the
impliciations of not doing so. Alex?
--
--- Comment #14 from ramana at gcc dot gnu dot org 2010-03-19 17:04 ---
Fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
__attribute__((noinline))
void bar (void)
{
asm volatile ( : : : memory);
}
int
main (void)
{
int i = 6;
bar ();
i++;
asm ( : +r (i));
i++;
return i;
}
on x86_64-linux -g -O2 has bogosity in VAR_LOCATION note:
(note 33 13 21 2 (var_location i (expr_list:REG_DEP_TRUE (plus:SI
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 17:12 ---
Created an attachment (id=20143)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20143action=view)
gcc45-pr43443.patch
Fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-19 17:35 ---
Ah, I see. We have
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 12 r12))
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-19 17:40 ---
(In reply to comment #4)
size.1 is always kind=4 so we may need some error checks if someone tries to
stuff a large file size into a small space.
Thus, we should change the ABI at some point (e.g. when doing the
ICE while building cross-compiler for ARM.
$ /usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-build/./gcc/
-B/usr/src/armtest/arm-none-eabi/bin/ -B/usr/src/armtest/arm-none-eabi/lib/
-isystem /usr/src/armtest/arm-none-eabi/include -isystem
/usr/src/armtest/arm-none-eabi/sys-include-g -O2
--- Comment #7 from bernds at gcc dot gnu dot org 2010-03-19 18:19 ---
Subject: Bug 42258
Author: bernds
Date: Fri Mar 19 18:18:54 2010
New Revision: 157581
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157581
Log:
gcc/
PR rtl-optimization/42258
* ira-lives.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 18:19 ---
Just fixed after this morning (which was done after the snapshot was done).
*** This bug has been marked as a duplicate of 43399 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-03-19 18:19
---
*** Bug 43444 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-19 18:39 ---
Comment #3 makes no sense: There is no such thing as target specific GIMPLE
canonicalization. And also there is no hoisting for GIMPLE so the form of the
IR given in comment #3 wouldn't make a difference.
Even
--- Comment #5 from aldyh at gcc dot gnu dot org 2010-03-19 18:41 ---
Err, I was just going to say that. Curse you Jakub. Let me know when you're
looking at something so we don't duplicate efforts. Wait, am I not supposed to
say curse on a PR? Oh well.
--
--- Comment #5 from bernds at gcc dot gnu dot org 2010-03-19 18:41 ---
Subject: Bug 40697
Author: bernds
Date: Fri Mar 19 18:41:22 2010
New Revision: 157582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157582
Log:
gcc/
PR target/40697
* optabs.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16996
nThis||
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-19 20:25
---
On it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ro at gcc dot gnu dot org 2010-03-19 20:32 ---
Fails on 64-bit Solaris 10, 11/SPARC, too.
I get the following stacktrace:
#0 0xfee7248c in abort () from /lib/libc.so.1
#1 0x08859957 in _cpp_process_line_notes (pfile=0x8b5c468, in_comment=0) at
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 20:37 ---
Created an attachment (id=20144)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20144action=view)
gcc45-pr43437.patch
Possible patch. Except that note_uses (and note_stores) walk parallels from
end to start, so
During a libjava build on i386-pc-solaris2.11, I noticed the following error:
ld.so.1: gcj-dbtool: fatal:
/vol/gcc/obj/gcc-4.5.0-20100208/11-gcc-gld/./gcc/libgcc_s.so.1: wrong ELF
class: ELFCLASS32
/bin/ksh: 29209 Killed
This happens when trying to execute the 64-bit gcj-dbtool. gcj-dbtool
build fails in configure-target-libiberty with:
checking for library containing strerror... configure: error: Link tests are
not allowed after GCC_NO_EXECUTABLES.
Anyway, Probably libiberty should not be built anyway for this target. The same
goes for libssp (can be disabled) and zlib.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 20:45 ---
How did you configure GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
At least on Solaris 10 and 11, both SPARC and x86, the 64-bit TestLeak.exe test
consumes all available memory, possibly bringing the machine to a complete
halt.
The problem seems to be far more severe if gcc is built to use GNU ld instead
of Sun ld.
--
Summary: TestLeak.exe test
gccbug hasn't worked in months if not years. Bug reports submitted using it
are silently dropped, which is the worse that can happen: submitters being
ignored
and possibly even losing their submission are far less likely to report bugs in
the future. Since it seems highly unlikely that a
We found a problem in sbitmap.c:
bool
sbitmap_range_empty_p (const_sbitmap bmap, unsigned int start, unsigned int n)
{
unsigned int i = start / SBITMAP_ELT_BITS;
SBITMAP_ELT_TYPE elm;
...
/* The bits are totally contained in a single element. */
if (shift + n SBITMAP_ELT_BITS)
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-19 20:56 ---
The patch has been bootstrapped/regtested on x86_64-linux and i686-linux and
apparently has huge effect on the debug info size.
i686 cc1 before:
DW_AT_location count 305862
[28] .debug_info PROGBITS
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 21:02 ---
SBITMAP_ELT_TYPE is defined as HOST_WIDEST_FAST_INT. And HOST_WIDEST_FAST_INT
(added by me) is either long or long long. Yes there should be a cast but
it cannot be an issue really with -m32 really because long is
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-19 21:05 ---
This is the comment from hwint.h (which I know I did :) ):
/* Define HOST_WIDEST_FAST_INT to the widest integer type supported
efficiently in hardware. (That is, the widest integer type that fits
in a
Moved from PR 40011 comment 40 into an extra PR. Joost reported that the
following ICEs in gfc_create_module_variable, at fortran/trans-decl.c:3386
The failing assert is:
gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
|| TYPE_CONTEXT (decl) ==
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-19 21:14 ---
I really think it is score backend that should be fixed here.
Say the store multiple should be represented with
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-19 21:50 ---
Similar effects on x86_64 cc1plus:
before:
DW_AT_location count 312834, cc1plus size 83M
[28] .debug_info PROGBITS 10eb517 149edb3 00
0 0 1
[32] .debug_locPROGBITS
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:56
---
I'm building a compiler for Cortex-M3 based microcontroller, so i used this
configure options:
../gcc/configure --prefix=/usr/src/gcc-armtest --target arm-none-eabi
--enable-languages=c --disable-libssp
--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:57
---
I forgot to add, that the configure error is the same as in bug #37634 for
libgfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc/configure --prefix=/usr/src/gcc-armtest --target
arm-none-eabi --enable-languages=c --disable-libssp
Thread model: single
gcc version 4.5.0 20100319 (experimental) (GCC)
--
http://gcc.gnu.org
Since the resolution of LWG 1147, most of the methods on the atomic integral
types should have two overloads, a volatile and a non-volatile version.
However, it appears that since r155377, the volatile overloads are missing from
the atomic integral types altogether.
--
Summary:
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-19 22:08 ---
Are you building a combined tree? Or are you doing the building in different
steps? For a combined tree, it should just work and if you are building a
combined tree please attach the config.log from libiberty
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-19 22:15
---
Yes. To be clear, Bugzilla isn't the proper tool for this kind of issue: it is
for *bug* tracking - not for managing the development of new projects - and the
whole C++0x is indeed a new project, and an
--- Comment #6 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 22:23
---
I haven't looked at newlib yet, as I needed just the C compiler. Source tree is
a vanilla svn checkout from svn://gcc.gnu.org/svn/gcc/trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-19 22:25
---
Benjamin, I'm adding you in CC, I don't know which plans do we have wrt to this
issue for 4.5.0...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-19 22:24 ---
So please try with the flags I offered for configuring. Since those are the
options which are needed to build a cross without newlib built (or a combined
tree).
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 ---
Subject: Bug 43211
Author: pinskia
Date: Fri Mar 19 22:52:41 2010
New Revision: 157585
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157585
Log:
2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 ---
Subject: Bug 43211
Author: pinskia
Date: Fri Mar 19 22:52:41 2010
New Revision: 157585
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157585
Log:
2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com
--- Comment #8 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 23:01
---
../gcc/configure --without-headers --with-newlib --prefix=/usr/src/gcc-armtest
--target arm-none-eabi --enable-languages=c --disable-libssp
Now make fails with:
/usr/src/gcc-build/./gcc/xgcc
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-19 23:04 ---
Can you revert all your patches and try again? Because this used to work for
me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #3 from dougkwan at google dot com 2010-03-19 23:09 ---
Yes, I lied to configure. So this is not a real bug.
--
dougkwan at google dot com changed:
What|Removed |Added
1 - 100 of 116 matches
Mail list logo
