Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Richard Biener]

On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>> On May 26, 2014, at 2:22 AM, FX  wrote:
>> >> This causes GCC bootstrap to fail on Darwin systems (whose system 
>> >> compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m 
>> >> not sure it’s the right call, see below), I’ve filed a separate report 
>> >> for the bootstrap issue 
>> >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
>> >
>> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, 
>> > bouh ouh”), I’d ask the maintainers to step in. Can we please provide a 
>> > GCC that works for the default darwin setup? Or at least drop darwin as 
>> > secondary target and document the failure?
>>
>> The best coarse of action, post a patch, have it reviewed and put in.
>> Current action, a patch has been posted, the review is outstanding, I’d
>> like to see it put in; though, I am curious why the casts were there in
>> the first place.
>
> Note, haven't added them there, but from what I can test, the casts there
> can serve as a compile time check that the right type is used, e.g.
> unsigned long i;
>
> void
> foo (void)
> {
>   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0" ((unsigned 
> long long) 0));
> }

Ah, interesting.  A not-so-hineous extension then.

> errors out on x86_64 -m32, but compiles fine with -m64, because in the
> latter case the type has the correct size, while in the former case it
> doesn't.  So, perhaps instead of removing the casts we should replace them
> with some kind of static assertions (whether
> extern char foobar[sizeof (arg) == sizeof (UDItype) && 
> __builtin_classify_type (arg) == 1 ? 1 : -1];
> or __builtin_types_compatible_p, or C++ templates for C++, ...

Yeah, a portable (C and C++) static assert would be nice.  And also pushing
this to gmp then.

In the meantime I see nothing wrong in "merging" from GMP.

Richard.

> Jakub

Re: Darwin bootstrap failure following wide int merge

[Richard Sandiford]

Richard Biener  writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>>> On May 26, 2014, at 2:22 AM, FX  wrote:
>>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>>> > compiler is clang-based). Since PR 61146 was resolved as INVALID
>>> > (but I’m not sure it’s the right call, see below), I’ve filed a
>>> > separate report for the bootstrap issue
>>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
>>> >
>>> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s
>>> > fault, bouh ouh”), I’d ask the maintainers to step in. Can we
>>> > please provide a GCC that works for the default darwin setup? Or at
>>> > least drop darwin as secondary target and document the failure?
>>>
>>> The best coarse of action, post a patch, have it reviewed and put in.
>>> Current action, a patch has been posted, the review is outstanding, I’d
>>> like to see it put in; though, I am curious why the casts were there in
>>> the first place.
>>
>> Note, haven't added them there, but from what I can test, the casts there
>> can serve as a compile time check that the right type is used, e.g.
>> unsigned long i;
>>
>> void
>> foo (void)
>> {
>>   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0"
>> ((unsigned long long) 0));
>> }
>
> Ah, interesting.  A not-so-hineous extension then.

In that case, how about just protecting the include with:

#if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))

rather than:

#if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))

so that clang will fail the version check?  At the end of the day we
only really care what happens during stage 2 and 3.  Cross-compilers
built with recentish gccs will still benefit.

Thanks,
Richard

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Richard Biener]

On Wed, May 28, 2014 at 10:24 AM, FX  wrote:
>> Yeah, a portable (C and C++) static assert would be nice.  And also pushing
>> this to gmp then.
>>
>> In the meantime I see nothing wrong in "merging" from GMP.
>
> One question, one comment:
>
> 1. can I count your “I see nothing wrong” as an approval, as in “global 
> reviewers can approve changes to any part of the compiler or associated 
> libraries”?

Well, kind of.  But Jakub is as well, so I don't want to override him.  So
please wait for an ack from Jakub.  I agree with him that the casts
served a purpose and that, if removed, they need to be replaced with
an appropriate assertion measure.

Given that inline asm is a GCC extension calling those casts another
extension from the LLVM side is really odd.  In fact I think the casts
are a very good way of doing this kind of assertions.  Are they documented
in that regard?  If so I'd say it's really really LLVM that should be fixed
and the workaround on the GCC side is to pass that -fhineous-gnu-extensions
flag.

> 2. I think your quotes around “merging” mean you’re not actually thinking of 
> a merge, but for clarification’s sake: GMP’s longlong.h has apparently a long 
> history of its own, and has many differences with GCC’s version. The closest 
> thing to an “upstream” for us would probably be glibc (see the diff 
> attached), from which we last merged on 2014-04-22.

I see.  I suppose the gcc side includes the proposed patch and glibc
still has those casts, right?  In that case there is nothing to merge
from glibc (but to glibc eventually).

Richard.

> Thanks,
> FX
>
>
>

Re: Darwin bootstrap failure following wide int merge

[Richard Biener]

