On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com wrote:
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
[ ... ] lack of test results in some platforms does not mean
that GCC developers are uninterested on supporting those platforms and
much less that they are against
Hi Jonathan,
egcs code was always license-compatible with GCC and was always
assigned to the FSF
The difference is quite significant.
both dragonegg and LLVM are license-compatible with GCC. The dragonegg
code is licensed under GPLv2 or later, while LLVM is licensed under the
University of
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com wrote:
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
[ ... ] lack of test results in some platforms does not mean
that GCC developers are uninterested
Jack Howarth wrote:
Manuel,
What I meant to say was that the reality of the situation is
that 90%+ of the code (by line) is probably created by paid
employees and the way things have shaken out has placed the bulk
of those on linux.
Just a note, AdaCore is certainly not Linux-only-centric
On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com wrote:
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
[ ... ] lack of test
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cyg...@googlemail.com wrote:
On
On 12/04/2010 07:47, Manuel López-Ibáñez wrote:
On 12 April 2010 00:38, Dave Korn dave.korn.cygwin@ wrote:
On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
[ ... ] lack of test results in some platforms does not mean
that GCC developers are uninterested on supporting those platforms and
much
Hi,
I was testing i386-rtems4.10 and 225
tests failed on the target because it
does not have any SSE flavor. It is
the last failures in
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html
FAIL: gcc.target/i386/sse-10.c execution test
FAIL: gcc.target/i386/sse-11.c execution test
.
On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
Hi,
I was testing i386-rtems4.10 and 225
tests failed on the target because it
does not have any SSE flavor. It is
the last failures in
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html
FAIL:
On 12 April 2010 16:18, Dave Korn dave.korn.cyg...@googlemail.com wrote:
Could anyone really believe that without being a grade A tinfoil-hat wearing
crazy? More precisely, could anyone capable of the kind of rational thought
Then, you do not read LWN comments, OS news or BSD mailing lists.
On 04/12/2010 09:05 AM, Richard Guenther wrote:
On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
Hi,
I was testing i386-rtems4.10 and 225
tests failed on the target because it
does not have any SSE flavor. It is
the last failures in
On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote:
qemu with no cpu argument specified. So qemu32.
It does run OK when I change the cpu model to 486
or pentium.
Is qemu reporting that it supports SSE and not doing a good
enough job to make gcc happen?
I think that's quite
On Mon, Apr 12, 2010 at 7:47 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
On 04/12/2010 09:05 AM, Richard Guenther wrote:
On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
Hi,
I was testing i386-rtems4.10 and 225
tests failed on the target because it
If the dragonegg and/or LLVM copyright was assigned to the FSF, which
is a prerequisit for anything included in GCC and not what license the
program is under currently, then I'm quite sure that the GCC
maintainers would be more than happy to include both.
On 04/12/2010 09:56 AM, Nathan Froyd wrote:
On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote:
qemu with no cpu argument specified. So qemu32.
It does run OK when I change the cpu model to 486
or pentium.
Is qemu reporting that it supports SSE and not doing a good
enough job
On Mon, Apr 12, 2010 at 11:00:13AM -0400, Alfred M. Szmidt wrote:
If the dragonegg and/or LLVM copyright was assigned to the FSF, which
is a prerequisit for anything included in GCC and not what license the
program is under currently, then I'm quite sure that the GCC
maintainers would be more
Thanks for the prompt reply and suggestions.
I checked the config.log as per your suggestion.
Check the config.log file for details. A successful build should show
something like this
configure:5634: checking for the correct version of the gmp/mpfr/mpc
libraries
configure:5665: gcc -o
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Err, well. I do not see how most of the code is OS specific
anyway - there is _very_ little code in GCC that is OS specific.
Richard.
Richard,
Except for LTO (for which dragon-egg represents a way around
since
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote:
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
Err, well. I do not see how most of the code is OS specific
anyway - there is _very_ little code in GCC that is OS specific.
Richard.
On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
I have opened PR43729, MachO LTO support needed for darwin, to discuss
this. Can you point me at Dave's previous patches that added LTO-suppport
to a non-ELF platform?
I've linked your new PR to the existing LTO
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our applications. I found
the existing pure and const cannot meet his requirements
because the
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our applications. I found
the existing pure and
We recently tracked down an aliasing bug in gcc-4.4.3 (found by our
TILE-Gx back end, not yet ready to contribute), and we wanted to make
sure the fix is right.
try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
merge_memattrs to merge them. To do so, it has to unify their
On darwin, we are missing a required header file
in the
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config
installation directory. The file gcc/config/darwin-sections.def needs
to be installed in plugin/include/config. What is the 'correct' way
to achieve this (short
Rodolfo == Rodolfo Lima rodo...@rodsoft.org writes:
Rodolfo I wonder what's the current state of -I- vs. -iquote, is there anyone
Rodolfo interested in fixing the fact that -iquote doesn't replace -I-
Rodolfo functionality, needed for out-of-source precompiled header utilization?
AFAIK the
On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter mhostet...@tilera.com wrote:
try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
merge_memattrs to merge them. To do so, it has to unify their
aliasing data such that any insn that aliased either of the original
insns aliases
Great, thanks -- I should have re-checked bugzilla after we tracked
this down.
We also noticed a few minor performance issues along the way.
It would be better if merge_memattrs did a min/max thing with
offset/size to choose an offset and size that encompass both original
references, rather than
On Mon, 2010-04-12 at 08:34 -0700, Name lastlong wrote:
Please check the following relevant information present in the config.log
as follows:
Now that you can see what is wrong, you should try to manually reproduce
the error. Check the libraries to see if they are OK, and if the right
-Original Message-
From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
Sent: Monday, April 12, 2010 8:27 AM
To: Dave Korn
Cc: Jack Howarth; Steven Bosscher; Duncan Sands; gcc@gcc.gnu.org
Subject: Re: dragonegg in FSF gcc?
The fact is that it is (perceived as) more
On 12/04/2010 17:03, Steven Bosscher wrote:
On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth wrote:
I have opened PR43729, MachO LTO support needed for darwin, to discuss
this. Can you point me at Dave's previous patches that added LTO-suppport
to a non-ELF platform?
I've linked your new PR
On 12/04/2010 17:33, Andrew Haley wrote:
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our
On 04/12/2010 07:22 PM, Dave Korn wrote:
On 12/04/2010 17:33, Andrew Haley wrote:
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
On 04/09/2010 03:16 PM, Jonathan Wakely wrote:
Iscassert the only C++ header that causes a problem?
cassert is exactly equivalent toassert.h because it only declares
macros, which are not in namespace std anyway.
So if that's the only problem, usingassert.h instead ofcassert
would solve
On 12/04/2010 19:04, Andrew Haley wrote:
I was thinking about non-memory-mapped I/O, a la x86 I/O ports.
I've always thought that was a bad misnomer. Isn't it just an alternative
memory-mapped address space pretty much like main memory (regardless that the
mapped devices may have some
Tom Tromey wrote:
AFAIK the patch is still waiting for a review. I don't know what the
hangup is. Perhaps it needs more frequent pings.
So, whoever is responsible for this, please step forward :) I'll test
the patch when I get home, but I have no knowledge of gcc's internals to
make a
On 12/04/2010 16:34, Name lastlong wrote:
= config.log ==
configure:5615: $? = 0
configure:5616: result: yes
configure:5634: checking for the correct version of the gmp/mpfr/mpc libraries
configure:5665: i386-pc-mingw32msvc-gcc -o
On Darwin we follow the collect2 phase with a call to dsymutil which
post-processes the object to collect debug info into a separate module.
At present this is done by tricking the driver into calling ld
followed by dsymutils by appending the dsymutils call onto the end of
On Mon, Apr 12, 2010 at 7:38 PM, Mat Hostetter mhostet...@tilera.com wrote:
Also, flow_find_cross_jump coarsens the aliasing information as it
scans, so even if it gives up because it doesn't find enough insns to
merge, the aliasing data is lost. We implemented a split of the scan
from the
On Mon, Apr 12, 2010 at 07:47:31PM +0100, Dave Korn wrote:
On 12/04/2010 19:04, Andrew Haley wrote:
I was thinking about non-memory-mapped I/O, a la x86 I/O ports.
I've always thought that was a bad misnomer. Isn't it just an alternative
memory-mapped address space pretty much like
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c(revision 158148)
+++
Weddington, Eric wrote:
From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
The fact is that it is (perceived as) more difficult to contribute to
GCC than LLVM/Clang for the reasons we all know already.
From my perspective (and someone correct me if I'm wrong) it is easier for LLVM
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
OK, I'll do some testing with it tomorrow. Which GCC versions are affected?
--
Eric Botcazou
OK, I'll do some testing with it tomorrow. Which GCC versions are affected?
I tested trunk and an old 4.2.1 internal branch, and found the bug on
both, so anything in between would be affected too. It goes back at
least to this patch, which mostly fixed the bug:
2008-02-19 Christian Bruel
IainS develo...@sandoe-acoustics.co.uk writes:
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get foo for command lines
with files with these suffixes:
.c
.cc
.for
.F90
but not otherwise (since it says . binds more strongly than
IainS develo...@sandoe-acoustics.co.uk writes:
If I want to install a script (wrapper) that will end up installed in
the same dir as gcc-xyz ...
1/ where do I put that in the GCC source tree?
Either in the gcc subdirectory or in some other top level
subdirectory.
2/ what do I need to
On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get foo for command lines
with files with these suffixes:
.c
.cc
.for
.F90
but not
Weddington, Eric eric.wedding...@atmel.com writes:
From my perspective (and someone correct me if I'm wrong) it is
easier for LLVM to do such marketing and focus on usability details
because they seem to have a central driver to the project, whether
person/group (founder(s)/champion(s)). GCC is,
On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
If I want to install a script (wrapper) that will end up installed in
the same dir as
snip
. If this program will only ever be
run by the gcc driver, then you should install it in either the
IainS develo...@sandoe-acoustics.co.uk writes:
yeah .. we use it in Darwin's dsymutil spec.
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
o:a.out
IainS develo...@sandoe-acoustics.co.uk writes:
I take it that, when called from a spec, any program in $(libsubdir)
will get the right path by the automagic built into the compiler?
Yes.
Or:
If I want to create a new post-collect phase --- is that already
As far as I know there is
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
yeah .. we use it in Darwin's dsymutil spec.
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil
IainS develo...@sandoe-acoustics.co.uk writes:
FWIW I couldn't (quickly) find any other spec using that syntax - so
perhaps it's not important.
There is an example of in java/lang-specs.h.
%{.class|.zip|.jar|!fsyntax-only:jc1 ...
Ian
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
if you put -lm on the c/l dsymutil doesn't get called.
Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver. It doesn't know the source
language of a .o file. So if you are linking, and
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-04-12
06:17 ---
Or just vmov.i32 q8, #0 would be better to avoid any potential data
dependency.
--
siarhei dot siamashka at gmail dot com changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2010-04-12 06:41 ---
(In reply to comment #5)
Some three years later we might expect I am unable to assist further and might
focus my efforts where they are more productive.
Sorry about that. I totally understand your frustration.
--- Comment #10 from iains at gcc dot gnu dot org 2010-04-12 06:43 ---
(In reply to comment #9)
I confirmed with the dsymutil maintainer that my reading of his response was
correct. Indeed, the warning may or may not be significant and has to be
checked for each instance. So if all
--- Comment #11 from iains at gcc dot gnu dot org 2010-04-12 06:57 ---
(In reply to comment #9)
checked for each instance. So if all four test cases are actually emitting
valid dwarf, we can drop the usage of -lm on darwin[921]
The two things are totally unrelated - AFAICT the
gcc version 4.5.0-rc20100406
/**/
#include arm_neon.h
void x(int32x4_t a, int32x4_t b, int32x4_t *p)
{
#define X(n) p[n] = vaddq_s32(p[n], a); p[n] = vorrq_s32(p[n], b);
X(0); X(1); X(2); X(3); X(4); X(5); X(6); X(7);
X(8); X(9); X(10); X(11); X(12);
}
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-12 08:21 ---
GCC would ICE if the referenced DIE wasn't being output on:
gcc_assert (AT_ref (a)-die_offset);
in output_die.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #7 from ramana at gcc dot gnu dot org 2010-04-12 08:38 ---
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-12 08:41 ---
Isn't this just a user error then? You should have used -ffixed-20 if you use
a call saved register as global register IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
--- Comment #2 from mikpe at it dot uu dot se 2010-04-12 08:48 ---
The equivalent C version of this test case ICEs with 4.4.4 but works with 4.3.5
and 4.5.0-RC-20100406.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #13 from julien dot etienne at gmail dot com 2010-04-12 08:50
---
Thanks for the fix !
Do you plan to backport it to 4.3.x ?
Best regards,
Julien Etienne
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
--- Comment #14 from rguenther at suse dot de 2010-04-12 09:00 ---
Subject: Re: [4.3 Regression] Struct to register
optimization fails
On Mon, 12 Apr 2010, julien dot etienne at gmail dot com wrote:
--- Comment #13 from julien dot etienne at gmail dot com 2010-04-12
08:50
--- Comment #5 from mikpe at it dot uu dot se 2010-04-12 09:02 ---
(In reply to comment #4)
Isn't this just a user error then? You should have used -ffixed-20 if you use
a call saved register as global register IMHO.
gcc's documentation (I'm looking at the global register variables
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-12 09:17 ---
Could you post a cleaned-up testcase ? I tried a cleaned up testcase with the
values appropriately zero-initialized and gcc ends up generating the vectorized
value in this case.
--
ramana at gcc dot gnu dot org
--- Comment #8 from siarhei dot siamashka at gmail dot com 2010-04-12
09:34 ---
(In reply to comment #7)
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html
Thank you. I have been testing it for two days already.
It really helps (in the sense that it is
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-12 09:44 ---
Created an attachment (id=20362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20362action=view)
gcc46-pr43690.patch
This is very ugly. Either we should reject all these during gimplification
(m (x+1) is also
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-12 09:50 ---
(In reply to comment #4)
I've tried to isolate the error message from the ICE. The smallest code is
a_module for the error and b_module for the ICE.
Thanks. However, ...
!!$ f951: internal compiler error: in
On Mon, 2010-04-12 at 09:34 +, siarhei dot siamashka at gmail dot
com wrote:
--- Comment #8 from siarhei dot siamashka at gmail dot com 2010-04-12
09:34 ---
(In reply to comment #7)
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html
Thank
--- Comment #9 from ramana dot radhakrishnan at arm dot com 2010-04-12
09:51 ---
Subject: Re: [4.5/4.6 Regression] Invalid code when
building gentoo pax-utils-0.1.19 with -Os optimizations
On Mon, 2010-04-12 at 09:34 +, siarhei dot siamashka at gmail dot
com wrote:
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-04-12 09:53
---
Subject: Bug 43611
Author: rguenth
Date: Mon Apr 12 09:52:50 2010
New Revision: 158218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158218
Log:
2010-04-12 Richard Guenther rguent...@suse.de
PR
--- Comment #16 from jakub at gcc dot gnu dot org 2010-04-12 10:18 ---
Subject: Bug 43560
Author: jakub
Date: Mon Apr 12 10:18:39 2010
New Revision: 158220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158220
Log:
PR tree-optimization/43560
*
--- Comment #17 from jakub at gcc dot gnu dot org 2010-04-12 10:22 ---
Subject: Bug 43560
Author: jakub
Date: Mon Apr 12 10:22:21 2010
New Revision: 158221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158221
Log:
PR tree-optimization/43560
*
--- Comment #18 from jakub at gcc dot gnu dot org 2010-04-12 10:25 ---
Subject: Bug 43560
Author: jakub
Date: Mon Apr 12 10:25:11 2010
New Revision: 158222
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158222
Log:
PR tree-optimization/43560
*
--- Comment #3 from mikpe at it dot uu dot se 2010-04-12 10:31 ---
gcc-4.5-20090514 (r147545): ICE
gcc-4.5-20090521 (r147778): no ICE
Continuing to investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
--- Comment #35 from steven at gcc dot gnu dot org 2010-04-12 10:40 ---
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)
In other words, with LTO is ~6% slower
--- Comment #4 from aflyhorse at foxmail dot com 2010-04-12 10:44 ---
Maybe I should still choose the proprietary compiler of M$ for my
Win_x64-target platform...
--
aflyhorse at foxmail dot com changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-12 11:06 ---
dup of Bug 42101 and Bug 14404 and Bug 38624 and Bug 37175 etc. etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43720
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-12 11:19 ---
(In reply to comment #5)
you're writing a smart pointer class in C++, users expect that you will
support
all the same operators with all the same semantics.
do you mean that users expect this?
volatile SmartPtr
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-12 11:21
---
- D.1850_209 = -alt_90;
- D.2093_151 = -alb_86;
- D.1849_208 = D.1848_207 - alb_86;
+ D.2093_151 = -alt_90;
+ D.1849_208 = D.1848_207 - alt_90;
D.1851_210 = D.1849_208 + -1.0e+0;
- z1a_211 = D.1851_210 +
gcc-4.5.0-RC-20100406 triggers an ICE while building RTEMS:
...
lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../lm32_evr/lib/include -DNO_SSI -DNO_SSL -DNO_CGI -O0
-g -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-MT l
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-04-12 11:52
---
Created an attachment (id=20363)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20363action=view)
*.i of the source file triggering the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
--- Comment #2 from joel at gcc dot gnu dot org 2010-04-12 12:11 ---
Did you have patches to get past
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
--- Comment #7 from joseph dot h dot garvin at gmail dot com 2010-04-12
12:19 ---
Right, I think that's what users expect, assuming you are in a situation where
volatile smart pointers make sense in the first place (in my case they are
smart pointers to addresses within a shared memory
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-12 12:30 ---
(In reply to comment #7)
smart pointers to addresses within a shared memory region
then shouldn't that be SmartPtrvolatile T rather than volatile
SmartPtrT ?
the former points to an object which might change due to
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-04-12 12:31
---
(In reply to comment #2)
Did you have patches to get past
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away?
Neither.
This breakdown is with the rtems-4.11-lm32-rtems4.11-gcc rpm,
--- Comment #3 from roman at binarylife dot net 2010-04-12 12:41 ---
sorry for bothering :)
thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43720
--- Comment #10 from lucier at math dot purdue dot edu 2010-04-12 13:17
---
Subject: Re: Darwin bootstrap failure, ld: bl out of
range
On Sun, 2010-04-11 at 10:29 +, iains at gcc dot gnu dot org wrote:
2. As a matter of curiosity - do you see a big improvement in performance
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-12 13:27 ---
Subject: Bug 43699
Author: jakub
Date: Mon Apr 12 13:27:07 2010
New Revision: 158224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158224
Log:
PR bootstrap/43699
* c-typeck.c
--- Comment #13 from iains at gcc dot gnu dot org 2010-04-12 13:28 ---
Created an attachment (id=20364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20364action=view)
hack wrapper for dsymutil
This is a simple script that edits one specific warning out of the output from
--- Comment #36 from davek at gcc dot gnu dot org 2010-04-12 13:30 ---
(In reply to comment #35)
http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf
Thanks for the link, not just because it's full of intersting information,
but also because I now have a new candidate for
--- Comment #14 from iains at gcc dot gnu dot org 2010-04-12 13:36 ---
Created an attachment (id=20365)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20365action=view)
sort out some nits with config/{*,}/darwin*.h and hack in a solution for
dsymtuil
The dsymutils issue is not a
--- Comment #15 from iains at gcc dot gnu dot org 2010-04-12 13:39 ---
(In reply to comment #12)
GCC would ICE if the referenced DIE wasn't being output on:
gcc_assert (AT_ref (a)-die_offset);
in output_die.
thanks Jakub,
for now we need to work around this ..
(a) until dsymutils
--- Comment #7 from zsojka at seznam dot cz 2010-04-12 13:47 ---
Running check on gcc/g++ shows further miscompilations with
-fno-ira-share-spill-slots (as of r158131, x86_64-linux):
gcc.c-torture/execute/20021120-1.c FAILs with:
-O2 -fno-ira-share-spill-slots
or
-O1
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-04-12 14:12 ---
I don't get why you closed this bug. Anyways if you have a patch, post it to
gcc-patc...@.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mikpe at it dot uu dot se 2010-04-12 14:18 ---
Appears to have been fixed for 4.5 by r147566, see
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html. But that patch
doesn't change any ARM code so the issue may be still be latent in 4.5 unless
some other patch
--- Comment #9 from joseph dot h dot garvin at gmail dot com 2010-04-12
15:00 ---
(In reply to comment #8)
(In reply to comment #7)
the former points to an object which might change due to effects outside the
program, the latter implies that the smart pointer itself might change,
In -Os mode I see undefined references to _restgpr_* _savefpr_* and similar
functions.
Michael Matz sees libgcc.a not added to the linkline in this mode.
testcase:
g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c
/tmp/cc8oo25Z.o: In function `hello()':
hello.c:(.text+0x30): undefined
1 - 100 of 202 matches
Mail list logo
