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 I
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> On 12 April 2010 00:38, Dave Korn 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 pl
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 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 wrote:
>> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
>> >
>> >> [ ... ] lack of test results in some platforms does not mean
>> >
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
> On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth
> 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 wrote:
> >> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
On 12/04/2010 07:47, Manuel López-Ibáñez wrote:
> On 12 April 2010 00:38, Dave Korn 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
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
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: gcc.target/i386/sse-1
On 12 April 2010 16:18, Dave Korn 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. You
probably do well for you
On 04/12/2010 09:05 AM, Richard Guenther wrote:
On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill
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/msg
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
wrote:
> On 04/12/2010 09:05 AM, Richard Guenther wrote:
>>
>> On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I was testing i386-rtems4.10 and 225
>>> tests failed on the target because it
>>> does not have any SSE f
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 to
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 mo
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
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth 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 we can use t
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote:
> On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth
> 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,
> >
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 to the existing "LTO doesn't work on non-E
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 "pur
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
ali
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 of
> "Rodolfo" == Rodolfo Lima 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 patch is still
On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter 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 the merged insn. I
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 g
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
versio
> -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
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
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 mem
On 04/09/2010 03:16 PM, Jonathan Wakely wrote:
Is the only C++ header that causes a problem?
is exactly equivalent to because it only declares
macros, which are not in namespace std anyway.
So if that's the only problem, using instead of
would solve it.
No, we also use , so avoiding the
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 fair
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 thorou
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 c
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
LINK_COMMAND_SPEC
On Mon, Apr 12, 2010 at 7:38 PM, Mat Hostetter 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 actual destructive m
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
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)
> +++ tree-ssa-loop-ivo
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
to
> 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 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 |) ;
That sounds ri
IainS 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 modify in the mechanics to arrang
On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:
IainS 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
"Weddington, Eric" 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, what I would call,
>
On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote:
IainS writes:
If I want to install a script (wrapper) that will end up installed in
the same dir as
. If this program will only ever be
run by the gcc driver, then you should install it in either the
directory where cc1 is installed, $(li
IainS 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"
> %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{
IainS 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 currently no post-collect phase
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
IainS 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 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 p
52 matches
Mail list logo
