On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
> Use -pedantic to warn about extensions. It doesn't make sense to
> warn for extensions if they are not deprecated. After all they are
> extensions.
The problem with -pedantic is that it gives lots of spurious warnings.
We have code that uses
On Tue, Jun 10, 2008 at 9:07 AM, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
>> Use -pedantic to warn about extensions. It doesn't make sense to
>> warn for extensions if they are not deprecated. After all they are
>> extensions.
>
> The proble
Sent from my iPhone
On Jun 10, 2008, at 11:45, Tim Prince <[EMAIL PROTECTED]>
wrote:
Vincent Lefevre wrote:
On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
Use -pedantic to warn about extensions. It doesn't make sense to
warn for extensions if they are not deprecated. After all th
Vincent Lefevre wrote:
On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
Use -pedantic to warn about extensions. It doesn't make sense to
warn for extensions if they are not deprecated. After all they are
extensions.
The problem with -pedantic is that it gives lots of spurious warn
On Mon, Jun 09, 2008 at 04:40:54PM +0200, Jan Hubicka wrote:
> Still it seems to me that we can use extend current eax convention.
> Currently the value must be in range 0...8 as it specify number of SSE
> registers. We can pack both numbers into it. This way we get
> unforutnately wild jump on c
>
> I don't understand why you want to pass __m256 and 256-bit vector values
> to anonymous arguments in registers. The only thing the vararg functions
> would do with it would be save it somewhere on the stack.
> Given the x86_64 ABI, you can't expect calling an implicitly
> prototyped or non-va
On Tue, 10 Jun 2008, Vincent Lefevre wrote:
> On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
> > Use -pedantic to warn about extensions. It doesn't make sense to
> > warn for extensions if they are not deprecated. After all they are
> > extensions.
>
> The problem with -pedantic is that it
Hello!
> I'm making some modifications to exception handling inside of
> unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for,
> unfortunately I can't seem to figure out how to
> correctly use builtins in the context of libgcc.
> I've tried a bunch of different things, but I c
On Tue, 10 Jun 2008, Paolo Carlini wrote:
> Luke Dalessandro wrote:
> > I'm making some modifications to exception handling inside of
> > unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for,
> > unfortunately I can't seem to figure out how to correctly use builtins in
> > the co
Hi,
While writing some testcases for the call abi switching for x86_64<->w64 I
came to the point, that it would be may good to add the builtin types and
functions for the different calling abi, too.
For the target default abi it would be
Index: gcc/gcc/testsuite/gcc.dg/callabi/callabi.h
==
On 2008-06-10 11:26:32 +0200, Richard Guenther wrote:
> On Tue, Jun 10, 2008 at 9:07 AM, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > On 2008-06-09 16:02:05 +0200, Richard Guenther wrote:
> >> Use -pedantic to warn about extensions. It doesn't make sense to
> >> warn for extensions if they are no
On 2008-06-10 06:45:43 -0400, Tim Prince wrote:
> long long is an extension, if you don't specify -std=c99.
I know that. But I can't use -std=c99 because it doesn't work with
old gcc versions.
> You ask for warnings about extensions, you get them.
No, I'm not asking warnings about extensions. I'
Vincent Lefevre wrote:
On 2008-06-10 06:45:43 -0400, Tim Prince wrote:
long long is an extension, if you don't specify -std=c99.
I know that. But I can't use -std=c99 because it doesn't work with
old gcc versions.
You ask for warnings about extensions, you get them.
No, I'm not asking warn
On Tue, Jun 10, 2008 at 02:29:24PM +0200, Vincent Lefevre wrote:
> On 2008-06-10 06:45:43 -0400, Tim Prince wrote:
> > long long is an extension, if you don't specify -std=c99.
>
> I know that. But I can't use -std=c99 because it doesn't work with
> old gcc versions.
It works with old, even very
On 2008-06-10 11:43:11 +, Joseph S. Myers wrote:
> For this particular extension, you can use the more specific warning
> -Wpointer-arith.
I've added that to the default options for gcc in MPFR's configure.in.
I've seen it works with gcc 2.95.2 (which is AFAIK the latest gcc for
a non-reflash
On 2008-06-10 08:40:40 -0400, Robert Dewar wrote:
> Clearly if everyone agreed that an extension was useless it would
> not be there, so this argument makes no sense to me.
Any example?
BTW, there should still be the possibility to use __extension__ to
avoid the warning.
--
Vincent Lefèvre <[EM
> From: "Ian Lance Taylor" <[EMAIL PROTECTED]>
> >Use CONST_CAST_RTX where necessary.
I think sprinkling const qualifiers liberally over the code and then
casting them away whenever they get in the way is worse than having
no const qualifiers in the first place. It adds extra text to the code
whi
On 2008-06-10 15:00:32 +0200, Jakub Jelinek wrote:
> It works with old, even very old gcc versions. Only doesn't work with
> prehistoric ones. Already GCC 3.0 and even 2.96-RH supported -std=c99.
I remember having problems with gcc 3.x and -std=c99 because the
C library was too old.
Also, I thi
On Tue, Jun 10, 2008 at 4:32 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>>
>> I don't understand why you want to pass __m256 and 256-bit vector values
>> to anonymous arguments in registers. The only thing the vararg functions
>> would do with it would be save it somewhere on the stack.
>> Given t
Joseph S. Myers wrote:
I hold that it is a bug that i686-* tools default to -march=i386 instead
of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
-mcpu means -march for SPARC).
Seconded.
Paolo.
On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
> Joseph S. Myers wrote:
>> I hold that it is a bug that i686-* tools default to -march=i386 instead
>> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
>> -mcpu means -march for SPARC).
> Seconded.
>
What a
On Tue, 10 Jun 2008, H.J. Lu wrote:
> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
> > Joseph S. Myers wrote:
> >> I hold that it is a bug that i686-* tools default to -march=i386 instead
> >> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
> >> -mcpu
Joern Rennecke <[EMAIL PROTECTED]> writes:
> Having another copy of note_stores seems simpler and is certainly
> more portable.
> What do you think about the name walk_stores?
Following this approach strictly leads to considerable code
duplication, which makes people unhappy. If you want to make
On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
> 1) make __m256 passed on stack on variadic functions and in registers
> otherwse. Then we don't need to worry about varargs changes at all.
> This will break unprototyped calls.
> 2) extend rax to pass info about if __m256 registers
> On Tue, Jun 10, 2008 at 4:32 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >>
> >> I don't understand why you want to pass __m256 and 256-bit vector values
> >> to anonymous arguments in registers. The only thing the vararg functions
> >> would do with it would be save it somewhere on the stack.
H.J. Lu wrote:
> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
>> Joseph S. Myers wrote:
>>> I hold that it is a bug that i686-* tools default to -march=i386 instead
>>> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
>>> -mcpu means -march for SPARC).
On Tue, Jun 10, 2008 at 7:42 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jun 2008, H.J. Lu wrote:
>
>> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
>> > Joseph S. Myers wrote:
>> >> I hold that it is a bug that i686-* tools default to -march=i386 instead
>> >> of -
On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
>> 1) make __m256 passed on stack on variadic functions and in registers
>> otherwse. Then we don't need to worry about varargs changes at all.
>> This will br
> On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
> >> 1) make __m256 passed on stack on variadic functions and in registers
> >> otherwse. Then we don't need to worry about varargs changes at all.
> >> Th
I'm forwarding this to the generic GCC development list, as more
people might be of help there (including the darwin maintainers), as
it's more of a darwin and build system issue.
FX
Début du message réexpédié :
De : IainS <[EMAIL PROTECTED]>
Date : 10 juin 2008 16:50:11 GMT+01:00
À : For
The link the the GCC 4.3 release notes to the TR1 implementation
status page is dead.
Also, the parallel mode page is somewhat unclear as to exactly _how_
to substitute the parallel algorithms "on a piecemeal basis."
-James Brown
The solution is to name the libs differently (as is done elsewhere
in gcc).
Target libraries named differently? Which? libssp has three variants,
which I don't really understand :)
$ ls libssp*
libssp.0.dylib libssp.dyliblibssp_nonshared.a
libssp.alibssp.la
On Tue, Jun 10, 2008 at 8:48 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>> > On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
>> >> 1) make __m256 passed on stack on variadic functions and in registers
>> >>
Paolo Carlini wrote:
Joseph S. Myers wrote:
I hold that it is a bug that i686-* tools default to -march=i386
instead of -march=i686 (whereas e.g. sparcv9-* tools default to
-mcpu=sparcv9, and -mcpu means -march for SPARC).
>
Seconded.
I've long been of the opinion that -march=native should
On 10 Jun 2008, at 17:11, FX wrote:
I opted to call the static library "libgfortran_static" and to
leave the shared name unchanged.
I'd suggest "-static" instead of using an underscore, to follow
libstdc++, but that's a minor point.
A minor point maybe, but, as you say, there seem to be
FX wrote on 10 June 2008 17:12:
>> The solution is to name the libs differently (as is done elsewhere
>> in gcc).
>
> Target libraries named differently? Which?
Just frex: When you build static libgcc, you get libgcc.a
When you build it shared, you get libgcc_s.so (and a static libgcc_eh.
On Tue, 10 Jun 2008, Joern Rennecke wrote:
> > From: "Ian Lance Taylor" <[EMAIL PROTECTED]>
> > >Use CONST_CAST_RTX where necessary.
>
> On Mon, Jun 09, 2008 at 04:45:14PM -0700, Kaveh R. Ghazi wrote:
> > Or pass in a struct pointer to the "data" parameter containing both your
> > hash table and t
Hi, GCC list!
Apologies if this isn't the right place to ask, but it seems like a good
place to find experts on C++ and Java syntax. If there's a better place
to ask, would somebody give me a pointer, please.
I'm the maintainer of Emacs's CC Mode, which includes modes for C, C++,
Java, etc.
Cur
On Tue, Jun 10, 2008 at 01:44:08PM -0400, Kaveh R. GHAZI wrote:
> I don't understand the point about the asm.
I need to modify the SET_SRC of the individual SETs presented by
note_stores. The caller of note_stores can't pass in the SET RTXes,
since they vary for each call of the callback function
On Tue, Jun 10, 2008 at 8:22 PM, Joern Rennecke <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 01:44:08PM -0400, Kaveh R. GHAZI wrote:
>> I don't understand the point about the asm.
>
> I need to modify the SET_SRC of the individual SETs presented by
> note_stores. The caller of note_stores
You are right that our current proposal/implementation doesn't handle
indirect function calls. (And we didn't try to do any pointer/alias
analysis for variables either in our first implementation .) But the
analysis will not be disabled completely if it encounters an indirect
function call. It simp
Alan Mackenzie <[EMAIL PROTECTED]> writes:
> I'm thinking of things like
>
> foo (a < b, c > d);
>
> I think this is unambiguously a function call with 2 parameters, the
> expressions "a < b" and "c > d". It cannot be be one with 1 parameter
> beginning with the template invocation "a < b , c
On Tue, Jun 10, 2008 at 08:27:43PM +0200, Steven Bosscher wrote:
> Actually, hold on a second please. You're only talking in terms of
> solutions. But what *exactly* are you trying to do? You ave to
> modify the SET_SRC of some SETs. What do these SET_SRCs look like?
> This is important, becaus
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Alan Mackenzie <[EMAIL PROTECTED]> writes:
>
>> I'm thinking of things like
>>
>> foo (a < b, c > d);
>>
>> I think this is unambiguously a function call with 2 parameters, the
>> expressions "a < b" and "c > d". It cannot be be one with 1 parame
Hello,
* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
>> De : IainS <[EMAIL PROTECTED]>
>>
>> I opted to call the static library "libgfortran_static" and to leave
>> the shared name unchanged.
>>
>> It would be great if libtool could be persuaded to change the basename
>> as well as the ext
On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
Hello,
* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
De : IainS <[EMAIL PROTECTED]>
I opted to call the static library "libgfortran_static" and to leave
the shared name unchanged.
It would be great if libtool could be persuaded to chang
* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
> On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
>
>> Can the driver use path/to/libgfortran.a instead of '-Lpath/to
>> -lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?
>
> this doesn't appear to work. [I've unset DYLD_LIBRA
We're getting a bit off-list; if this loses connection to GCC we may
want to move to [EMAIL PROTECTED]
* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
> On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
>>
>> It doesn't do that because that breaks the abstraction. It might also
>> increase
On 10 Jun 2008, at 20:58, Ralf Wildenhues wrote:
* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?
this do
Hi,
In the process of fixing tests for AVR and other small targets I have
come across issues with profile
tests in gcc/dg/struct that affect all targets and I would like reviewed
so I can raise patches to rectify them correctly.
Both involve random creating structures then setting and checkin
Ralf Wildenhues wrote:
>>> Independently, does anybody know whether odcctools is dead (homepage
>>> seems to be down ATM)?
odcctools is currently seeking a maintainer.
Peter
--
Peter O'Gorman
http://pogma.com
Hi all,
Yes, Sebastian is Right for now, and thanks for pointing out the references.
Yet in the longer term, we are working on CLooG extensions to facilitate
tiling with parametric sizes, multidomensional tiling, increased
scalability, no risks of integer overflows, and better quality of
generate
I started to write the following message two days ago but I wished to
send a .cloog which is not easy since I changed my laptop just before
the trip I'm still on ! I need to finish installing all the tools...
Here is the message, just a follow-up of Albert's one.
Ced.
---
Hi Tobi,
Sebastian gave
53 matches
Mail list logo
