Re: Re: GCC build failure, h...@149166 on native
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 problem(s) is (are) fixed. Dominique
Re: Re: GCC build failure, h...@149166 on native
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 > fix bootstrap failures. Meanwhile I hope to see such mails > until the problem(s) is (are) fixed. Well, I suppose "native" is *-darwin which then boils down to the fact that this is not a freely available host operating system and the respective maintainers of that target/host combination seem to not care. But yes, Geoff - can you adjust the regression mails to not blame people for build failures that persist for some time? Thanks, Richard. > Dominique >
Re: GCC build failure, h...@149166 on native
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 irritating is that it takes so long to >> fix bootstrap failures. Meanwhile I hope to see such mails >> until the problem(s) is (are) fixed. > > Well, I suppose "native" is *-darwin which then boils down to the fact > that this is not a freely available host operating system and the > respective maintainers of that target/host combination seem to not > care. > > But yes, Geoff - can you adjust the regression mails to not blame > people for build failures that persist for some time? Is this really a good idea? Surely the solution is to fix the failures on Darwin. Andrew.
Re: Re: GCC build failure, h...@149166 on native
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
Re: Re: GCC build failure, h...@149166 on native
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 fixed and the > last one has been approved. oh and two effected powerpc-linux too including the current one ... --Pinski
Endianess attribute
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 already prevent me that it would be a hard task (aliasing, etc.), but i
would like to begin with basic specs.
The spec could be :
- add an attribute (this description could change to be compatible with
existing ones (diabdata for example))
__attribute__ ((endian("big")))
__attribute__ ((endian("lil")))
- this attribute only apply to ints
- this attribute only apply to variables declaration
- a pointer to this variable don't inherit the attribute (this behavior could
change later, i don't know...)
- the test case is
uint32_t x __attribute__ ((endian("big")));
uint32_t * ptr_x = x;
x = 0xDEADBEEF
if(plf_is_little)
{
assert((*ptr_x == 0xEFBEADDE));
}
else if(plf_is_big)
{
assert((*ptr_x == 0xDEADBEEF));
}
My first work is the patch below.
So my questions to the mailing list are :
- is it a good starting point ?
- how can i get the endianess of the target ?
Thank for your help and suggestion.
8<
diff -abBruN gcc-4.4.0.orig/gcc/c-common.c gcc-4.4.0.mod/gcc/c-common.c
--- gcc-4.4.0.orig/gcc/c-common.c 2009-03-30 19:42:27.0 +0200
+++ gcc-4.4.0.mod/gcc/c-common.c2009-07-02 11:10:28.0 +0200
@@ -522,6 +522,7 @@
static bool check_case_bounds (tree, tree, tree *, tree *);
static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
+static tree handle_endian_attribute (tree *, tree, tree, int, bool *);
static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
static tree handle_common_attribute (tree *, tree, tree, int, bool *);
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
@@ -761,6 +762,8 @@
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
{ "packed", 0, 0, false, false, false,
handle_packed_attribute },
+ { "endian", 1, 1, false, false, false,
+ handle_endian_attribute },
{ "nocommon", 0, 0, true, false, false,
handle_nocommon_attribute },
{ "common", 0, 0, true, false, false,
@@ -5155,6 +5158,58 @@
return NULL_TREE;
}
+/* Handle an "endian" attribute; arguments as in
+ struct attribute_spec.handler.
+ IDENTIFIER_POINTER (name) gives "endian"
+ TREE_CODE (arg) should be a STRING_CST
+*/
+
+static tree
+handle_endian_attribute (tree *node, tree name, tree args,
+int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ tree arg = TREE_VALUE (args);
+
+ if (TREE_CODE (arg) != STRING_CST)
+{
+ error ("argument of %qE attribute should be a string\n", name);
+}
+ else if (TREE_CODE (*node) != FIELD_DECL &&
+ TREE_CODE (*node) != VAR_DECL &&
+ TREE_CODE (*node) != TYPE_DECL)
+{
+ error ("%qE only support FIELD_DECL, VAR_DECL and TYPE_DECL\n", name);
+}
+ else
+{
+ if (!strcmp (TREE_STRING_POINTER (arg), "little"))
+{
+ if(TARGET_BIG_ENDIAN)
+{
+ DECL_SWAP(*node) = 1;
+ debug_tree(*node);
+}
+}
+ else if (!strcmp (TREE_STRING_POINTER (arg), "big"))
+{
+ if(TARGET_LITTLE_ENDIAN)
+{
+ DECL_SWAP(*node) = 1;
+ debug_tree(*node);
+}
+}
+ else
+{
+ error ("argument of %qE attribute should be 'little' or 'big'\n",
name);
+ *no_add_attrs = true;
+}
+}
+
+ *no_add_attrs = true;
+
+ return NULL_TREE;
+}
+
/* Handle a "nocommon" attribute; arguments as in
struct attribute_spec.handler. */
diff -abBruN gcc-4.4.0.orig/gcc/tree.h gcc-4.4.0.mod/gcc/tree.h
--- gcc-4.4.0.orig/gcc/tree.h 2009-03-23 17:29:33.0 +0100
+++ gcc-4.4.0.mod/gcc/tree.h2009-07-02 11:10:28.0 +0200
@@ -2721,13 +2721,15 @@
/* In FIELD_DECL, this is DECL_NONADDRESSABLE_P
In VAR_DECL and PARM_DECL, this is DECL_HAS_VALUE_EXPR. */
unsigned decl_flag_3 : 1;
+ /* In FIELD_DECL, VAR_DECL and TYPE_DECL this is DECL_SWAP. */
+ unsigned decl_flag_4 : 1;
/* Logically, these two would go in a theoretical base shared by var and
parm decl. */
unsigned gimple_reg_flag : 1;
/* In a DECL with pointer type, set if no TBAA should be done. */
unsigned no_tbaa_flag : 1;
/* Padding so that 'align' can be on a 32-bit boundary. */
- unsigned decl_common_unused : 2;
+ unsigned decl_common_unused : 1;
unsigned int align : 24;
/* DECL_OFFSET_ALIGN, used only for FIELD_DECLs. */
@@ -2854,6 +2856,10 @@
#define DECL_NONADDRESSABLE_P(NODE) \
-f[no-]finite-math-only
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 arguments and results are not NaNs or +-Infs", it
is to assume that the code uses either or both. If so, it's very likely that
this was not intended by the original author.
Any pointers on how to track down these issues in ~25kloc of Fortran77 to
double check what's going on?
Thanks
Daniel
P.S. Not using '-ffast-math' would of course be an option, but knowing that
there might be something fishy going on with NaN/Inf does not improve the
confidence in the application's results ...
Re: Re: GCC build failure, h...@149166 on native
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 automatically disappear. Dominique
Re: GCC build failure, h...@149166 on native
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 they will be fixed on trunk the annoying mails will automatically disappear. However, this does not mean that tuning the regression tester to not sending more than 6 emails a day (one every 4 hours) would be a bad idea. Paolo
Re: -f[no-]finite-math-only
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 optimizations for floating-point
> arithmetic that assume that arguments and results are not NaNs or +-Infs", it
> is to assume that the code uses either or both. If so, it's very likely that
> this was not intended by the original author.
>
> Any pointers on how to track down these issues in ~25kloc of Fortran77 to
> double check what's going on?
The code is likely using isinf/isnan intrinsics (if such exist) or
comparisons like x != x which check for NaN. Those are optimized
away with -ffinite-math-only.
Richard.
> Thanks
>
>
> Daniel
>
>
> P.S. Not using '-ffast-math' would of course be an option, but knowing that
> there might be something fishy going on with NaN/Inf does not improve the
> confidence in the application's results ...
>
Donate for text link
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
Donate for text link
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
question about gcc compiler
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 can we distribute our application under the terms of our license? Thank you beforehand! Best regards
Re: GCC build failure, h...@149166 on native
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
Aliasing bug
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;
short **s;
} u;
u.v = (&foo);
if (*u.s == 0) *u.s = (short *)42;
return u.s;
}
const short *a, *b;
int
f ()
{
a = *f1();
b = *f1();
}
The (not very useful) testcase initialises foo to 42, if necessary, and
then sets both 'a' and 'b' to equal foo. There should be no way that 'a'
and 'b' can ever be set to zero.
Compile the code as follows:
sh-linux-gnu-gcc -c aliasing.c -O2 -fdump-tree-all
The dump file aliasing.c.133t.optimized (the last tree dump) then contains:
f ()
{
void * foo.3;
short int * D.1982;
short int * * D.1973;
:
foo.3_10 = foo;
D.1982_26 = (short int *) foo.3_10;
if (D.1982_26 == 0B)
goto ;
else
goto ;
:
D.1973_13 = (short int * *) &foo;
*D.1973_13 = 42B;
a = 0B;
:
b = D.1982_26;
return;
:
a = D.1982_26;
goto ;
}
This is the state of the code after the tree optimisations. Both 'a' and
'b' are set to the initial value of foo, before it was initialised. Not
only that, but 'a' is explicitly set to zero.
This problem goes away if -fno-strict-aliasing is used.
Is this a compiler bug? Or have I got something wrong in my code?
Thanks
Andrew
Re: Aliasing bug
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 (void)
> {
> union
> {
> void **v;
> short **s;
> } u;
>
> u.v = (&foo);
> if (*u.s == 0) *u.s = (short *)42;
> return u.s;
> }
>
> const short *a, *b;
>
> int
> f ()
> {
> a = *f1();
> b = *f1();
> }
>
> The (not very useful) testcase initialises foo to 42, if necessary, and then
> sets both 'a' and 'b' to equal foo. There should be no way that 'a' and 'b'
> can ever be set to zero.
>
> Compile the code as follows:
>
> sh-linux-gnu-gcc -c aliasing.c -O2 -fdump-tree-all
>
> The dump file aliasing.c.133t.optimized (the last tree dump) then contains:
>
> f ()
> {
> void * foo.3;
> short int * D.1982;
> short int * * D.1973;
>
> :
> foo.3_10 = foo;
> D.1982_26 = (short int *) foo.3_10;
> if (D.1982_26 == 0B)
> goto ;
> else
> goto ;
>
> :
> D.1973_13 = (short int * *) &foo;
> *D.1973_13 = 42B;
> a = 0B;
>
> :
> b = D.1982_26;
> return;
>
> :
> a = D.1982_26;
> goto ;
>
> }
>
> This is the state of the code after the tree optimisations. Both 'a' and 'b'
> are set to the initial value of foo, before it was initialised. Not only
> that, but 'a' is explicitly set to zero.
>
> This problem goes away if -fno-strict-aliasing is used.
>
> Is this a compiler bug? Or have I got something wrong in my code?
You are writing to memory of type void * via an lvalue of type short *.
Richard.
> Thanks
>
> Andrew
>
Re: Aliasing bug
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
Re: Aliasing bug
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
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.
Richard.
Re: Endianess attribute
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 implement this feature as an exercise.
You already prevent me that it would be a hard task (aliasing,
etc.), but i would like to begin with basic specs.
As another gcc user (and, once upon a time, developer) who's had to
deal with occasional byte ordering issues (mainly in network
protocols), I can imagine some uses for something like this. But...
The spec could be :
- add an attribute (this description could change to be compatible
with existing ones (diabdata for example))
__attribute__ ((endian("big")))
__attribute__ ((endian("lil")))
I would use "little" spelled out, rather than trying to use some cute
abbreviation. Whether it should be a string vs a C token like little
or __little__, I don't know, or particularly care.
- this attribute only apply to ints
It should at least be any integral type -- short to long long or
whatever TImode is. (Technically maybe char/QImode could be allowed
but it wouldn't have any effect on code generation.) I wouldn't jump
to the conclusion that it would be useless for pointers or floating
point values, but I don't know what the use cases for those would be
like. However, I think that's a case where you could limit the
implementation initially, then expand the support later if needed,
unlike the pointer issue below.
- this attribute only apply to variables declaration
- a pointer to this variable don't inherit the attribute (this
behavior could change later, i don't know...)
This seems like a poor idea -- for one thing, my use cases would
probably involve something like pointers to unaligned big-endian
integers in allocated buffers, or maybe integer fields in packed
structures, again via pointers. (It looks like you may be trying to
handle the latter but not the former in the code you've got so far.)
For another, one operation that may be used in code refactoring
involves taking a bunch of code accessing some variable x (and
presumably similar blocks of code elsewhere that may use different
variables), and pulling it out into a separate function that takes the
address of the thing to be modified, passed in at the call sites to
the new function; if direct access to x and access via &x behave
differently under this attribute, suddenly this formerly reasonable
transformation is unsafe -- and perhaps worst of all, the behavior
change would be silent, since the compiler would have nothing to
complain about.
Also, changing the behavior later means changing the interpretation of
some code after deploying a compiler using one interpretation.
Consider this on a 32-bit little-endian machine:
unsigned int x __attribute__((endian("big"));
*&x = 0x12345678;
In normal C code without this attribute, reading and writing "*&x" is
the same as reading and writing x. In your proposed version, "*&x"
would use the little-endian interpretation, and "x" would use the big-
endian interpretation, with nothing at the site of the executable code
to indicate that the two should be different. But an expression like
this can come up naturally when dealing with macro expansions. Or,
someone using this attribute may write code depending on that
different handling of "*&x" to deal with a selected byte order in some
cases and native byte order in other cases. Then if you update the
compiler so that the attribute is passed along to the pointer type, in
the next release, suddenly the two cases behave the same -- breaking
the user's code when it worked under the previous compiler release.
If you support taking the address of specified-endianness variables at
all, you need to get the pointer handling right the first time around.
I would suggest that if you implement something like this, the
attribute should be associated with the data type, not the variable
decl; so in the declaration above, x wouldn't be treated specially,
but its type would be "big-endian unsigned int", a distinct type from
"int" (even on a big-endian machine, probably).
The one advantage I see to associating the attribute with the decl
rather than the type is that I could write:
uint32_t thing __attribute__((endian("big")));
rather than needing to figure out what uint32_t is in fundamental C
types and create a new typedef incorporating the underlying type plus
the attribute, kind of like how you can't write a declaration using
"signed size_t". But that's a long-standing issue in C, and I don't
think making the language inconsistent so you can fix the problem in
some cases but not others is a very good idea.
- the test case is
uint32_t x __attribute__ ((endian("big")));
uint32_t * pt
Re: GCC build failure, h...@149166 on native
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
Re: Aliasing bug
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 reference to a
memory location that happens to contain a pointer is different to one
what contains other data?
Anyway, I see that the glibc code has, in fact, already been fixed here:
http://sourceware.org/ml/libc-alpha/2008-11/msg4.html
Thank you.
Andrew
Re: Aliasing bug
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 not know that. I still don't understand how a reference to a
> memory location that happens to contain a pointer is different to one
> what contains other data?
It's easy enough to find out: just look at the C standard. 6.3.2.3, Pointers.
Andrew.
Re: Aliasing bug
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 to store to foo.
>
> Ah, I did not know that. I still don't understand how a reference to a
> memory location that happens to contain a pointer is different to one what
> contains other data?
It is not different.
> Anyway, I see that the glibc code has, in fact, already been fixed here:
> http://sourceware.org/ml/libc-alpha/2008-11/msg4.html
Great.
Richard.
> Thank you.
>
> Andrew
>
Re: GCC build failure, h...@149166 on native
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 failure was Darwin specific and is now fixed, two others are powerpc ones. When they will be fixed on trunk the annoying mails will automatically disappear. However, this does not mean that tuning the regression tester to not sending more than 6 emails a day (one every 4 hours) would be a bad idea. It is once every commit until it is fixed which seems like the correct way of doing it really. We really should be frozen during the period it is broken. Otherwise more things break like what happened here. --Pinski Paolo
Re: BIGGEST_ALIGNMENT vs g++ compat test expectation on aix ?
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. Humm, it apparently doesn't: I see no difference in the generated assembly for t027_y.C. Olivier
Re: About feasibility of implementing an instruction
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 the register [b32 to b39] the data > has to be stored into a 32bit memory location. The data should be > stored in such a way that if it is stored for 0-7 in memory the data > can be moved to b32-b39 of a even register and if the data in the > memory is stored in 16-23 of the memory word then it can be moved to > b32-b39 of a odd register. Hope i make myself clear. > > Will it be possible to implement this in the gcc back-end so that the > particular instruction is supported? In general, the gcc backend can do anything, so, yes, this can be supported. It sounds like this is not a general purpose register, so I would probably do it using a builtin function. If you need to treat it as a general purpose register (i.e., the register is managed by the register allocator) then you will need a secondary reload to handle this. Ian
Re: Endianess attribute
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 gcc, and i would like to > implement this feature as an exercise. > > You already prevent me that it would be a hard task (aliasing, etc.), but i > would like to begin with basic specs. Well actually, if we can ever get the named address space patches checked in, it provides the framework for different address spaces, where pointers might be different sizes or encodings from standard pointers. Non-native endian would be handled by a different named address space, and the compiler would not let you convert different endian pointers. I suspect there are still holes, but those will only be fixed when it gets more mainstream testing and use. Tree level aliasing might be one such case. During the recent GCC summit, I gave a talk about the named address space support that I had worked on last year before being transfered to a different group within IBM. Unfortunately all of my focus is getting the powerpc changes in the current release, and I no longer officially work on the named address space stuff. 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 fact more time to get the byte swap instructions nailed down (bear in mind, since I've written a lot of the named address space stuff, I knew exactly where to add stuff, so it might take somewhat longer for somebody else to add the support). So for example, with my patches: __little int foo; would declare foo to be little endian (there are restrictions that named address space variables can only be global/static or referenced through a pointer). Then you can declare: int *__little bar = &foo; would declare bar to be a normal pointer, which points to a little endian item. The following would be illegal, since bletch and bar point to different named address spaces, and the backend says you can't convert them. int *bletch = bar; -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: GCC build failure, h...@149166 on native
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 extremely irritating is that it takes so long to fix bootstrap failures. Meanwhile I hope to see such mails until the problem(s) is (are) fixed. Well, I suppose "native" is *-darwin which then boils down to the fact that this is not a freely available host operating system and the respective maintainers of that target/host combination seem to not care. But yes, Geoff - can you adjust the regression mails to not blame people for build failures that persist for some time? The regression tester's mail should not be taken as blaming anyone for anything. It's a machine and not yet capable of such complex thoughts. Indeed, it's not capable of reliably working out whether a build failure has persisted for some time or has changed. At present it looks at the log file length but because the log file length can vary for many reasons it can have both false positives and false negatives. The powerpc tester won't do a run more often than once every 15 minutes, and that only if the build fails that quickly (indicating a pretty bad build breakage) and there are commits since the previous run. In those circumstances I think it's reasonable to hope that the commit will fix the build breakage and so should be tested as quickly as possible... If anyone is having trouble reproducing a problem reported by the tester, send me mail!
Re: GCC build failure, h...@149166 on native
> 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, need for approval, need to rely on Peter Bergner to test patches, possibility to work with him only when both of us were awake, etc.). 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. Paolo
-frename-registers bug?
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 dumps.
./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers -fverbose-asm
cp_vector __attribute((vliw))
func1( cp_vector a, cp_vector b )
{
cp_vector c;
c = mep_cpabsu3_b(a,b);
mep_c0nop();
c = mep_cpadd3_b(a,c);
c = mep_cpsub3_b(a,c);
c = mep_cpabs3_b(c,b);
mep_c1nop();
c = mep_cpadd3_h(a,c); <- 1
c = mep_cpabs3_h(c,b);
c = mep_cpsub3_h(c,a); < -2
c = mep_cpadd3_w(c,c);
return c;
}
func1:
cpabsu3.b $c8,$c1,$c2 ;# tmp149, a, b
c0nop
cpadd3.b$c5,$c1,$c8 ;# tmp150, a, tmp149
cpsub3.b$c4,$c1,$c5 ;# tmp151, a, tmp150
cpabs3.b$c3,$c4,$c2 ;# tmp152, tmp151, b
c1nop
cpadd3.h$c1,$c1,$c3 ;# tmp153, a, tmp152<- 1 (clobbers
$c1)
cpabs3.h$c2,$c1,$c2 ;# tmp154, tmp153, b
cpsub3.h$c0,$c2,$c1 ;# tmp155, tmp154, a<- 2 (expects
old $c1 value)
cpadd3.w$c0,$c0,$c0 ;#, tmp155, tmp155
ret
begin 644 dj.dap.tar.gz
M'XL(``\F34H"`^U;;6_;.!+.5_M7$-T<8.-X0
M!(8L*;:ZBN23Y"3=(/_]GJ%>_":Y;G>;7GL68&A(S:!Q33/X`=,.'N&:9[F;,G;@O]_.-W&O
m...@^s@N[N\V>C&_D_(KH/9R)NYXVRNC\:L5W8/6$GTGW77.'U_-\9L/MY1XSC;
mqbbg*...@a&]!2.(34;2N`NCLK&=460KT+<%(wh+...@o$e"O^#2XF3&>BM=
MO.I2^@(O3U(V&KEYGH;C>1[T>C=1>-OO=Z_FL<=[;,'D#I8:8];OWG<[BPX/
M"CL>>[XZ>CUW,`94IS:&@)?9U-"!RUOM+T9JL[\8F)ZWI)6W:)VV2$\KZ34T
MZG<;]-RBG_1T.VF0S].8/'w...@_vuu]]^>^'V5?._X+KHL[_IL95_C?%/O\_
MQM497H51T'F">>`]Z7:&&3)+F,2=X4T>W.6#)^[=S9/!3[,TF8S#/`,#92K<
M9L*-PDG,..A)E(PCIG(76OF'6=!1C0'[B>ZDK\AL1]W.#^PJ122/F,T8?FDP
MR2BCJ=0U''<./7MP",E#3W2>_<#RZQF7SH#2X)C:5L>;!/$HC)$XXRST%DEO
M]%H;O>:=BRB()_D4V41>0B]E/Y)S-N3HB9+1WJX+J12D;#%*6^S*%D-3MA1F
M42?7&BQ2^94T-UBD\IY2+DOE1JV2R,92MNGD926YNR'$52MXFV-OO!4F$JW6U#U*9;!>6VU*U^4#-8
M5:YFA,Y;0G+;'!)LE"0FM7++),$...@c=uhb4]G0"_2OLO]S79KFVOY/C?W^_QA7]]DS
M]FNY21=;..NI6[]+CSB+DF26L:MD'OOHH+Z7Z&$:46P:N'Z0,NR*D9LC"W#5
MZP(_9WX_*N1B_3WX8^`>6X4!7ZWVWU>7S"'72!)D>%BDPNZ)F[M747(+\ZZOW?3#D;(^C&]0\/AN#OWC#THCZ\"9BT/M
m...@y<'/)+>'1Q*"Z9CIM^R21N\I(YN#E@(59.O(H9W)S8.?BY"6+F@;!`1#,0
M-HC,34%!'+H$2:>S,2BNJ`"44!3D!"%.0Q"$&2...@#'8!4`'-A"f...@f"`%Z;T>
M4P^9=1V`TC75AZi...@n*5(<^"%*-W0D4=!\&A*N3X<$=462Y=S4!
M!0A!02"`...@d`?ac/),$X"M120C)+`=%"*F2E83A%21`!#R0@,!npb0...@f
MR0./.DB_AQZ#U'm`-$b[av`9i-m#z`u2...@r%#/!J'LA%Y#Z:'8&(4B:#*5
M)AH14ZGBT&4J71S*3*6,0YNIS.0F*$-1%BB%P`%A*@@.#%-A"&"8"D,`PRJL
M!8:E,`0P+(4A@&$I#`$,2V$(8...@*0p##4a@"&);"H/A8"H,B9"D,BI&M,#!]
MT&LK%`3<5B!>"F1;+TA`VPHFN5*L1DF3"k...@7>JW2IKZ[4(4-MA.0<((1RM(
M"J?#2QK<3HE)(75*4`JJ(TN:EH=1&DO\A.IZGC8B15;5H"=VU2!53M70:5UI
M54M2BU894UV&%7;."`P_F$;;+
M<91XOS/*V%>A%[H1,6?KS,'THWPP6PU1.JED4.U^*,60SQ7OEN2ZT%.FSD+)
M79B7.M;QZOSQ+8R'&H;@!EMH%-X$Y(95[`_2KI)@E0-5"BR%KN"U.P%_RI_?
M<_^!I:*\Z^5=EG=N$#$0>3)OS0U$%#+N].,D#3"*-&>S\U;O3T=GYV_/1R>G+TW>G)T61\Y9J
m...@qb[>L\J9TV-:GSW]1U&KC,>8?XMI/**I>83*Y:'I(CA_RGO%:,&`E^+M&GX/
MHZBC!O8U58.!CVG#3L_?O?DW54/:4/O;)4.1BTF23]-YOYPA!N8(BA=X2>-Y
MN317?OGY[=GQZ)>7KX[_B?E2<(/30!(22VROW[QZ^>K%;Z>CT_.3FD\2I[7"
M]^MOY\?OSEY![^D+XJ-Y"A:)2E$P>a...@l^]+,A9#Y/ZZ.2,?(6K,%XZE_TN
M*Z_>/,y...@4<,%W5G_1"B/]XH80?"&,LD#2='''64RRY)E;6D:E,*4450:RF;
MC0LI>TV*"D,N^WU4A1:[W_YQ[H'UXC#JUSX[\!H[9N6T77DTNDGP-A%&P9I?
M/2^)LYST4]VMW6E+ME!A[)A]5%]RTXRE;w...@#?h4j\,L)IB;RA??G(MP]U
M&6G#H$B;J!+OMW]TW/!2D*-<5FYBK;>XR1_9S96X5FY*$VY*E&3W6S]_;g...@i
ME:-F[25O\U)\BI?M`?J3RT:H96,T+YMV+TWEJ%U[*?[>3:)IT0BU:'C;HIFV+!HX2%&NKE?OI%-S-TE$49OG1F],7J(1^/OG8T*FX+`(CU.`;=6",
MMO$W/C4PS3']_%FBLHE4V41ORR8[!:9EL%LD/LW(,KQUS4"1%?0U1C06K,4@
MT&.#o...@["T<_T8+H;ALV>FL=.",YH6',U$TW3:%MQMRX*#,_!*=Y9=HOIR
MPR74Y7PA6]1C#HE+;25FIZ_/BHJLK+3>SZ]G(P4%1DA(o...@pu48F*"K6_E%0+`]NFTT)D8X6A9CV-_?57$4'O(3W&^U41GB#%T-(;68@)8U*90SF5^6$]U1]SA*E*PW
M=<-8[3)NSJI7M5X>I-=A[.;!Z#8-\Z"_C5U\&KO\-';[D]C%BNU^X/J;W&+!
M+3[.O="-/7/3E),P\]S4;Y%8\17C,$H5QIM@@MT*V968>[Q_I,Z8CM^,L'^]
M+9>.7!9MXE^WEV^VUEEE;
MS47,R^%Y1F>-[HT;1NX8+V?C("<>;YJ$7K`:NDI&B%UE%CA"&[`TB)&E?.9F
M5'EVB\5'%n9c4cbc5$8p=evg`wlyh1u\?...@r:[B;5?M#[OTA]_Z0>W_(O3_D
MWA]R?ZN'W$B!50:L$F"5_U3ZVQ^"[p_!...@w]\a.,H;+._](?CC'X*CPD2"
M?<1#\.:A_M*'X*BHL9\\XB%XW[6(7AS@/:'X,V'X.6$>+1#
M\.:!_5\^!&^,T/X0?'\(OC\$_SX.P1T;^6;MOQ$?]N?BW^"Y>/%-.::'C=^>
MHR!O>;9%LOA.WB)*#[?)BFVR8KNLW"8KM\O:VV3MK;)BF[_T\/_OKP_VU_[:
47_MK?^VO_?4UKO\"'+!2NP!0
`
end
Re: -frename-registers bug?
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 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 dumps.
>
> ./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers -fverbose-asm
>
> cp_vector __attribute((vliw))
> func1( cp_vector a, cp_vector b )
> {
> cp_vector c;
>
> c = mep_cpabsu3_b(a,b);
> mep_c0nop();
> c = mep_cpadd3_b(a,c);
> c = mep_cpsub3_b(a,c);
> c = mep_cpabs3_b(c,b);
> mep_c1nop();
> c = mep_cpadd3_h(a,c); <- 1
> c = mep_cpabs3_h(c,b);
> c = mep_cpsub3_h(c,a); < -2
> c = mep_cpadd3_w(c,c);
>
> return c;
> }
>
>
> func1:
> cpabsu3.b $c8,$c1,$c2 ;# tmp149, a, b
> c0nop
> cpadd3.b $c5,$c1,$c8 ;# tmp150, a, tmp149
> cpsub3.b $c4,$c1,$c5 ;# tmp151, a, tmp150
> cpabs3.b $c3,$c4,$c2 ;# tmp152, tmp151, b
> c1nop
> cpadd3.h $c1,$c1,$c3 ;# tmp153, a, tmp152 <- 1 (clobbers
> $c1)
> cpabs3.h $c2,$c1,$c2 ;# tmp154, tmp153, b
> cpsub3.h $c0,$c2,$c1 ;# tmp155, tmp154, a <- 2 (expects
> old $c1 value)
> cpadd3.w $c0,$c0,$c0 ;#, tmp155, tmp155
> ret
>
> begin 644 dj.dap.tar.gz
> M'XL(``\F34H"`^U;;6_;.!+.5_M7$-T<8.-X0
> M!(8L*;:ZBN23Y"3=(/_]GJ%>_":Y;G>;7GL68&A(S M:;A,*=6=B^*N57?J,HP#SH70!7Z:>:!Q33/X`=,.'N&:9[F;,G;@O]_.-W&O
> m...@^s@N[N\V>C&_D_(KH/9R)NYXVRNC\:L5W8/6$GTGW77.'U_-\9L/MY1XSC;
> mqbbg*...@a&]!2.(34;2N`NCLK&=460KT+<%(wh+...@o$e"O^#2XF3&>BM=
> MO.I2^@(O3U(V&KEYGH;C>1[T>C=1>-OO=Z_FL<=[;,'D#I8:8];OWG<[BPX/
> M"CL>>[XZ>CUW,`94IS:&@)?9U-"!RUOM+T9JL[\8F)ZWI)6W:)VV2$\KZ34T
> MZG<;]-RBG_1T.VF0S].8/'w...@_vuu]]^>^'V5?._X+KHL[_IL95_C?%/O\_
> MQM497H51T'F">>`]Z7:&&3)+F,2=X4T>W.6#)^[=S9/!3[,TF8S#/`,#92K<
> M9L*-PDG,..A)E(PCIG(76OF'6=!1C0'[B>ZDK\AL1]W.#^PJ122/F,T8?FDP
> MR2BCJ=0U''<./7MP",E#3W2>_<#RZQF7SH#2X)C:5L>;!/$HC)$XXRST%DEO
> M]%H;O>:=BRB()_D4V41>0B]E/Y)S-N3HB9+1WJX+J12D;#%*6^S*%D-3MA1F
> M42?7&BQ2^94T-UBD\IY2+DOE1JV MH,90D>2R,92MNGD926YNR'$52MXFV-OO!4F M8GV^&')0...@ra7a=;BZK0EC&J(2+$JW6U#U*9;!>6VU*U^4#-8
> M5:YFA,Y;0G+;'!)LE"0FM7++),$...@c=uhb4] MQ\='K/?B_+<^DT-CJ"%XFJ-9FF"]X&X6I.$UV-RHSRXFGO=4CO2GX]2-O2D6
> M\DV88:$S)'-;URZ?[#?K;V7_]X;<$>G0"_2OLO]S79KFVOY/C?W^_QA7]]DS
> M]FNY21=;..NI6[]+CSB+DF26L:MD'OOHH+Z7Z&$:46P:N'Z0,NR*D9LC"W#5
> MZP M0991,[F"n...@30.?(0W&63>(_9WX_*N1B_3WX8^`>6X4!7ZWVWU>7S"'72 MGDW=>!)D>%BDPNZ)F[M747(+\ZZOW?3#D;(^C&]0\/AN#OWC#THCZ\"9BT/M
> m...@y<'/)+>'1Q*"Z9CIM^R21N\I(YN#E@(59.O(H9W)S8.?BY"6+F@;!`1#,0
> M-HC,34%!'+H$2:>S,2BNJ`"44!3D!"%.0Q"$&2...@#'8!4`'-A"f...@f"`%Z;T>
> M4P^9=1V`TC75AZi...@n*5(<^"%*-W0D4=!\&A*N3X<$=462Y=S4!
> M!0A!02"`...@d`?ac/),$X"M120C)+`=%"*F2E83A%21`!#R0@,!npb0...@f
> MR0./.DB_AQZ#U'm`-$b[av`9i-m#z`u2...@r%#/!J'LA%Y#Z:'8&(4B:#*5
> M)AH14ZGBT&4J71S*3*6,0YNIS.0F*$-1%BB%P`%A*@@.#%-A"&"8"D,`PRJL
> M!8:E,`0P+(4A@&$I#`$,2V$(8...@*0p##4a@"&);"H/A8"H,B9"D,BI&M,#!]
> MT&LK%`3<5B!>"F1;+TA`VPHFN5*L1DF3"k...@7>JW2IKZ[4(4-MA.0<((1RM(
> M"J?#2QK<3HE)(75*4`JJ(TN:EH=1&DO\A.IZGC8B15;5H"=VU2!53M70:5UI
> M54M2BU M7*M:A,=YU2(\3NC9U/636YLDN5RT"9,;=9LK?K-N2Y4VK+HME+R]:)-=E"FJ
> M-EFM4D;95MF&+]JD3Z6/$L^^++*YF_JW+G(BO96Q>894UV&%7;."`P_F$;;+
> M<91XOS/*V%>A%[H1,6?KS,'THWPP6PU1.JED4.U^*,60SQ7OEN2ZT%.FSD+)
> M79B7.M;QZOSQ+8R'&H;@!EMH%-X$Y(95[`_2KI)@E0-5"BR%KN"U.P%_RI_?
> M<_^!I:*\Z^5=EG=N$#$0 M&35EUI154W9-.14EM)KB-24*2CG#6)[...@=6/)*6G<<^D/=#X?:,$#MF5$[AZ3
> MJ)J9?\>>3)OS0U$%#+N].,D#3"*-&>S\U;O3T=GYV_/1R>G+TW>G)T61\Y9J
> m...@qb[>L\J9TV-:GSW]1U&KC,>8?XMI/**I>83*Y:'I(CA_RGO ML44I51%L9?97&_[F;O8-S$]R"+[NYE`E@,A!H%Z&*X]IDK>%:,&`E^+M&GX/
> MHZBC!O8U58.!CVG#3L_?O?DW54/:4/O;)4.1BTF23]-YOYPA!N8(BA=X2>-Y
> MN317?OGY[=GQZ)>7KX[_B?E2<(/30!(22VROW[QZ^>K%;Z>CT_.3FD\2I[7"
> M]^MOY\?OSEY![^D+XJ-Y"A:)2E$P>a...@l^]+,A9#Y/ZZ.2,?(6K,%XZE_TN
> M*Z_>/,y...@4<,%W5G_1"B/]XH80?"&,LD#2='''64RRY)E;6D:E,*4450:RF;
> MC0LI>TV*"D,N^WU4A1:[W_YQ[H'UXC#JUSX[\!H[9N6T77DTNDGP-A%&P9I?
> M/2^)LYST4]VMW6E+ME!A[)A]5%]RTXRE;w...@#?h4j\,L)IB;RA??G(MP]U
> M&6G#H$B;J!+OMW]TW/!2D*-<5FYBK;>XR1_9S96X5FY*$VY*E&3W6S]_;g...@i
> ME:-F[25O\U)\BI?M`?J3RT:H96,T+YMV+TWEJ%U[*?[ M&Q;8*LCURL7K9TN<]<>>3:)IT0BU:'C;HIFV+!HX2%&NKE? MIY/^UTTG34TGO6TZ3>OI%-S-TE$49OG1F],7J(1^/OG8T*FX+`(CU.`;=6",
> MMO$W/C4PS3']_%FBLHE4V41ORR8[!:9EL%LD/LW(,KQUS4"1%?0U1C06K,4@
> MT&.#o...@["T<_T8+H;ALV>FL=.",YH6',U$TW3:%MQMRX*#,_!*=Y9=HOIR
> MPR74Y7PA6]1C#HE+;25FIZ_/BHJLK+3>SZ]G(P4%1DA(o...@pu M.&5MR"J[CMZ>48F*"K6_E%0+`]NFTT)D8X6A9CV-_?57$4'O(3W&^U41G M;_6EMBC16QSH%J]C<\^KJO9_G;U;%.T8PK&;IB%>B#%T-(;68@)8U* M_MOR=W?^HZ?#-,;D_!KG/Z9IRO7S']/:__W'5S__>90SF5^6$]U1]SA*E*PW
> M=<
Re: -frename-registers bug?
> 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
Re: Register Pressure in Instruction Level Parallelism
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 it often does suboptimally (and secondary reloads even worse). If a clever pass running before reload could insert explicit spill/reload code at well-chosen places (bearing in mind class-based register pressure), it could relieve reload of the necessity to generate its own spill code most of the time, and let it just do what it does best. IRA actually already inserts spill code in most important places (on loop borders). Besides loop regions, IRA could be extended to other regions (and even bb parts to relief pressure inside the blocks). I am going to work on it to evaluate how much it could give. I've already got some code to do this -- I've pondered more than once pushing it through independently of the other allocation/reload work I'm doing. I could probably be convinced to put the block local allocation/spilling on hold to focus on benchmarking and tuning my bits to generate spill code. That is great. I look forward to see the code.
gcc-4.5-20090702 is now available
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 revision 149198 You'll find: gcc-4.5-20090702.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090702.tar.bz2 C front end and core compiler gcc-ada-4.5-20090702.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090702.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090702.tar.bz2 C++ front end and runtime gcc-java-4.5-20090702.tar.bz2 Java front end and runtime gcc-objc-4.5-20090702.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090702.tar.bz2The GCC testsuite Diffs from 4.5-20090625 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Endianess attribute
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 fact more time to get the byte swap instructions nailed down That sounds great! (there are restrictions that named address space variables can only be global/static or referenced through a pointer). That sounds like a potential problem, depending on the use cases. No structure field members with explicit byte order? That could be annoying for dealing with network protocols or file formats with explicit byte ordering. On the other hand, if we're talking about address spaces... I would guess you could apply it to a structure? That would be good for memory-mapped devices accepting only one byte order that may not be that of the main CPU. For that use case, it would be unfortunate to have to tag every integer field. I don't think Paul indicated what his use case was... Ken
Re: GCC build failure, h...@149166 on native
> 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 reported for weeks in PRs and the problematic patch clearly identified. -- Eric Botcazou
Re: GCC build failure, h...@149166 on native
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 recent multiple SPARC breakages had been reported for weeks in PRs and the problematic patch clearly identified. Yeah, but it's nothing compared to the nagging for powerpc-darwin. Maintainers and other frequent testers of SPARC notice it, and that's it. While everyone is going to notice the failures from Geoff's regression tester, like Arnaud did. Paolo
