ICE in gcc.dg/pr77834.c test for MIPS

[Toma Tabacu]

Hello,

I have been looking into an ICE triggered by the gcc.dg/pr77834.c test for
MIPS targets (filed as PR 79150).

It turns out that it is unrelated to the fix for PR 77834, as the code from the
test case triggers the same ICE even without those changes.

It is caused by "gcc_assert (!JUMP_P (last))" in
commit_one_edge_insertion (gcc/cfgrtl.c:2059-2077):

  if (returnjump_p (last))
{
  /* ??? Remove all outgoing edges from BB and add one for EXIT.
 This is not currently a problem because this only happens
 for the (single) epilogue, which already has a fallthru edge
 to EXIT.  */

  e = single_succ_edge (bb);
  gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
  && single_succ_p (bb) && (e->flags & EDGE_FALLTHRU));

  e->flags &= ~EDGE_FALLTHRU;
  emit_barrier_after (last);

  if (before)
delete_insn (before);
}
  else
gcc_assert (!JUMP_P (last));

The test case uses the vector_size __attribute__ to define a vector type.

The trouble starts in insert_partition_copy_on_edge (gcc/tree-outof-ssa.c:239),
which calls emit_partition_copy. For vectors of vector_size >=32,
emit_partition_copy will call emit_block_move which will eventually end up
calling mips_expand_block_move (gcc/config/mips.c:8103), which generates a
looped block move for a vector_size >32 for MIPS32 or >64 for MIPS64.

Fast-forwarding to commit_one_edge_insertion, if an edge has a looped block 
move,
"last" will point to the conditional jump_insn from the looped block move,
which will fail the "returnjump_p (last)" condition and, because it is a
jump_insn, it will trigger the "!JUMP_P (last)" assert.

I can't come up with a reason for this assert and this code hasn't been touched
in a long time, so I'm not sure it's necessary. It looks to me like it was
added more out of habit rather than for a specific reason.

I ran the testsuite (only for the MIPS target and only GCC tests) without the
problematic assert and there were no extra failures.

I would be grateful for any help with this.

Regards,
Toma Tabacu

Re: ICE in gcc.dg/pr77834.c test for MIPS

[Segher Boessenkool]

Hello Toma,

On Thu, Feb 16, 2017 at 02:39:12PM +, Toma Tabacu wrote:
> It is caused by "gcc_assert (!JUMP_P (last))" in
> commit_one_edge_insertion (gcc/cfgrtl.c:2059-2077):
> 
>   if (returnjump_p (last))
> {
>   /* ??? Remove all outgoing edges from BB and add one for EXIT.
>This is not currently a problem because this only happens
>for the (single) epilogue, which already has a fallthru edge
>to EXIT.  */
> 
>   e = single_succ_edge (bb);
>   gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
> && single_succ_p (bb) && (e->flags & EDGE_FALLTHRU));
> 
>   e->flags &= ~EDGE_FALLTHRU;
>   emit_barrier_after (last);
> 
>   if (before)
>   delete_insn (before);
> }
>   else
> gcc_assert (!JUMP_P (last));

> I can't come up with a reason for this assert and this code hasn't been 
> touched
> in a long time, so I'm not sure it's necessary. It looks to me like it was
> added more out of habit rather than for a specific reason.

This happens when you have inserted code ending in a jump on an edge.
This then will need updating of the CFG, and this code does not know
how to do that.


Segher

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Thu, Feb 16, 2017 at 04:25:04PM +1100, Patrick Oppenlander wrote:
> >It's not true though; we still support all those cores, just not the
> >VLE extension (we never have), and I propose GCC 7 will drop the SPE
> >extension as well -- not all other support we have for those cores.
> >They will have to use soft float, alas.
> 
> Will the SPFP APU still be supported?

"SPE.Embedded Float Scalar Single" is part of SPE, so support for it
will be removed.  Sorry.


Segher

New page "nvptx" in the GCC wiki to document --target=nvptx-none configurations

[Thomas Schwinge]

Hi!

I created a new page "nvptx" in the GCC wiki to document
--target=nvptx-none configurations: .


Grüße
 Thomas

Re: Obsolete powerpc*-*-*spe*

[Sandra Loosemore]

On 02/13/2017 08:07 PM, Segher Boessenkool wrote:

Hi all,

I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
the spe.h installed header file, all the __builtin_spe* intrinsics, the
-mfloat-gprs= command-line option, and the support for the SPE ABIs.

No one has properly tested these targets in a long time (the latest
testresults I could find are from July 2015, >1000 failures), and the
SPE support makes a lot of code much more complex.

Any objections to this obsoletion?  GCC 7 will then be the last release
with support for SPE (it will need --enable-obsolete to build these
targets), and we will delete the SPE support during GCC 8 development.


Can I ask that we hold off a bit before making a decision on this?  I am 
pretty sure that some of Mentor's automotive customers use PowerPC 
processors with SPE support, but this is not my own area of expertise or 
responsibility and I need to chase down the right people in other 
groups, argue that we need to pick up the ball on maintenance if it's 
important to our customers, etc.


I don't think it's really appropriate to force this decision on the GCC 
community without giving other folks adequate notice that we can figure 
out what to do about it, anyway.  Maybe obsolete it if no maintainer can 
be found in 30 days, or something like that?


-Sandra

Re: Obsolete powerpc*-*-*spe*

[Segher Boessenkool]