On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
>>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
 On May 26, 2014, at 2:22 AM, FX  wrote:
 >> This causes GCC bootstrap to fail on Darwin systems (whose system
 > compiler is clang-based). Since PR 61146 was resolved as INVALID
 > (but I’m not sure it’s the right call, see below), I’ve filed a
 > separate report for the bootstrap issue
 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
 >
 > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s
 > fault, bouh ouh”), I’d ask the maintainers to step in. Can we
 > please provide a GCC that works for the default darwin setup? Or at
 > least drop darwin as secondary target and document the failure?

 The best coarse of action, post a patch, have it reviewed and put in.
 Current action, a patch has been posted, the review is outstanding, I’d
 like to see it put in; though, I am curious why the casts were there in
 the first place.
>>>
>>> Note, haven't added them there, but from what I can test, the casts there
>>> can serve as a compile time check that the right type is used, e.g.
>>> unsigned long i;
>>>
>>> void
>>> foo (void)
>>> {
>>>   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0"
>>> ((unsigned long long) 0));
>>> }
>>
>> Ah, interesting.  A not-so-hineous extension then.
>
> In that case, how about just protecting the include with:
>
> #if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
>
> rather than:
>
> #if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
>
> so that clang will fail the version check?  At the end of the day we
> only really care what happens during stage 2 and 3.  Cross-compilers
> built with recentish gccs will still benefit.

Works for me (thus, pre-approved with a comment explaining the version
choice).

Thanks,
Richard.

> Thanks,
> Richard

Re: Darwin bootstrap failure following wide int merge

[Richard Biener]

On Wed, May 28, 2014 at 11:40 AM, Richard Biener
 wrote:
> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>  wrote:
>> Richard Biener  writes:
>>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
 On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2:22 AM, FX  wrote:
> >> This causes GCC bootstrap to fail on Darwin systems (whose system
> > compiler is clang-based). Since PR 61146 was resolved as INVALID
> > (but I’m not sure it’s the right call, see below), I’ve filed a
> > separate report for the bootstrap issue
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
> >
> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s
> > fault, bouh ouh”), I’d ask the maintainers to step in. Can we
> > please provide a GCC that works for the default darwin setup? Or at
> > least drop darwin as secondary target and document the failure?
>
> The best coarse of action, post a patch, have it reviewed and put in.
> Current action, a patch has been posted, the review is outstanding, I’d
> like to see it put in; though, I am curious why the casts were there in
> the first place.

 Note, haven't added them there, but from what I can test, the casts there
 can serve as a compile time check that the right type is used, e.g.
 unsigned long i;

 void
 foo (void)
 {
   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0"
 ((unsigned long long) 0));
 }
>>>
>>> Ah, interesting.  A not-so-hineous extension then.
>>
>> In that case, how about just protecting the include with:
>>
>> #if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
>>
>> rather than:
>>
>> #if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
>>
>> so that clang will fail the version check?  At the end of the day we
>> only really care what happens during stage 2 and 3.  Cross-compilers
>> built with recentish gccs will still benefit.
>
> Works for me (thus, pre-approved with a comment explaining the version
> choice).

Btw, testing coverage would ask for && defined (__OPTIMIZE__), too, disabling
that path in stage1 unconditionally even for new GCC.

Richard.

> Thanks,
> Richard.
>
>> Thanks,
>> Richard

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Jakub Jelinek]

On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 10:24 AM, FX  wrote:
> >> Yeah, a portable (C and C++) static assert would be nice.  And also pushing
> >> this to gmp then.
> >>
> >> In the meantime I see nothing wrong in "merging" from GMP.
> >
> > One question, one comment:
> >
> > 1. can I count your “I see nothing wrong” as an approval, as in “global 
> > reviewers can approve changes to any part of the compiler or associated 
> > libraries”?
> 
> Well, kind of.  But Jakub is as well, so I don't want to override him.  So
> please wait for an ack from Jakub.  I agree with him that the casts
> served a purpose and that, if removed, they need to be replaced with
> an appropriate assertion measure.

I think my preference would be to change include/ansidecl.h to:

 /* This macro simplifies testing whether we are using gcc, and if it
is of a particular minimum version. (Both major & minor numbers are
significant.)  This macro will evaluate to 0 if we are not using
gcc at all.*/
 #ifndef GCC_VERSION
+/* Some compilers pretend to be GCC, even when they are not.  */
+#if defined(__clang__) || defined(__INTEL_COMPILER)
+#define GCC_VERSION 0
+#else
 #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
+#endif
 #endif /* GCC_VERSION */

so that we really can trust the GCC_VERSION macro, casts in lhs of inline
asm isn't the only incompatibility clang has.

Any other compilers that define __GNUC__?

Jakub

Re: Darwin bootstrap failure following wide int merge

[Richard Sandiford]

