On 07/03/2009 07:31 AM, Eric Botcazou wrote:
This was pretty bad, but it was also unlucky that the failure was only
on the exact arch that the tester builds for. Failures on powerpc are
extremely annoying, failures on SPARC will go (almost) unnoticed.
Not clear what you mean about SPARC. The
> This was pretty bad, but it was also unlucky that the failure was only
> on the exact arch that the tester builds for. Failures on powerpc are
> extremely annoying, failures on SPARC will go (almost) unnoticed.
Not clear what you mean about SPARC. The recent multiple SPARC breakages had
been
On Jul 2, 2009, at 16:44, Michael Meissner wrote:
Anyway I had some time during the summit, and I decided to see how
hard it
would be to add explicit big/little endian support to the powerpc
port. It
only took a few hours to add the support for __little and __big
qualifier
keywords, and in
Snapshot gcc-4.5-20090702 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090702/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Jeff Law wrote:
Vladimir Makarov wrote:
Dave Korn wrote:
In a brief exchange I had with Michael off-list, we discussed
that. I
observed that of the things that reload does,
constraint-satisfaction/insn-variant-selection is its primary
purpose, and
spill/reload code generation is something
> You could file this in Bugzilla instead, with all required fields
> filled in (host, target, compiler revision number, etc), and test
> cases as text attachments ;-)
Ok. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
Hi DJ,
You could file this in Bugzilla instead, with all required fields
filled in (host, target, compiler revision number, etc), and test
cases as text attachments ;-)
Ciao!
Steven
On Thu, Jul 2, 2009 at 11:30 PM, DJ Delorie wrote:
>
> When compiled with -frename-registers, this test case pro
When compiled with -frename-registers, this test case produces invalid
code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h
assumes it still has the value "a" in it. Compiling with
-fno-rename-registers results in valid code.
I've attached the full testcase and before/after dum
> The powerpc tester won't do a run more often than once every 15
> minutes
Well, if the failure is in libgcc, that means that we get a mail on
every commit. In this case my patch went in on Sunday afternoon, and
the problems were fixed only on Thursday for multiple reasons (multiple
patches
On Jul 2, 2009, at 2:35 AM, Richard Guenther
wrote:
On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres> wrote:
In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
Arnaud Charlet wrote:
Can someone please fix or disable these runs? They are getting very
irritating.
What I find e
On Thu, Jul 02, 2009 at 12:02:29PM +0200, Paul Chavent wrote:
> Hi.
>
> I already have posted about the endianess attribute
> (http://gcc.gnu.org/ml/gcc/2008-11/threads.html#00146).
>
> For some year, i really need this feature on c projects.
>
> Today i would like to go inside the internals of
Mohamed Shafi writes:
> I just want to know about the feasibility of implementing an
> instruction for a port in gcc 4.4
> The target has 40 bit register where the normal load/store/move
> instructions will be able to access the 32 bits of the register. In
> order to move data into the rest of th
David Edelsohn wrote:
> > .csect .data[RW],4
> > ^^^
> > .align 6
> > ^^^
> > a2661:
> > .space 10240
>
> The default alignment of CSECTs is 4, but using -fdata-sections should
> place the object in its own CSECT with stricter alignment.
H
Sent from my iPhone
On Jul 2, 2009, at 4:18 AM, Paolo Bonzini wrote:
On 07/02/2009 12:06 PM, Dominique Dhumieres wrote:
Andrew Haley wrote
Is this really a good idea? Surely the solution is to fix the
failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failur
On Thu, Jul 2, 2009 at 3:46 PM, Andrew Stubbs wrote:
> On 02/07/09 14:34, Richard Guenther wrote:
>>
>> No, that's invalid. You would have to do
>>
>> extern union {
>> void *foo;
>> short *bar;
>> };
>>
>> using the union for the double-indirect pointer doesn't help. Or
>> simply use memcpy
Andrew Stubbs wrote:
> On 02/07/09 14:34, Richard Guenther wrote:
>> No, that's invalid. You would have to do
>>
>> extern union {
>>void *foo;
>>short *bar;
>> };
>>
>> using the union for the double-indirect pointer doesn't help. Or
>> simply use memcpy to store to foo.
>
> Ah, I did n
On 02/07/09 14:34, Richard Guenther wrote:
No, that's invalid. You would have to do
extern union {
void *foo;
short *bar;
};
using the union for the double-indirect pointer doesn't help. Or
simply use memcpy to store to foo.
Ah, I did not know that. I still don't understand how a refe
On 07/02/2009 03:09 PM, Dominique Dhumieres wrote:
Note that revision 149171 not only breaks powerpc-apple-darwin9.7.0
but now also i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00114.html).
I don't see any of the new failures reported in that message.
Paolo
On Jul 2, 2009, at 06:02, Paul Chavent wrote:
Hi.
I already have posted about the endianess attribute (http://gcc.gnu.org/ml/gcc/2008-11/threads.html#00146
).
For some year, i really need this feature on c projects.
Today i would like to go inside the internals of gcc, and i would
like to
On Thu, Jul 2, 2009 at 3:29 PM, Andrew Stubbs wrote:
> On 02/07/09 14:26, Richard Guenther wrote:
>>
>> You are writing to memory of type void * via an lvalue of type short *.
>
> Yes, there is type punning there, but that should work, shouldn't it?
No, that's invalid. You would have to do
exter
On 02/07/09 14:26, Richard Guenther wrote:
You are writing to memory of type void * via an lvalue of type short *.
Yes, there is type punning there, but that should work, shouldn't it?
This code is distilled from some glibc code I'm having trouble with.
Andrew
On Thu, Jul 2, 2009 at 3:21 PM, Andrew Stubbs wrote:
> Hi all,
>
> I'm fairly sure I have found an aliasing bug in GCC, although I could be
> wrong. I've reproduced it in both 4.4 and mainline.
>
> Consider this testcase, aliasing.c:
>
> extern void *foo;
>
> extern inline short **
> f1 (v
Hi all,
I'm fairly sure I have found an aliasing bug in GCC, although I could be
wrong. I've reproduced it in both 4.4 and mainline.
Consider this testcase, aliasing.c:
extern void *foo;
extern inline short **
f1 (void)
{
union
{
void **v;
sh
Note that revision 149171 not only breaks powerpc-apple-darwin9.7.0
but now also i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00114.html).
Dominique
Good day!
We`d like to use a compiler gcc to compile our application. I know that gcc
exists under special exception which allows to use it for commercial
application.
I have 2 questions:
If we use a static linking with gcc - should we distribute our application on
the terms of GPL? or ca
Hi Gnu,
Thank you for great OSS project. I would like to make donation for you.
Could you please place my text link on your homepage
(http://gcc.gnu.org/java/). It would link to my software downloads
website, anchor text "Software Download".
Please let me know.
Regards,
Martin
Hi Gnu,
Thank you for great OSS project. I would like to make donation for you.
Could you please place my text link on your homepage
(http://gcc.gnu.org/). It would link to my software downloads website,
anchor text "Software Download".
Please let me know.
Regards,
Martin
On Thu, Jul 2, 2009 at 12:02 PM, Daniel Franke wrote:
>
> Dear all,
>
> some Fortran77 code I inherited gives wrong results if compiled
> with '-ffast-math', especially with '-ffinite-math-only' enabled
> ('-ffast-math -fno-finite-math-only' seems to work).
>
> As '-ffinite-math-only' does "Allow o
On 07/02/2009 12:06 PM, Dominique Dhumieres wrote:
Andrew Haley wrote
Is this really a good idea? Surely the solution is to fix the
failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failure
was Darwin specific and is now fixed, two others are powerpc ones.
When t
Andrew Haley wrote
> Is this really a good idea? Surely the solution is to fix the
> failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failure
was Darwin specific and is now fixed, two others are powerpc ones.
When they will be fixed on trunk the annoying mails will
Dear all,
some Fortran77 code I inherited gives wrong results if compiled
with '-ffast-math', especially with '-ffinite-math-only' enabled
('-ffast-math -fno-finite-math-only' seems to work).
As '-ffinite-math-only' does "Allow optimizations for floating-point
arithmetic that assume that argu
Hi.
I already have posted about the endianess attribute
(http://gcc.gnu.org/ml/gcc/2008-11/threads.html#00146).
For some year, i really need this feature on c projects.
Today i would like to go inside the internals of gcc, and i would like to
implement this feature as an exercise.
You alread
On Thu, Jul 2, 2009 at 2:41 AM, Andrew Pinski wrote:
> On Thu, Jul 2, 2009 at 2:35 AM, Richard
> Guenther wrote:
>> But yes, Geoff - can you adjust the regression mails to not blame
>> people for build failures that persist for some time?
>
> except it was three different failures; two have been fi
On Thu, Jul 2, 2009 at 2:35 AM, Richard
Guenther wrote:
> But yes, Geoff - can you adjust the regression mails to not blame
> people for build failures that persist for some time?
except it was three different failures; two have been fixed and the
last one has been approved.
--Pinski
Richard Guenther wrote:
> On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres
> wrote:
>> In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
>> Arnaud Charlet wrote:
>>> Can someone please fix or disable these runs? They are getting very
>>> irritating.
>> What I find extremely irritat
On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres wrote:
> In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
> Arnaud Charlet wrote:
>> Can someone please fix or disable these runs? They are getting very
>> irritating.
>
> What I find extremely irritating is that it takes so long to
In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
Arnaud Charlet wrote:
> Can someone please fix or disable these runs? They are getting very
> irritating.
What I find extremely irritating is that it takes so long to
fix bootstrap failures. Meanwhile I hope to see such mails
until the
37 matches
Mail list logo
