On Mar 11, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
>> * Basile STARYNKEVITCH wrote on Tue, Mar 11, 2008 at 09:18:54PM CET:
>>> I would like to use this tool to compile some (generated)
>>> warm(basilys.c file into a warm-basilys.la in the most portable
>>> way (on Linux/ELF system
Alexandre Oliva wrote:
On Mar 11, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
* Basile STARYNKEVITCH wrote on Tue, Mar 11, 2008 at 09:18:54PM CET:
I would like to use this tool to compile some (generated)
warm-basilys.c file into a warm-basilys.la in the most portable
way (on Lin
Hello all,
Maybe I can add a few comments here. This is the way I see the RTL
within GCC. Details are at:
http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/
and in particular, I'd like to point to
http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/html/gcc-conceptual-structure.html.
(BTW, community fee
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for
Thanks to the GCC SC for accepting the picochip port.
Regards
Hari
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
accepted the picoChip port for inclusion in GCC and appointed
Hariharan Sandanagobalane and Daniel Towner as port maintainers.
The initi
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Actually, I just want to generate (during the build process in gcc/ subdir
> in build directory) a script (basilys-gcc) invoked by cc1 with two
> arguments :
>the full path of some C file to generate
>the stripped path (without .so or .sl
> On 3/9/08 7:26 AM, Jan Hubicka wrote:
>
> >compensate testsuite and documentation for the removal of RTL dump
> >letters so I would rather do that just once. Does this seem OK?
>
> Yup, thanks for doing this.
>
>
> >The patch include the read/write methods that will be just placeholders
> >o
Hi,
Currently, -B doesn't add the multilib search paths when processing
startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in
$prefix/lib/../lib64
Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes
do actually process the multilibs. Is there any good
> "Schmave" == Schmave <[EMAIL PROTECTED]> writes:
> i was wondering what steps i need to take to port gcc to a new
> architecture
Did you find something unclear in the GCC documentation? Do you have a
specific question?
Sam
--
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.ne
Andreas Schwab wrote:
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
Actually, I just want to generate (during the build process in gcc/ subdir
in build directory) a script (basilys-gcc) invoked by cc1 with two
arguments :
the full path of some C file to generate
the stripped path (with
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>> Why can't you generate it in a separate toplevel directory?
>
>
> I am not sure to understand what exactly you mean. Do you suggest to
> generate this script in the toplevel (top of gcc source directory)
> Makefile.tpl or do you suggest it to be
Hello all,
What is the exact intent of the update_path in gcc/prefix.[hc]?
I would guess it is related to the -B option to gcc driver executable.
But I'm not sure how exactly. I don't exactly understand what it means
to pass "GCC" (or "BINUTILS") as the key (2nd) argument to update_path.
On Wed, Mar 12, 2008 at 04:19, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Sure.
Thanks. Phasing out the 'tree' name is going to be a long process.
> Though gimplifier itself might end up being GIMPLE_PASS but it is
> not big deal I guess.
Both the gimplifier and the rtl expander will always ha
Hi,
Did the default i386 CPU model that gcc generates
code for change between 4.2.x and 4.3.0? I didn't
see anything in the release notes that jumps out at
me about this.
Using i386-rtems4.9 as the target, I was running
code compiled by gcc 4.3.0 on a vanilla i386 and
was getting illegal ins
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Did the default i386 CPU model that gcc generates
> code for change between 4.2.x and 4.3.0? I didn't
> see anything in the release notes that jumps out at
> me about this.
>
> Using i386-rtems4.9 as the targe
> Hi,
>
> Did the default i386 CPU model that gcc generates
> code for change between 4.2.x and 4.3.0? I didn't
> see anything in the release notes that jumps out at
> me about this.
There wasnt any intend to change the codebase. However the default
tunning now has changed to "generic" model.
Hello,
many people seem to be finding our git mirror of the GCC repo
useful:
http://git.infradead.org/toolchain/gcc.git
git://git.infradead.org/toolchain/gcc.git
Therefore, I'd like to advertise it on the GCC web site
as an alternative to the Subversion repository. If nobody
is opposed, I'll s
On Wed, Mar 12, 2008 at 04:06:52PM +0100, Basile STARYNKEVITCH wrote:
> Hello all,
>
>
> What is the exact intent of the update_path in gcc/prefix.[hc]?
Very complicated and underdocumented; I avoid it for that reason.
Can't you use an existing directory variable, like gcc_libexec_prefix?
--
Dan
Hi all,
The Fortran 2003 standard requires that Fortran compilers be able to
know, at compile-time, what size the various int_fastN_t types have
on the target (for N = 8, 16, 32 and 64). I've discussed that issue
before on this list, and was told it's a known issue, tracked as PR
448. For
Richard Guenther wrote:
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Hi,
Did the default i386 CPU model that gcc generates
code for change between 4.2.x and 4.3.0? I didn't
see anything in the release notes that jumps out at
me about this.
Using i386-rtems
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
>
> 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
>
> Is there any way to skip these tests for particular HW features
> that are not present? There are similar failures on the PowerPC
> target I use for repo
Daniel Jacobowitz wrote:
On Wed, Mar 12, 2008 at 04:06:52PM +0100, Basile STARYNKEVITCH wrote:
Hello all,
What is the exact intent of the update_path in gcc/prefix.[hc]?
Very complicated and underdocumented; I avoid it for that reason.
Can't you use an existing directory variable, like gcc_l
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote:
> On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
> <[EMAIL PROTECTED]> wrote:
>
> >
> > 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
> >
> > Is there any way to skip these tests for particular HW features
> > that are n
H.J. Lu wrote:
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote:
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
Is there any way to skip these tests for particular HW features
that are
> "Bernardo" == Bernardo Innocenti <[EMAIL PROTECTED]> writes:
Bernardo> If people think it would be useful, we could install a commit
Bernardo> hook on gcc.gnu.org to mirror each commit immediately.
It would be great!
Sam
--
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
> Since we are talking 100s of tests, it seems like it would be
> easiest to avoid them in the scripts. I just don't know how
> to do that.
You might want to look at how the ARM NEON vector unit is handled
(check_effective_target_arm_neon_ok and check_effective_target_arm_neon_hw).
Paul
Paul Brook wrote:
Since we are talking 100s of tests, it seems like it would be
easiest to avoid them in the scripts. I just don't know how
to do that.
You might want to look at how the ARM NEON vector unit is handled
(check_effective_target_arm_neon_ok and check_effective_target_arm_neon_
> Joel Sherrill writes:
Joel> If I understand this correctly, it is checking that the
Joel> target HW actually supports the Neon extension.
Joel> Is this right?
Joel> Where does this get invoked?
Joel> I think I am on the edge of understanding a solution
Joel> path. It sounds like I need to
On Mar 12, 2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> Actually, I just want to generate (during the build process in gcc/
> subdir in build directory) a script (basilys-gcc) invoked by cc1 with
> two arguments :
>the full path of some C file to generate
>the stripped path (wit
FX Coudert <[EMAIL PROTECTED]> writes:
> The Fortran 2003 standard requires that Fortran compilers be able to
> know, at compile-time, what size the various int_fastN_t types have
> on the target (for N = 8, 16, 32 and 64). I've discussed that issue
> before on this list, and was told it's a known
David Edelsohn wrote:
Joel Sherrill writes:
Joel> If I understand this correctly, it is checking that the
Joel> target HW actually supports the Neon extension.
Joel> Is this right?
Joel> Where does this get invoked?
Joel> I think I am on the edge of understanding a solution
Joel>
On Wed, 12 Mar 2008, FX Coudert wrote:
> I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on for 16, 32
> and 64): they would be defined to -1 in defaults.h (meaning that int_fastN_t
> types are not available), and independent targets can redefine them.
> Front-ends and the middle-
On Wednesday 12 March 2008, Joel Sherrill wrote:
> Paul Brook wrote:
> >> Since we are talking 100s of tests, it seems like it would be
> >> easiest to avoid them in the scripts. I just don't know how
> >> to do that.
> >
> > You might want to look at how the ARM NEON vector unit is handled
> > (ch
> Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_available again.
David
On Wed, 12 Mar 2008, Ian Lance Taylor wrote:
> I don't disagree with that, but I would also like to see something
> that will not require changing every target for basic default
> behaviour.
>
> I'd like to suggest that in the absence of other information from the
> tm.h file, for N in {8,16,32,6
I've created a new wiki page to track things we'd like to add/fix/remove
to the OpenMP implementation and related things like the auto
parallelizer (http://gcc.gnu.org/wiki/openmp)
I've linked the page to the Google SoC projects wiki page. If you have
anything that you'd been wanting to wor
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_availa
> Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel> Is this another category of tests to avoid somehow?
405-mullhw-1.c is i
> David Edelsohn wrote:
> >>Joel Sherrill writes:
> >>
> >
> >Joel> Those all look like checks to see if the compiler itself
> >Joel> supports Altivec -- not a run-time check on the hardware
> >Joel> like the Neon check_effective_target_arm_neon_hw appears
> >Joel> to be.
> >
>
On Wed, 12 Mar 2008, David Edelsohn wrote:
> > Joel Sherrill writes:
>
> Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
>
> Joel> Are those things which would be expected to fail on a vanilla
> Joel> 603e target without networking or disk?
>
> Joel> Is this another cate
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_availa
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel
Jan Hubicka wrote:
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Greg Schafer wrote:
The issue is now filed as
http://gcc.gnu.org/PR35532
It would be appreciated if the responsible Codesourcery folks could address
this regression.
I will definitely look into this. (I was on vacation last week and I've
been sick this week, so I haven't had a chance yet,
Snapshot gcc-4.2-20080312 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080312/
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
On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
> Manuel> The third approach would be to store an offset and when
> Manuel> generating diagnostics, reopen the file, fseek to the offset
> Manuel> and print that line.
>
> I
On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> Another approach would be to only use the carets for parse errors,
> which is where they are the most helpful. For a middle-end error like
> "assuming signed overflow does not occur when simplifying
> multiplication" a caret pointe
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> clang points into the original input buffer that was lexed from. This
> requires keeping the original files mapped into the address space of
> the compiler. However, clang only produces diagnostics from the front-
> end, not from the
On 08/03/2008, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Adding support for releasing large buffers from memory and either
> seeking or not displaying carrets if it turns out to be important on the
> top of the in-memory implementation seems straighforward: the line
> location would be anyway so
On 08/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
>
> Perhaps I was mistaken to state an implementation preference this
> early, anyway. It would be fine by me to have an implementation that
> works in any reasonable way. If the "don't free" approach proves too
> costly, with sane API desi
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>>
>> Another approach would be to only use the carets for parse errors,
>> which is where they are the most helpful. For a middle-end error like
>> "assuming signed overflow does not
On 13/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>
>
> > On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >>
> >> Another approach would be to only use the carets for parse errors,
> >> which is where they are the most h
On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
clang points into the original input buffer that was lexed from.
This
requires keeping the original files mapped into the address space of
the compiler. However, clang only pro
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
> >>
> >> clang points into the original input buffer that was lexed from.
> >> This
> >> requires keeping the orig
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace
former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>> >> Another approach would be to only use the carets for parse errors,
>> >> which is where they are the most helpful. For a middle-end error like
>> >> "assuming signed overflow does not occur when simplifying
>> >> multiplication" a ca
On Mar 12, 2008, at 9:49 PM, Manuel López-Ibáñez wrote:
The clang front-end generates these warnings. This means that the
set
of warnings produced by the compiler doesn't change as the optimizer
evolves, are generally less mystifying to the user, and have perfect
location info as a side effect
Liu Yu <[EMAIL PROTECTED]> writes:
> There are 2 bugs existing in __udiv_qrnnd_c:
>
> 1. remainder could not be counted correctly
> __r1 and __r0 are not adding enough, so I use do..while to replace former if
>
> 2. the case of overflow of __m are not considered
> so I add a couple of lines to han
Hi Ian,
Thanks a lot for your detailed explanation.
> -Original Message-
> From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 13, 2008 1:45 PM
> To: Liu Yu
> Cc: gcc@gcc.gnu.org
> Subject: Re: [PATCH] Fix bug on soft emulation of float point
> in gcc/longlong.c
>
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> There is no right answer, and this topic has been the subject of much
> debate on the GCC list in the past. I really don't care to debate the
> merits of one approach vs the other with you, I just answered your
> question about what cl
60 matches
Mail list logo