Richard Biener  writes:
> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>  wrote:
>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>  wrote:
>>> Richard Biener  writes:
 On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>> On May 26, 2014, at 2:22 AM, FX  wrote:
>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>> > compiler is clang-based). Since PR 61146 was resolved as INVALID
>> > (but I’m not sure it’s the right call, see below), I’ve filed a
>> > separate report for the bootstrap issue
>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
>> >
>> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s
>> > fault, bouh ouh”), I’d ask the maintainers to step in. Can we
>> > please provide a GCC that works for the default darwin setup? Or at
>> > least drop darwin as secondary target and document the failure?
>>
>> The best coarse of action, post a patch, have it reviewed and put in.
>> Current action, a patch has been posted, the review is outstanding, I’d
>> like to see it put in; though, I am curious why the casts were there in
>> the first place.
>
> Note, haven't added them there, but from what I can test, the casts there
> can serve as a compile time check that the right type is used, e.g.
> unsigned long i;
>
> void
> foo (void)
> {
>   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0"
> ((unsigned long long) 0));
> }

 Ah, interesting.  A not-so-hineous extension then.
>>>
>>> In that case, how about just protecting the include with:
>>>
>>> #if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined 
>>> (__SIZEOF_INT128__))
>>>
>>> rather than:
>>>
>>> #if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined 
>>> (__SIZEOF_INT128__))
>>>
>>> so that clang will fail the version check?  At the end of the day we
>>> only really care what happens during stage 2 and 3.  Cross-compilers
>>> built with recentish gccs will still benefit.
>>
>> Works for me (thus, pre-approved with a comment explaining the version
>> choice).
>
> Btw, testing coverage would ask for && defined (__OPTIMIZE__), too, disabling
> that path in stage1 unconditionally even for new GCC.

Ah, but surely the day is near when we use -O or -Og for stage1?
I've been using -O for a good few years now and it definitely makes
things faster (and without affecting debugging too much -- in the
rare cases where it does affect debugging, a recompile with -g
is very quick).

ATM we get the testing coverage for i686 and ppc32 hosts.  So TBH I'd
prefer to keep it simple and just bump the version number.

Thanks,
Richard

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Richard Biener]

On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek  wrote:
> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>> On Wed, May 28, 2014 at 10:24 AM, FX  wrote:
>> >> Yeah, a portable (C and C++) static assert would be nice.  And also 
>> >> pushing
>> >> this to gmp then.
>> >>
>> >> In the meantime I see nothing wrong in "merging" from GMP.
>> >
>> > One question, one comment:
>> >
>> > 1. can I count your “I see nothing wrong” as an approval, as in “global 
>> > reviewers can approve changes to any part of the compiler or associated 
>> > libraries”?
>>
>> Well, kind of.  But Jakub is as well, so I don't want to override him.  So
>> please wait for an ack from Jakub.  I agree with him that the casts
>> served a purpose and that, if removed, they need to be replaced with
>> an appropriate assertion measure.
>
> I think my preference would be to change include/ansidecl.h to:
>
>  /* This macro simplifies testing whether we are using gcc, and if it
> is of a particular minimum version. (Both major & minor numbers are
> significant.)  This macro will evaluate to 0 if we are not using
> gcc at all.*/
>  #ifndef GCC_VERSION
> +/* Some compilers pretend to be GCC, even when they are not.  */
> +#if defined(__clang__) || defined(__INTEL_COMPILER)
> +#define GCC_VERSION 0
> +#else
>  #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
> +#endif
>  #endif /* GCC_VERSION */
>
> so that we really can trust the GCC_VERSION macro, casts in lhs of inline
> asm isn't the only incompatibility clang has.
>
> Any other compilers that define __GNUC__?

Every one I guess.  ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.

Richard.

> Jakub

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Richard Biener]

On Wed, May 28, 2014 at 12:03 PM, Richard Biener
 wrote:
> On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek  wrote:
>> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, FX  wrote:
>>> >> Yeah, a portable (C and C++) static assert would be nice.  And also 
>>> >> pushing
>>> >> this to gmp then.
>>> >>
>>> >> In the meantime I see nothing wrong in "merging" from GMP.
>>> >
>>> > One question, one comment:
>>> >
>>> > 1. can I count your “I see nothing wrong” as an approval, as in “global 
>>> > reviewers can approve changes to any part of the compiler or associated 
>>> > libraries”?
>>>
>>> Well, kind of.  But Jakub is as well, so I don't want to override him.  So
>>> please wait for an ack from Jakub.  I agree with him that the casts
>>> served a purpose and that, if removed, they need to be replaced with
>>> an appropriate assertion measure.
>>
>> I think my preference would be to change include/ansidecl.h to:
>>
>>  /* This macro simplifies testing whether we are using gcc, and if it
>> is of a particular minimum version. (Both major & minor numbers are
>> significant.)  This macro will evaluate to 0 if we are not using
>> gcc at all.*/
>>  #ifndef GCC_VERSION
>> +/* Some compilers pretend to be GCC, even when they are not.  */
>> +#if defined(__clang__) || defined(__INTEL_COMPILER)
>> +#define GCC_VERSION 0
>> +#else
>>  #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
>> +#endif
>>  #endif /* GCC_VERSION */
>>
>> so that we really can trust the GCC_VERSION macro, casts in lhs of inline
>> asm isn't the only incompatibility clang has.
>>
>> Any other compilers that define __GNUC__?
>
> Every one I guess.  ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.

