New definition of regression
I am not a fan of the new definition of a regression. Yes the new definition helps out release managers but it does not help out our users at all. In fact I think it hurts them more as some don't update as fast as the release managers think they do. I still support a 4.3 based GCC and only starting to roll out a 4.7 based GCC. I think it is wrong to say memory/compile time hogs are not regressions any more just for the fun of it. Also this was not discussed at all on the list or I did not see it being discussed. This decision should not be taken lightly when it comes to some users of the compiler. Thanks, Andrew Pinski
Confusion about delay slots and using condition-code register
I'm using the CCmode model for condition-code handling in a 4.6.1 based compiler. Every other port I've done used the CC0 model, so I'm probably doing something misguided here. I'm down to just 170 failures in the check-gcc testsuites, so it's looking pretty solid; of the failures about 30 are tests with delay-slots being filled incorrectly. The situation I see is where we have source that looks like if (x != 0) count++; if (y != z) . RTL (without delay slot considerations looks like) jeq$1 add r1,1 $1: cmp r2,r3 jeq $2 branches have delay slots, and are not annullable. When reorg runs, it realizes that it can't put the add into the delay slot, but it hoists the cmp instruction into the first branch slot, ala jeq $1 cmp r2,r3 add r1,1 $1: jeq $r2 .. So, if the first branch is not taken, we set the condition codes needed for the second branch and clobber them with the add instruction then fall to the conditional branch using the wrong condition codes. I emit (clobber (reg:CC CCreg)) with every instruction that can set condition codes, but it appears that nearly all of them are removed before we reach reorg where mark_referenced_resources() or mark_set_resources() would detect a conflict of the CCreg's. So, am I constructing my RTL incorrectly? Do I need to be making the clobbers inside a parallel instead of just emitting them sequentially? Or should I just fall back to a cc0 model where this shouldn't be a problem? The define_expand pattern for add looks like (define_expand "add3" [(set (match_operand:S 0 "nonimmediate_operand") (plus:S (match_operand:S 1 "general_operand") (match_operand:S 2 "general_operand"))) (clobber (reg:CC CC_REGNUM))] "" . }) has corresponding define_insn's are (define_insn "*addsi" [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,rS,rm") (plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0, 0, 0,rm") (match_operand:SI 2 "general_operand" "QI, K, i,rm")))] , ) (define_insn "*addsi_cc" [(set (reg:CC CC_REGNUM) (compare:CC (plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0, 0, 0,rm") (match_operand:SI 2 "general_operand" "QI, K, i,rm")) (const_int 0))) (set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,rS,rm") (plus:SI (match_dup 1) (match_dup 2)))]
Re: C++ conversion: an observation about minimum compiler version
This is now bugzilla 56558.
Thierry Moreau wrote:
Hi,
The C++ template code in annex triggers a
compile-time error on 4.2, 4.4, 4.6, but not on 4.7. (I suppose this bug
has been found and tracked before.)
===
template class t1
{
public:
int length;
};
template class t2 : public t1
{
public:
void f();
};
template
void t2::f()
{
int &len=(t1::length); // ok
t1::length=100; // ok
unsigned char *val=new unsigned char[t1::length]; // ok
int ln=-(t1::length); // ok
int *ptlen=&(t1::length); // address-of operator in this
// base class template member access
// ==> compiler bug with gcc 4.2 to 4.6
}
void fstatic()
{
t2<1000> obj;
obj.f(); // instantiate ...
}
===
In member function 'void t2::f() [with int SIZE = 1000]':
error: cannot convert 'int t1<1000>::*' to 'int*' in initialization
===
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
Re: 32 bit pointers on a 64 bit system
Thanks for that about the MIPS and PA. Gosh now I feel rather silly, I remember doing something like this years and years ago in a company I was in at the time with MIPS and PowerPC but it was roll our own rather than gcc. Parameters were passed on stack at the size they were rather than widened to 64 as in N32 but callee save registers had to be saved as 64 bits wide - but it didn't matter much as there were lots of work registers. And we did have 64 bit longs with 32 bit pointers without any special problems with software even then. An interesting thing was we normally tried to separate registers holding pointers from those holding data in the call ABI. Sorry, I really had completely forgotten about it, I just don't know how all that work could have completely slipped my mind. David McQuillan On 06/03/2013 14:26, Jeff Law wrote: On 03/06/2013 07:21 AM, paul_kon...@dell.com wrote: On Mar 6, 2013, at 7:38 AM, David McQuillan wrote: Have there been any implementations of gcc for a 32 bit pointer system where the registers are 64 bits long? MIPS (N32 ABI, and if you want, also O64) is another example. The PA2.0 chips were commonly used in this manner as well when they were first delivered. It's referred to as "narrow" mode. jeff
Re: Adding UNION/MAP -- Feedback and tips pls!
On Wed, Mar 6, 2013 at 11:46 AM, N.M. Maclaren wrote: > On Mar 6 2013, Andrew Pinski wrote: >> >> >> Except GCC implements C's unions as allowing to do type punning as an >> extension and as far as GCC is concerned that is not going to change >> any time soon. >> This is a documented exception to the aliasing/type punning rules. > > > The problem is that this is worse than type punning, because it also > allows the preservation of data. Does the extension guarantee that, > or would it need a change to at least the documentation? The documentation is not clear on whether data is preserved. I believe that as a matter of fact the data is preserved, but I don't think we need to guarantee it. Ian
Re: Adding UNION/MAP -- Feedback and tips pls!
On Wed, 6 Mar 2013, N.M. Maclaren wrote:
> On Mar 6 2013, Andrew Pinski wrote:
> >
> > Except GCC implements C's unions as allowing to do type punning as an
> > extension and as far as GCC is concerned that is not going to change
> > any time soon.
> > This is a documented exception to the aliasing/type punning rules.
>
> The problem is that this is worse than type punning, because it also
> allows the preservation of data. Does the extension guarantee that,
> or would it need a change to at least the documentation?
I don't think the extension guarantees more than type punning as described
in the footnote added in C99TC3 ("If the member used to access the
contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object
representation of the value is reinterpreted as an object representation
in the new type as described in 6.2.6 (a process sometimes called "type
punning"). This might be a trap representation.").
That is, writing to a smaller member might affect bytes of the union
outside that member (at least, we don't claim to preserve them).
--
Joseph S. Myers
jos...@codesourcery.com
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Andrew Pinski wrote: Except GCC implements C's unions as allowing to do type punning as an extension and as far as GCC is concerned that is not going to change any time soon. This is a documented exception to the aliasing/type punning rules. The problem is that this is worse than type punning, because it also allows the preservation of data. Does the extension guarantee that, or would it need a change to at least the documentation? Regards, Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
Doing a bit more light reading on type-punning wrt unions I came upon
the following (from
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html#Structures-unions-enumerations-and-bit_002dfields-implementation):
"""
- A member of a union object is accessed using a member of a different
type (C90 6.3.2.3).
The relevant bytes of the representation of the object are treated as
an object of the type used for the access. See Type-punning. This may
be a trap representation.
"""
Further digging leads to the -fstrict-aliasing flag (from
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#Type%2dpunning)
which notes:
"""
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
union a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one
most recently written to (called “type-punning”) is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type. So, the code above will work as
expected.
"""
I'll leave interpretation about the implications of this to the experts.
v/r,
Russell
On Wed, Mar 6, 2013 at 2:21 PM, Russell Brennan
wrote:
> Perhaps I misunderstand how you are defining failure here... what
> would be the failure mode? Perhaps if you could provide an example of
> the ill-effects that could be seen as a result of this behavior it
> would clarify the issue?
>
> v/r,
>
> Russell
>
> On Wed, Mar 6, 2013 at 2:15 PM, N.M. Maclaren wrote:
>> On Mar 6 2013, Russell Brennan wrote:
Ouch.
This seems to be at odds with C's unions, where it is not allowed to do
type punning.
>>>
>>>
>>> As of gcc 4.4.6, the description above seems to match the C behavior:
>>
>>
>> Er, no. One simple test does not prove that it will always work; this
>> sort of thing is most likely to fail because it interacts in very nasty
>> ways with optimisation. C99 introduced a horribly ill-defined concept
>> called "effective types", which specifically allows type-dependent
>> optimisations. I have no idea whether gcc uses it at present, but it
>> might well do so in the future.
>>
>> Regards,
>> Nick Maclaren.
>>
>>
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Russell Brennan wrote:
Perhaps I misunderstand how you are defining failure here... what
would be the failure mode? Perhaps if you could provide an example of
the ill-effects that could be seen as a result of this behavior it
would clarify the issue?
Generating bad code. In:
union {
double x[10];
double y;
} fred, joe;
fred.y = 0.0;
joe = fred;
call alf(fred);
The compiler is permitted to copy only a single double in either of
the last two statements, because the last use was via y. That liberty
dates from C90, but C99 effective types extended it to many more cases.
If you break the semantic rules of a language, it is common to see no
error until you enable optimisation, whereupon it produces wrong answers
and the average user claims that the optimiser is broken.
Regards,
Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
On Wed, Mar 6, 2013 at 10:35 AM, Thomas Koenig wrote:
> Am 04.03.2013 21:34, schrieb N.M. Maclaren:
>
> (quoting documentation about DEC UNIONs for Fortran)
>
>> "However, if you overlay one variable with another smaller variable,
>> that portion of the initial variable is retained that is not overlaid.
>> Depending on the application, the retained portion of an overlaid variable
>> may or may not contain meaningful data and can be utilized at a later
>> point in the program."
>
>
> Ouch.
>
> This seems to be at odds with C's unions, where it is not allowed to do
> type punning.
Except GCC implements C's unions as allowing to do type punning as an
extension and as far as GCC is concerned that is not going to change
any time soon.
This is a documented exception to the aliasing/type punning rules.
Thanks,
Andrew Pinski
>
> This probably means that it would be necessary to present a DEC Fortran
> union to the middle end as something like
>
> union {
> char buff[8];
> double b;
> int c;
> }
>
> and then only do assignment with memcpy() to buff.
>
> I think you're right - if we add this to gfortran, it should live behind
>
> -fdo-you-really-want-to-use-dec-unions-yes-well-in-that-case-i-ll-let-you
>
> or an options with a similar name.
>
> Thomas
Re: Adding UNION/MAP -- Feedback and tips pls!
Perhaps I misunderstand how you are defining failure here... what would be the failure mode? Perhaps if you could provide an example of the ill-effects that could be seen as a result of this behavior it would clarify the issue? v/r, Russell On Wed, Mar 6, 2013 at 2:15 PM, N.M. Maclaren wrote: > On Mar 6 2013, Russell Brennan wrote: >>> >>> >>> Ouch. >>> >>> This seems to be at odds with C's unions, where it is not allowed to do >>> type punning. >> >> >> As of gcc 4.4.6, the description above seems to match the C behavior: > > > Er, no. One simple test does not prove that it will always work; this > sort of thing is most likely to fail because it interacts in very nasty > ways with optimisation. C99 introduced a horribly ill-defined concept > called "effective types", which specifically allows type-dependent > optimisations. I have no idea whether gcc uses it at present, but it > might well do so in the future. > > Regards, > Nick Maclaren. > >
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Russell Brennan wrote: Ouch. This seems to be at odds with C's unions, where it is not allowed to do type punning. As of gcc 4.4.6, the description above seems to match the C behavior: Er, no. One simple test does not prove that it will always work; this sort of thing is most likely to fail because it interacts in very nasty ways with optimisation. C99 introduced a horribly ill-defined concept called "effective types", which specifically allows type-dependent optimisations. I have no idea whether gcc uses it at present, but it might well do so in the future. Regards, Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
>> "However, if you overlay one variable with another smaller variable,
>> that portion of the initial variable is retained that is not overlaid.
>> Depending on the application, the retained portion of an overlaid variable
>> may or may not contain meaningful data and can be utilized at a later
>> point in the program."
>
>
> Ouch.
>
> This seems to be at odds with C's unions, where it is not allowed to do
> type punning.
As of gcc 4.4.6, the description above seems to match the C behavior:
#include
#include
int main() {
union {
uint32_t test32int;
uint16_t test16int;
} testunion;
testunion.test32int = 0x;
printf("Before assignment: %0x\n", testunion.test32int);
testunion.test16int = 0x;
printf("After assignment: %0x\n", testunion.test32int);
}
Produces the following:
Before assignment:
After assignment:
Re: Adding UNION/MAP -- Feedback and tips pls!
Am 04.03.2013 21:34, schrieb N.M. Maclaren:
(quoting documentation about DEC UNIONs for Fortran)
"However, if you overlay one variable with another smaller variable,
that portion of the initial variable is retained that is not overlaid.
Depending on the application, the retained portion of an overlaid variable
may or may not contain meaningful data and can be utilized at a later
point in the program."
Ouch.
This seems to be at odds with C's unions, where it is not allowed to do
type punning.
This probably means that it would be necessary to present a DEC Fortran
union to the middle end as something like
union {
char buff[8];
double b;
int c;
}
and then only do assignment with memcpy() to buff.
I think you're right - if we add this to gfortran, it should live behind
-fdo-you-really-want-to-use-dec-unions-yes-well-in-that-case-i-ll-let-you
or an options with a similar name.
Thomas
GCC 4.8.0 Status Report (2013-03-06)
Status == We've reached the goal of zero P1 regressions again, and have less than 100 P1-P3 bugs, but the number of changes going daily is still too high. If no new P1 appears within a week, I'd like to create first release candidate in the middle of next week, but please try to decrease the amount of changes to trunk till then, for every fix think twice whether it is really important to be already in 4.8.0 or if it can wait for 4.8.1, and if the patch isn't too risky at this point. The trunk remains in release branch mode, with only regression fixes and documentation changes allowed. Quality Data Priority # Change from Last Report --- --- P10 - 7 P2 65 0 P3 18 + 3 --- --- Total83 - 4 Previous Report === http://gcc.gnu.org/ml/gcc/2013-02/msg00177.html The next report will be sent by me again, when RC1 is created.
Re: 32 bit pointers on a 64 bit system
On 03/06/2013 07:21 AM, paul_kon...@dell.com wrote: On Mar 6, 2013, at 7:38 AM, David McQuillan wrote: Have there been any implementations of gcc for a 32 bit pointer system where the registers are 64 bits long? MIPS (N32 ABI, and if you want, also O64) is another example. The PA2.0 chips were commonly used in this manner as well when they were first delivered. It's referred to as "narrow" mode. jeff
Re: 32 bit pointers on a 64 bit system
On Mar 6, 2013, at 7:38 AM, David McQuillan wrote: > Have there been any implementations of gcc for a 32 bit pointer system where > the registers are 64 bits long? MIPS (N32 ABI, and if you want, also O64) is another example. paul
Re: filling delay slots with branches
On 03/05/2013 08:00 PM, Alan Lehotsky wrote: Am I correct in my understanding that you can't put a branch instruction in the delay slot of a branch instruction? Semantically, the HW I'm looking at annuls the branch in the delay slot if the first branch is taken, but any other instructions are not annulled; but it appears that there's no way to describe this in the define_delay() and it looks to me like the delay-slot for the instruction in the delay slot won't get filled properly either. e.g. cmpi $r1,0 jeq $1 jlt $2 jmp $3 nop would be a 3-way branch on zero, neg or (by elimination) positive values with the indented instructions being in a branch delay slot. I'm not aware of any way to describe it to the current delay slot scheduler; I looked at it briefly eons ago as the PA allows branches in delay slots, but gave up -- for the PA at least the semantics weren't very useful. jeff
Re: 32 bit pointers on a 64 bit system
David McQuillan writes: > Have there been any implementations of gcc for a 32 bit pointer system > where the registers are 64 bits long? x32. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: 32 bit pointers on a 64 bit system
On 6 March 2013 12:38, David McQuillan wrote: > Have there been any implementations of gcc for a 32 bit pointer system where > the registers are 64 bits long? Yes, the new x32 ABI for x86_64, see https://sites.google.com/site/x32abi/ and http://lwn.net/Articles/456731/
Re: RFC: IPACP function cloning without LTO
Hi,
On Wed, Mar 06, 2013 at 04:00:52PM +0400, Dinar Temirbulatov wrote:
> Hi,
> The current implementation of IPACP doesn't allowed to clone function
> if caller(s) to that function is located in another object.
That is not exactly true. With -fipa-cp-clone (default at -O3),
IPA-CP is happy to clone a function that is callable from outside of
the current compilation unit. Of course, only calls from within the
CU are redirected without LTO. And code size may grow significantly,
which is why IPA-CP does this only if it deems the estimated
cost/benefit ratio to still be quite good.
> Of course,
> no such problems if we could utilized LTO. And it is very interesting
> to have such functionality of compiler even without LTO. It could be
> changed, if for example we could call to the cloned instance of that
> function from the original instance of function in the function
> prolog:
> Here is what I mean:
>
> int func(int a, .)
> {
> if (a==some_constant)
> func.constprop.0();
>
> thanks, Dinar.
well, you could just as well put the quick version right into the
original function (and execute the original in the else branch). If
it is small and you did this in an early pass, IPA-SPLIT might even
help inliner to inline it into known callers.
The tough part, however, is determining when this is such a good idea.
Do you have any particular situation in mind?
Thanks,
Martin
32 bit pointers on a 64 bit system
Have there been any implementations of gcc for a 32 bit pointer system where the registers are 64 bits long? I was looking at AArch64 and wondering about whether it mightn't be better for a 32 bit system than AArch32 if all the pointers were 32 bit, and as far as the ABI is concerned half the general registers were treated as 32 bit. If more than 32 bits of address space were put in it could be used for data by using assembler inserts to use a long pointer to access it. I can't see any particular problems but that doesn't mean there aren't any great big ones! David McQuillan
Re: RFC: IPACP function cloning without LTO
On Wed, Mar 6, 2013 at 1:00 PM, Dinar Temirbulatov
wrote:
> Hi,
> The current implementation of IPACP doesn't allowed to clone function
> if caller(s) to that function is located in another object. Of course,
> no such problems if we could utilized LTO. And it is very interesting
> to have such functionality of compiler even without LTO. It could be
> changed, if for example we could call to the cloned instance of that
> function from the original instance of function in the function
> prolog:
> Here is what I mean:
>
> int func(int a, .)
> {
> if (a==some_constant)
> func.constprop.0();
The only reasonable way to do this is add value-profiles for incoming arguments
and thus require profile-feedback.
Richard.
> thanks, Dinar.
RFC: IPACP function cloning without LTO
Hi,
The current implementation of IPACP doesn't allowed to clone function
if caller(s) to that function is located in another object. Of course,
no such problems if we could utilized LTO. And it is very interesting
to have such functionality of compiler even without LTO. It could be
changed, if for example we could call to the cloned instance of that
function from the original instance of function in the function
prolog:
Here is what I mean:
int func(int a, .)
{
if (a==some_constant)
func.constprop.0();
thanks, Dinar.
Re: Gcc-4.8 (20130217) dealing with bugfixes in isl
On Tue, Mar 5, 2013 at 8:04 PM, koala01 wrote:
> Hello,
>
> I'm trying to compile the gcc-4.8.0-20130217 snapshot with (eg) the last
> version of isl.
>
> This version has a bug fix which make that isl_version() returns
> "isl-1.11.1", as result that configure script fails to detect isl because it
> try to compile a code like
> int
> main ()
> {
> printf("%s",isl_version());
> if (strncmp (isl_version (), "isl-0.11", strlen ("isl-0.11")) != 0 &&)
> return 1;
>
> ;
> return 0;
> }
>
> of course, this code returns 1 and detection fails.
>
> One possible way to deal with bugfix numbers should to modify the test code
> in something like
> #include
>#include
> int
> main ()
> {
> char *version[8]={};
> strncpy(version, isl_version(),8);
>
> if (strncmp (version, "isl-0.11", strlen ("isl-0.11")) != 0)
Eh? How should that behave any different? strncmp compares at most
strlen("isl-0.11") characters which is an equivalent prefix of isl-0.11.1.
The existing test works for me:
configure:5905: checking for version 0.11 of ISL
configure:5924: gcc -o conftest -g -O2 conftest.c -lisl >&5
configure:5924: $? = 0
configure:5924: ./conftest
configure:5924: $? = 0
configure:5933: result: yes
and I have ISL 0.11.1.
Richard.
> return 1;
>
> ;
> return 0;
> }
> (works if changed directly in configure script)
> What would you thing about idea to integrate such change directly in
> Configure.ac ?
>
> PS: Please excuse my poor english but it isn't my native language