On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:
> >I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> >the spe.h installed header file, all the __builtin_spe* intrinsics, the
> >-mfloat-gprs= command-line option, and the support for the SPE ABIs.
> >
> >No one has properly tested these targets in a long time (the latest
> >testresults I could find are from July 2015, >1000 failures), and the
> >SPE support makes a lot of code much more complex.
> >
> >Any objections to this obsoletion?  GCC 7 will then be the last release
> >with support for SPE (it will need --enable-obsolete to build these
> >targets), and we will delete the SPE support during GCC 8 development.
> 
> Can I ask that we hold off a bit before making a decision on this?

Of course, that is what we're doing in any case.

Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
we *can* remove it in GCC 8; we do not have to.  You have plenty of time
to find some way to keep SPE support in GCC.  The obsoletion notice _is_
the advance warning you're asking for.

The gcc-7/changes.html text I'll propose later says:


  Support for a number of older systems and recently
  unmaintained or untested target ports of GCC has been declared
  obsolete in GCC 7.  Unless there is activity to revive them, the
  next release of GCC will have their sources permanently
  removed.

  The following ports for individual systems on
  particular architectures have been obsoleted:

  
PowerPC SPE (powerpc*-*-*spe*) as announced
https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html";>
here.
  
  


Segher

gcc-6-20170216 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 245520

You'll find:

 gcc-6-20170216.tar.bz2   Complete GCC

  MD5=9c5519ac98b6c28236c4ce0c5cc5d8c8
  SHA1=175d76886985b89fb8f8b9631717f5806ad645ec

Diffs from 6-20170209 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
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: Obsolete powerpc*-*-*spe*

[Sandra Loosemore]

On 02/16/2017 03:19 PM, Segher Boessenkool wrote:

On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:

I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
the spe.h installed header file, all the __builtin_spe* intrinsics, the
-mfloat-gprs= command-line option, and the support for the SPE ABIs.

No one has properly tested these targets in a long time (the latest
testresults I could find are from July 2015, >1000 failures), and the
SPE support makes a lot of code much more complex.

Any objections to this obsoletion?  GCC 7 will then be the last release
with support for SPE (it will need --enable-obsolete to build these
targets), and we will delete the SPE support during GCC 8 development.


Can I ask that we hold off a bit before making a decision on this?


Of course, that is what we're doing in any case.

Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
we *can* remove it in GCC 8; we do not have to.  You have plenty of time
to find some way to keep SPE support in GCC.  The obsoletion notice _is_
the advance warning you're asking for.

The gcc-7/changes.html text I'll propose later says:


   Support for a number of older systems and recently
   unmaintained or untested target ports of GCC has been declared
   obsolete in GCC 7.  Unless there is activity to revive them, the
   next release of GCC will have their sources permanently
   removed.

   The following ports for individual systems on
   particular architectures have been obsoleted:

   
 PowerPC SPE (powerpc*-*-*spe*) as announced
 https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html";>
 here.
   
   


I understand that you're not going to remove the SPE support tomorrow. 
But that notice is going to scare users who depend on it, and I think 
it's not a good idea to scare users unnecessarily.  AFAIK GCC 7 is not 
going to be released tomorrow, either, so why not give folks a little 
more time to look into alternatives to announcing the support is being 
obsoleted?  IMO that should only be done when new maintainers have been 
solicited and nobody has come forward.


-Sandra

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

On Thu, Feb 16, 2017 at 3:53 PM, Sandra Loosemore
 wrote:
> On 02/16/2017 03:19 PM, Segher Boessenkool wrote:
>>
>> On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote:

 I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
 the spe.h installed header file, all the __builtin_spe* intrinsics, the
 -mfloat-gprs= command-line option, and the support for the SPE ABIs.

 No one has properly tested these targets in a long time (the latest
 testresults I could find are from July 2015, >1000 failures), and the
 SPE support makes a lot of code much more complex.

 Any objections to this obsoletion?  GCC 7 will then be the last release
 with support for SPE (it will need --enable-obsolete to build these
 targets), and we will delete the SPE support during GCC 8 development.
>>>
>>>
>>> Can I ask that we hold off a bit before making a decision on this?
>>
>>
>> Of course, that is what we're doing in any case.
>>
>> Note that obsoleting it in GCC 7 means GCC 7 will still work, and that
>> we *can* remove it in GCC 8; we do not have to.  You have plenty of time
>> to find some way to keep SPE support in GCC.  The obsoletion notice _is_
>> the advance warning you're asking for.
>>
>> The gcc-7/changes.html text I'll propose later says:
>>
>>
>>Support for a number of older systems and recently
>>unmaintained or untested target ports of GCC has been declared
>>obsolete in GCC 7.  Unless there is activity to revive them, the
>>next release of GCC will have their sources permanently
>>removed.
>>
>>The following ports for individual systems on
>>particular architectures have been obsoleted:
>>
>>
>>  PowerPC SPE (powerpc*-*-*spe*) as announced
>>  https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html";>
>>  here.
>>
>>
>
>
> I understand that you're not going to remove the SPE support tomorrow. But
> that notice is going to scare users who depend on it, and I think it's not a
> good idea to scare users unnecessarily.  AFAIK GCC 7 is not going to be
> released tomorrow, either, so why not give folks a little more time to look
> into alternatives to announcing the support is being obsoleted?  IMO that
> should only be done when new maintainers have been solicited and nobody has
> come forward.

Sandra,

This is not a new issue.  The maintainer did not suddenly resign last
week.  There have been numerous efforts to reach out to the SPE
community for over a *decade*, cajoling them to step up with
maintenance for the port.  I am glad that this notice of obsolescence
has focused more attention on the long-standing problem.

Thanks, David