So if we want to go down that route I'd rather change the configury that
checks whether we are using GCC to be more pedantic and for example
parse $CC --version output (not for the actual version but for whether
$CC is GCC).

Richard.

> Richard.
>
>> Jakub

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Jakub Jelinek]

On Wed, May 28, 2014 at 12:07:41PM +0200, Richard Biener wrote:
> >>  #ifndef GCC_VERSION
> >> +/* Some compilers pretend to be GCC, even when they are not.  */
> >> +#if defined(__clang__) || defined(__INTEL_COMPILER)
> >> +#define GCC_VERSION 0
> >> +#else
> >>  #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
> >> +#endif
> >>  #endif /* GCC_VERSION */
> >>
> >> so that we really can trust the GCC_VERSION macro, casts in lhs of inline
> >> asm isn't the only incompatibility clang has.
> >>
> >> Any other compilers that define __GNUC__?
> >
> > Every one I guess.  ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.

ICC is included in the above check, that is the __INTEL_COMPILER check.

> So if we want to go down that route I'd rather change the configury that
> checks whether we are using GCC to be more pedantic and for example
> parse $CC --version output (not for the actual version but for whether
> $CC is GCC).

include/ is shared among many GCC/binutils/GDB uses, using autoconf macros
there would be nightmare, since you'd need to replicate those tests
everywhere you'd use the header, plus lots of people customize the gcc
--version output and it has changed over the years.

Jakub

Re: Darwin bootstrap failure following wide int merge

[Richard Biener]

On Wed, May 28, 2014 at 11:49 AM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>>  wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>>  wrote:
 Richard Biener  writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek  wrote:
>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>>> On May 26, 2014, at 2:22 AM, FX  wrote:
>>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>>> > compiler is clang-based). Since PR 61146 was resolved as INVALID
>>> > (but I’m not sure it’s the right call, see below), I’ve filed a
>>> > separate report for the bootstrap issue
>>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
>>> >
>>> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s
>>> > fault, bouh ouh”), I’d ask the maintainers to step in. Can we
>>> > please provide a GCC that works for the default darwin setup? Or at
>>> > least drop darwin as secondary target and document the failure?
>>>
>>> The best coarse of action, post a patch, have it reviewed and put in.
>>> Current action, a patch has been posted, the review is outstanding, I’d
>>> like to see it put in; though, I am curious why the casts were there in
>>> the first place.
>>
>> Note, haven't added them there, but from what I can test, the casts there
>> can serve as a compile time check that the right type is used, e.g.
>> unsigned long i;
>>
>> void
>> foo (void)
>> {
>>   asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0"
>> ((unsigned long long) 0));
>> }
>
> Ah, interesting.  A not-so-hineous extension then.

 In that case, how about just protecting the include with:

 #if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined 
 (__SIZEOF_INT128__))

 rather than:

 #if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined 
 (__SIZEOF_INT128__))

 so that clang will fail the version check?  At the end of the day we
 only really care what happens during stage 2 and 3.  Cross-compilers
 built with recentish gccs will still benefit.
>>>
>>> Works for me (thus, pre-approved with a comment explaining the version
>>> choice).
>>
>> Btw, testing coverage would ask for && defined (__OPTIMIZE__), too, disabling
>> that path in stage1 unconditionally even for new GCC.
>
> Ah, but surely the day is near when we use -O or -Og for stage1?
> I've been using -O for a good few years now and it definitely makes
> things faster (and without affecting debugging too much -- in the
> rare cases where it does affect debugging, a recompile with -g
> is very quick).
>
> ATM we get the testing coverage for i686 and ppc32 hosts.  So TBH I'd
> prefer to keep it simple and just bump the version number.

Works for me (though see Jakubs idea on the other thread, so please
wait until we settled on a solution).

Richard.

> Thanks,
> Richard
>

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Jakub Jelinek]

On Wed, May 28, 2014 at 12:03:39PM +0200, Richard Biener wrote:
> > Any other compilers that define __GNUC__?
> 
> Every one I guess.  ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.

For ICC it seems to depend on the ICC version, newer ICC versions
report newer __GNUC_MINOR__.
That said, ICC doesn't error out on the LHS cast for -m32, just
silently drops the cast, so we really can't say it is compatible
in this regard.

unsigned long i;

void
foo (void)
{
  asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0" ((unsigned long 
long) 0));
}

Jakub

Re: Darwin bootstrap failure following wide int merge

[Jakub Jelinek]

On Wed, May 28, 2014 at 12:18:13PM +0200, Richard Biener wrote:
> > ATM we get the testing coverage for i686 and ppc32 hosts.  So TBH I'd
> > prefer to keep it simple and just bump the version number.
> 
> Works for me (though see Jakubs idea on the other thread, so please
> wait until we settled on a solution).

After lengthy IRC discussions, what Richard and I can live with is
&& !defined(__clang__) in this particular case that uses longlong.h
in GCC sources, with a comment why.
If we get too many of these workarounds, we should reconsider.

Jakub

Re: Darwin bootstrap failure following wide int merge

[FX]

> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.

I’ll test this patch and commit if there is no problem. But right now, current 
trunk doesn’t build on x86_64-apple-darwin due to error below. Richard, could 
this be due to your revision 211013?

FX



../../trunk/gcc/rtl.c: In function ‘void cwi_output_hex(FILE*, const_rtx)’:
../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type 
‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
   fprintf (outfile, HOST_WIDE_INT_PRINT_HEX, CWI_ELT (x, --i));
  ^
../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type 
‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type 
‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
 fprintf (outfile, HOST_WIDE_INT_PRINT_PADDED_HEX, CWI_ELT (x, i));
 ^
../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type 
‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
cc1plus: all warnings being treated as errors
make[3]: *** [build/rtl.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Re: How can I generate a new function at compile time?

[Benedikt Huber]

I ported the pass to the fsf trunk. It is built with —enable-checking.
The patch applied with no changes and also the behaviour is the same.
So I probably mess up the cfg somehow.
Can you suggest any strategy for finding the problem that I could use?

/home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
-fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
-funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
/home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
/home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
purge_dead_edges, at cfgrtl.c:3179
 bar (int s, int r, unsigned * t, int * k, int * p, int * l)
 ^
0x681195 purge_dead_edges(basic_block_def*)
../../src/gcc/cfgrtl.c:3179
0xe64d8a find_bb_boundaries
../../src/gcc/cfgbuild.c:522
0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
../../src/gcc/cfgbuild.c:604
0x66e689 execute
../../src/gcc/cfgexpand.c:5905
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Best regards,
Benedikt

On 27 May 2014, at 17:35, Benedikt Huber  
wrote:

> 
> On 27 May 2014, at 17:25, Richard Biener  wrote:
> 
>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>  wrote:
>>> 
>>> On 27 May 2014, at 17:09, Richard Biener  wrote:
>>> 
 On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
  wrote:
> (Sorry for the duplicate.)
> 
> I managed to pass the needed parameters to the generated function.
> However I cannot pin down the reason why the compilation fails.
> It seems that the cfg is somehow broken, but I cannot tell how.
> Do you have any debugging hints?
> 
> As far as I can tell, the cfg is changed during the generation of the 
> preheader
> (I do this to find the entry block easily.)
> and in the function move_sese_region_to_fn.
> 
> I noticed that after pass 058t.copyrename2 the original function bar 
> disappears
> and the new function is replaced by _GLOBAL__N_bar.constprop, could this 
> have
> anything to do with the problem?
 
 Unlikely.  You can disable that by using -fno-ipa-cp.
 
> The pass runs just after the construction of cfg,  outline.c.011t.cfg.
> 
> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src -c 
> -fdump-tree-all-details -fdump-ipa-all-details -fdump-rtl-all-details 
> -funinline-innermost-loops -Wall -Wextra 
> /home/bhuber/sandbox/try/outline.c
> /home/bhuber/sandbox/try/outline.c: In function 
> '_GLOBAL__N_bar.constprop':
> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
> purge_dead_edges, at cfgrtl.c:3183
 
 the line doesn't match anything that would ICE on current trunk, but I 
 suppose
 it's the single_succ_p assert that triggers?
>>> Yes, that is right, it is
>>> 
>>> gcc_assert (single_succ_p (bb));
>>> 
 
 Either you really got until RTL generation or somehow cfgrtl cfg hooks are
 still active while you are working in your pass.
>>> 
>>> The pass that fails, according to the dump files is outline.c.174r.expand
>>> So it already tries to generate RTL.
>>> My problem is that there are so many passes in
>>> between, that I do not know where to start looking.
>>> Any idea?
>> 
>> What code-base are you developing on?  Do you build with checking
>> enabled (--enable-checking, the default on trunk but not on release 
>> branches).
> 
> It is a linaro branch, but I am going to port the pass to the fsf trunk and 
> see
> whether the behaviour changes.
> 
> Best regards,
> Benedikt
> 
>> 
>> Richard.
>> 
 
 Richard.
 
> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
> ^
> 0x67e7c4 purge_dead_edges(basic_block_def*)
> ../../src/gcc/cfgrtl.c:3183
> 0xe5a0d6 find_bb_boundaries
> ../../src/gcc/cfgbuild.c:522
> 0xe5a0d6 find_many_sub_basic_blocks(simple_bitmap_def*)
> ../../src/gcc/cfgbuild.c:604
> 0x66c0f5 execute
> ../../src/gcc/cfgexpand.c:5873
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> I attach the transformation pass and the small example program.
> 
> Thank you again for the help,
> Benedikt
> 
> P.s. I am aware that this transformation is not safe in general,
>  however in this case it should work.
> 

Re: Darwin bootstrap failure following wide int merge

[Richard Biener]

On Wed, May 28, 2014 at 3:15 PM, FX  wrote:
>> After lengthy IRC discussions, what Richard and I can live with is
>> && !defined(__clang__) in this particular case that uses longlong.h
>> in GCC sources, with a comment why.
>
> I’ll test this patch and commit if there is no problem. But right now, 
> current trunk doesn’t build on x86_64-apple-darwin due to error below. 
> Richard, could this be due to your revision 211013?

Hum, yeah.  But why does it even warn if sizeof (long) == sizeof (long long)?
I suppose casting the result of CWI_ELT () to uint64_t fixes this.  Do
similar errors happen elsewhere?

(the hex printfs expect unsigned types but CWI_ELT returns a signed
HWI)

Richard.

> FX
>
>
>
> ../../trunk/gcc/rtl.c: In function ‘void cwi_output_hex(FILE*, const_rtx)’:
> ../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type 
> ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
>fprintf (outfile, HOST_WIDE_INT_PRINT_HEX, CWI_ELT (x, --i));
>   ^
> ../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type 
> ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
> ../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type 
> ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
>  fprintf (outfile, HOST_WIDE_INT_PRINT_PADDED_HEX, CWI_ELT (x, i));
>  ^
> ../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type 
> ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=]
> cc1plus: all warnings being treated as errors
> make[3]: *** [build/rtl.o] Error 1
> make[2]: *** [all-stage2-gcc] Error 2
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
>
>
>

Re: How can I generate a new function at compile time?

[Richard Biener]

On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
 wrote:
> I ported the pass to the fsf trunk. It is built with —enable-checking.
> The patch applied with no changes and also the behaviour is the same.
> So I probably mess up the cfg somehow.
> Can you suggest any strategy for finding the problem that I could use?
>
> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
> -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
> purge_dead_edges, at cfgrtl.c:3179
>  bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>  ^
> 0x681195 purge_dead_edges(basic_block_def*)
> ../../src/gcc/cfgrtl.c:3179
> 0xe64d8a find_bb_boundaries
> ../../src/gcc/cfgbuild.c:522
> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
> ../../src/gcc/cfgbuild.c:604
> 0x66e689 execute
> ../../src/gcc/cfgexpand.c:5905
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

Well, look at the CFG and see if it makes sense and why it expects
a single successor and why there is none.  Basically, work back
from the ICE ...

Richard.

> Best regards,
> Benedikt
>
> On 27 May 2014, at 17:35, Benedikt Huber 
>  wrote:
>
>>
>> On 27 May 2014, at 17:25, Richard Biener  wrote:
>>
>>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>>  wrote:

 On 27 May 2014, at 17:09, Richard Biener  
 wrote:

> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>  wrote:
>> (Sorry for the duplicate.)
>>
>> I managed to pass the needed parameters to the generated function.
>> However I cannot pin down the reason why the compilation fails.
>> It seems that the cfg is somehow broken, but I cannot tell how.
>> Do you have any debugging hints?
>>
>> As far as I can tell, the cfg is changed during the generation of the 
>> preheader
>> (I do this to find the entry block easily.)
>> and in the function move_sese_region_to_fn.
>>
>> I noticed that after pass 058t.copyrename2 the original function bar 
>> disappears
>> and the new function is replaced by _GLOBAL__N_bar.constprop, could this 
>> have
>> anything to do with the problem?
>
> Unlikely.  You can disable that by using -fno-ipa-cp.
>
>> The pass runs just after the construction of cfg,  outline.c.011t.cfg.
>>
>> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src -c 
>> -fdump-tree-all-details -fdump-ipa-all-details -fdump-rtl-all-details 
>> -funinline-innermost-loops -Wall -Wextra 
>> /home/bhuber/sandbox/try/outline.c
>> /home/bhuber/sandbox/try/outline.c: In function 
>> '_GLOBAL__N_bar.constprop':
>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
>> purge_dead_edges, at cfgrtl.c:3183
>
> the line doesn't match anything that would ICE on current trunk, but I 
> suppose
> it's the single_succ_p assert that triggers?
 Yes, that is right, it is

 gcc_assert (single_succ_p (bb));

>
> Either you really got until RTL generation or somehow cfgrtl cfg hooks are
> still active while you are working in your pass.

 The pass that fails, according to the dump files is outline.c.174r.expand
 So it already tries to generate RTL.
 My problem is that there are so many passes in
 between, that I do not know where to start looking.
 Any idea?
>>>
>>> What code-base are you developing on?  Do you build with checking
>>> enabled (--enable-checking, the default on trunk but not on release 
>>> branches).
>>
>> It is a linaro branch, but I am going to port the pass to the fsf trunk and 
>> see
>> whether the behaviour changes.
>>
>> Best regards,
>> Benedikt
>>
>>>
>>> Richard.
>>>
>
> Richard.
>
>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>> ^
>> 0x67e7c4 purge_dead_edges(basic_block_def*)
>> ../../src/gcc/cfgrtl.c:3183
>> 0xe5a0d6 find_bb_boundaries
>> ../../src/gcc/cfgbuild.c:522
>> 0xe5a0d6 find_many_sub_basic_blocks(simple_bitmap_def*)
>> ../../src/gcc/cfgbuild.c:604
>> 0x66c0f5 execute
>> ../../src/gcc/cfgexpand.c:5873
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>>
>> I attach the transformation pass and the small example program.
>>
>> Thank you again for the help,
>> Benedikt
>>
>> P.s. I am aware that this transformation is not safe in general,
>>  however in this

Re: Darwin bootstrap failure following wide int merge

[Jakub Jelinek]

On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 3:15 PM, FX  wrote:
> >> After lengthy IRC discussions, what Richard and I can live with is
> >> && !defined(__clang__) in this particular case that uses longlong.h
> >> in GCC sources, with a comment why.
> >
> > I’ll test this patch and commit if there is no problem. But right now, 
> > current trunk doesn’t build on x86_64-apple-darwin due to error below. 
> > Richard, could this be due to your revision 211013?
> 
> Hum, yeah.  But why does it even warn if sizeof (long) == sizeof (long long)?

Because using the right format strings is important for portability.

> I suppose casting the result of CWI_ELT () to uint64_t fixes this.  Do
> similar errors happen elsewhere?
> 
> (the hex printfs expect unsigned types but CWI_ELT returns a signed
> HWI)

I think the sign shouldn't be a problem, but perhaps there is a mismatch
between HOST_WIDE_INT definition and HOST_WIDE_INT_PRINT_HEX?

Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
or not, but using PRIx64 etc. unconditionally is just wrong, either
HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
not, and then you should keep using what has been used in the past,
different macros depending on how HOST_WIDE_INT is defined.

Jakub

Re: Darwin bootstrap failure following wide int merge

[Jakub Jelinek]

On Wed, May 28, 2014 at 04:00:32PM +0200, Jakub Jelinek wrote:
> Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
> or not, but using PRIx64 etc. unconditionally is just wrong, either
> HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
> not, and then you should keep using what has been used in the past,
> different macros depending on how HOST_WIDE_INT is defined.

And, note that even the fallback PRI*64 definitions if not defined in system
headers already probably need to depend on autoconf test finding out whether
uint64_t is unsigned long or unsigned long long (and failing otherwise,
unless PRI*64 is defined in the headers).  Guess the test can easily try to
compile some proglet with a template to find out what uint64_t is.

Jakub

TARGET_MACRO_FUSION_PAIR for something besides compare-and-branch ?

[Kyrill Tkachov]

Hi all,

The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used 
to tell the scheduler that two insns should not be scheduled apart. It 
doesn't specify what kinds of insns those can be.


Yet from what I can see in sched-deps.c it can only be used on compares 
and conditional branches,

as implemented in i386.

Say I want to specify two other types of instruction that I want to 
force together, would it be worth

generalising the TARGET_MACRO_FUSION_PAIR usage to achieve that?

Thanks,
Kyrill

Re: Darwin bootstrap failure following wide int merge

[FX]

> I suppose casting the result of CWI_ELT () to uint64_t fixes this.  Do
> similar errors happen elsewhere?

I don’t think you can cast to uint64_t, as host wide int might be some other 
type, no?

There are others:

../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’:
../../trunk/gcc/print-rtl.c:385:62: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
  fprintf (outfile, HOST_WIDE_INT_PRINT_DEC, XWINT (in_rtx, i));
  ^
../../trunk/gcc/print-rtl.c:385:62: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
../../trunk/gcc/print-rtl.c:388:48: error: format ‘%llx’ expects argument of 
type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ 
[-Werror=format=]
  (unsigned HOST_WIDE_INT) XWINT (in_rtx, i));
^
../../trunk/gcc/print-rtl.c:388:48: error: format ‘%llx’ expects argument of 
type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ 
[-Werror=format=]
../../trunk/gcc/genemit.c: In function ‘void gen_exp(rtx, rtx_code, char*)’:
../../trunk/gcc/genemit.c:200:49: error: format ‘%lld’ expects argument of type 
‘long long int’, but argument 2 has type ‘long int’ [-Werror=format=]
printf (HOST_WIDE_INT_PRINT_DEC_C, INTVAL (x));
 ^
../../trunk/gcc/genemit.c:200:49: error: format ‘%lld’ expects argument of type 
‘long long int’, but argument 2 has type ‘long int’ [-Werror=format=]
../../trunk/gcc/genattrtab.c: In function ‘unsigned int write_test_expr(FILE*, 
rtx, unsigned int, int)’:
../../trunk/gcc/genattrtab.c:3758:61: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
   fprintf (outf, HOST_WIDE_INT_PRINT_DEC, XWINT (exp, 0));
 ^
../../trunk/gcc/genattrtab.c:3758:61: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
../../trunk/gcc/genattrtab.c: In function ‘void write_attr_value(FILE*, 
attr_desc*, rtx)’:
../../trunk/gcc/genattrtab.c:4350:61: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
   fprintf (outf, HOST_WIDE_INT_PRINT_DEC, INTVAL (value));
 ^
../../trunk/gcc/genattrtab.c:4350:61: error: format ‘%lld’ expects argument of 
type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]

Re: Darwin bootstrap failure following wide int merge

[FX]

> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.
> If we get too many of these workarounds, we should reconsider.

Committed as revision 211023, after bootstrap on x86_64-apple-darwin13.

Thanks!
FX



patch
Description: application/applefile


CL
Description: Binary data

Re: TARGET_MACRO_FUSION_PAIR for something besides compare-and-branch ?

[Alexander Monakov]

On Wed, 28 May 2014, Kyrill Tkachov wrote:

> Hi all,
> 
> The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
> tell the scheduler that two insns should not be scheduled apart. It doesn't
> specify what kinds of insns those can be.
> 
> Yet from what I can see in sched-deps.c it can only be used on compares and
> conditional branches, as implemented in i386.

Please note that it's not only restricted to conditional branches, but also to
keeping the instructions together if they were consecutive in the first place
(i.e. it does not try to move a compare insn closer to the branch).

Doing it that way allowed to solve the issue at hand at that time without a
separate scan of the whole RTL instruction stream.
 
> Say I want to specify two other types of instruction that I want to force
> together, would it be worth generalising the TARGET_MACRO_FUSION_PAIR usage
> to achieve that?

I'd say yes, but that would be the least of the problems; the more important
question is how to trigger the hook (you probably want to integrate it into
the existing scheduler dependencies evaluation loop rather than adding a new
loop just to discover macro-fusable pairs).  You'll also have to invent
something new if you want to move non-consecutive fusable insns together if
they are apart.

HTH.
Alexander

Re: TARGET_MACRO_FUSION_PAIR for something besides compare-and-branch ?

[Kyrill Tkachov]

On 28/05/14 17:36, Alexander Monakov wrote:


On Wed, 28 May 2014, Kyrill Tkachov wrote:


Hi all,

The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
tell the scheduler that two insns should not be scheduled apart. It doesn't
specify what kinds of insns those can be.

Yet from what I can see in sched-deps.c it can only be used on compares and
conditional branches, as implemented in i386.

Please note that it's not only restricted to conditional branches, but also to
keeping the instructions together if they were consecutive in the first place
(i.e. it does not try to move a compare insn closer to the branch).

Doing it that way allowed to solve the issue at hand at that time without a
separate scan of the whole RTL instruction stream.
  

Say I want to specify two other types of instruction that I want to force
together, would it be worth generalising the TARGET_MACRO_FUSION_PAIR usage
to achieve that?

Hi Alexander,
Thanks for the insight,


I'd say yes, but that would be the least of the problems; the more important
question is how to trigger the hook (you probably want to integrate it into
the existing scheduler dependencies evaluation loop rather than adding a new
loop just to discover macro-fusable pairs).


Yeah, I was afraid that would be the case.


  You'll also have to invent
something new if you want to move non-consecutive fusable insns together if
they are apart.


Seems to me that TARGET_SCHED_REORDER would be a better fit for that.

Kyrill



HTH.
Alexander

gcc-4.9-20140528 is now available

[gccadmin]

Snapshot gcc-4.9-20140528 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 211035

You'll find:

 gcc-4.9-20140528.tar.bz2 Complete GCC

  MD5=eb9e3374aadd7a9a3f9352aedeb6f096
  SHA1=d6e9eaa2dab0bc449e85b0293b873e49bf808524

Diffs from 4.9-20140521 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.