[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.10.0

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.preudhomme at arm dot com

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1]))

smells like

2014-05-23  Thomas Preud'homme  <thomas.preudhomme@arm.com>

        PR tree-optimization/54733
        * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
...

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The load may be converted to unaligned - does sparc-solaris properly handle
unaligned (non-vector) loads?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-05-26
     Ever confirmed|0                           |1

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The load may be converted to unaligned - does sparc-solaris properly handle
> unaligned (non-vector) loads?

No, all SPARC-based platforms are strict-alignment.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
> gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1]))
>
> smells like
>
> 2014-05-23  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>
>         PR tree-optimization/54733
>         * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
> ...

I've now confirmed that this patch is indeed the culprit.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
Thomas,

btw, I noticed that you use duplicate dg-options in
gcc.dg/optimize-bswapsi-[12].c.  Please use dg-additional-options for
the s390-*-* case to avoid the duplication.

Thanks.
        Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #6 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
Sure, I'll push a patch for this as soon as I finish fixing the regressions
that poped up due to the change I made to the bswap pass.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
>> --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
>> gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1]))
>>
>> smells like
>>
>> 2014-05-23  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>>
>>         PR tree-optimization/54733
>>         * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
>> ...
>
> I've now confirmed that this patch is indeed the culprit.

Thomas, any progress on fixing this regression?  SPARC bootstrap is
broken for a week now.

Thanks.
        Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Sure, I'll push a patch for this as soon as I finish fixing the regressions
> that poped up due to the change I made to the bswap pass.

While you're at it, could you change all the references in the code (as well as
the ChangeLog) to "host endianness", which is mightily confusing in a compiler?

By definition a compiler generates code for a target, not for a host.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #9 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
Sorry, I didn't realize it was preventing bootstrap. I have a small patch that
disable the optimization for STRICT_ALIGNMENT target but was reluctant to use
it as is because this effectively disable this optimization for ARM. But given
the situation the patch could be applied temporarily to avoid the bootstrap
failure and a better solution be commited later.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #10 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
So I am testing the patch right now and should be able to send it tomorrow.
However, the code already shall already mark the load with the actual alignment
the access is being done with. Therefore it seems to me that something in the
backend fails to split the unaligned load into several aligned load. Could you
break after the line align = get_object_alignment (src); in
tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage 1 (I suppose
it breaks in stage 2)?

What does print align gives? What about print load_type->type_common.align ?

Best regards.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So I am testing the patch right now and should be able to send it tomorrow.
> However, the code already shall already mark the load with the actual
> alignment the access is being done with. Therefore it seems to me that
> something in the backend fails to split the unaligned load into several
> aligned load.

But what would be the point of this round trip exactly?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #11)
> > So I am testing the patch right now and should be able to send it tomorrow.
> > However, the code already shall already mark the load with the actual
> > alignment the access is being done with. Therefore it seems to me that
> > something in the backend fails to split the unaligned load into several
> > aligned load.
> 
> But what would be the point of this round trip exactly?

I'd say

Index: tree-ssa-math-opts.c
===================================================================
--- tree-ssa-math-opts.c        (revision 211170)
+++ tree-ssa-math-opts.c        (working copy)
@@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_
       unsigned align;

       align = get_object_alignment (src);
-      if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
+      if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
+         && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
        return false;

       /*  Compute address to load from and cast according to the size

is obvious (and pre-approved).

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #10)
> So I am testing the patch right now and should be able to send it tomorrow.
> However, the code already shall already mark the load with the actual
> alignment the access is being done with. Therefore it seems to me that
> something in the backend fails to split the unaligned load into several
> aligned load. Could you break after the line align = get_object_alignment
> (src); in tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage
> 1 (I suppose it breaks in stage 2)?
> 
> What does print align gives? What about print load_type->type_common.align ?
> 
> Best regards.

The question is more like what happens in expand_assignment, that is, why
don't we go the extract_bit_field codepath.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> (In reply to Eric Botcazou from comment #11)
> > > So I am testing the patch right now and should be able to send it tomorrow.
> > > However, the code already shall already mark the load with the actual
> > > alignment the access is being done with. Therefore it seems to me that
> > > something in the backend fails to split the unaligned load into several
> > > aligned load.
> > 
> > But what would be the point of this round trip exactly?
> 
> I'd say
> 
> Index: tree-ssa-math-opts.c
> ===================================================================
> --- tree-ssa-math-opts.c        (revision 211170)
> +++ tree-ssa-math-opts.c        (working copy)
> @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_
>        unsigned align;
>  
>        align = get_object_alignment (src);
> -      if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
> +      if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
> +         && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
>         return false;
>  
>        /*  Compute address to load from and cast according to the size
> 
> is obvious (and pre-approved).

obvious as a workaround, that is.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, unpatched and with a cross to sparc-linux (didn't figure out a working
solaris triplet that builds) and

unsigned int foo (unsigned short *x)
{
  return x[0] << 16 | x[1];
}

I see

32 bit load in host endianness found at: _8 = (int) load_dst_11;
foo (short unsigned int * x)
{
  short unsigned int _3;
  int _4;
  int _5;
  short unsigned int _6;
  int _7;
  int _8;
  unsigned int _9;
  short unsigned int * load_src_10;
  unsigned int load_dst_11;

  <bb 2>:
  _3 = *x_2(D);
  _4 = (int) _3;
  _5 = _4 << 16;
  _6 = MEM[(short unsigned int *)x_2(D) + 2B];
  _7 = (int) _6;
  load_src_10 = x_2(D);
  load_dst_11 = MEM[(short unsigned int *)load_src_10];
  _8 = (int) load_dst_11;
  _9 = (unsigned int) _8;
  return _9;

expanding from

  <bb 2>:
  load_dst_11 = MEM[(short unsigned int *)x_2(D)];
  return load_dst_11;

gets you

foo:
        lduh    [%o0], %g1
        lduh    [%o0+2], %o0
        sll     %g1, 16, %g1
        jmp     %o7+8
         or     %o0, %g1, %o0

which looks perfect to me.

So it must be sth else that breaks the libjava case?

Can someone please provide preprocessed source for jcf-parse.c and
point out the error in the assembly at least?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> unsigned int foo (unsigned short *x)
> {
>   return x[0] << 16 | x[1];
> }
> 
> [...]
> gets you
> 
> foo:
>         lduh    [%o0], %g1
>         lduh    [%o0+2], %o0
>         sll     %g1, 16, %g1
>         jmp     %o7+8
>          or     %o0, %g1, %o0
> 
> which looks perfect to me.

Indeed, but after having gone through a perfectly useless transformation and
wasted cycles.  This reminds me of the ipa-split + inlining round trip.

Really SPARC machines aren't fast enough to allow such a silliness...

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #17 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to Richard Biener from comment #12)
> 
> I'd say
> 
> Index: tree-ssa-math-opts.c
> ===================================================================
> --- tree-ssa-math-opts.c        (revision 211170)
> +++ tree-ssa-math-opts.c        (working copy)
> @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_
>        unsigned align;
>  
>        align = get_object_alignment (src);
> -      if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
> +      if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
> +         && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
>         return false;
>  
>        /*  Compute address to load from and cast according to the size
> 
> is obvious (and pre-approved).

Alright but tests need to be modified to add an xfail for target impacted by
this. I did such a change and also rewrote the tests to use aligned variable as
much as possible so that they are more meaningful on STRICT_ALIGNMENT targets.
I'll post it for review today (at least for the changes in the testsuite).

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #18 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to Eric Botcazou from comment #16)
> > unsigned int foo (unsigned short *x)
> > {
> >   return x[0] << 16 | x[1];
> > }
> > 
> > [...]
> > gets you
> > 
> > foo:
> >         lduh    [%o0], %g1
> >         lduh    [%o0+2], %o0
> >         sll     %g1, 16, %g1
> >         jmp     %o7+8
> >          or     %o0, %g1, %o0
> > 
> > which looks perfect to me.
> 
> Indeed, but after having gone through a perfectly useless transformation and
> wasted cycles.  This reminds me of the ipa-split + inlining round trip.
> 
> Really SPARC machines aren't fast enough to allow such a silliness...

Fair enough but the information about alignment is only available late in the
pass so that most of the code is already executed. Only when the whole OR
expression has been processed do we know what is the lowest address and the
range of the memory access and therefore whether that access is aligned or not.

Also if the expression was loading a 32 bit value byte by byte then the
transformation would be useful. I'm already working on a patch to add a cost
model but this will just add more code to execute before taking the decision.
It will however prevent rewriting statements if the result will execute slower
on the target.

Maybe a better solution for sparc would be to add a switch for this pass and
disable it by default on sparc. What do you think about that?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
> (In reply to Eric Botcazou from comment #11)
>> > So I am testing the patch right now and should be able to send it tomorrow.
>> > However, the code already shall already mark the load with the actual
>> > alignment the access is being done with. Therefore it seems to me that
>> > something in the backend fails to split the unaligned load into several
>> > aligned load.
>> 
>> But what would be the point of this round trip exactly?
>
> I'd say
>
> Index: tree-ssa-math-opts.c
> ===================================================================
> --- tree-ssa-math-opts.c        (revision 211170)
> +++ tree-ssa-math-opts.c        (working copy)
> @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_
>        unsigned align;
>
>        align = get_object_alignment (src);
> -      if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
> +      if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
> +         && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
>         return false;
>
>        /*  Compute address to load from and cast according to the size
>
> is obvious (and pre-approved).

I've now regtested that patch on sparc-sun-solaris2.11 (compared to a
bootstrap without java before) and i386-pc-solaris2.11.  No regressions,
but gcc.c-torture/execute/bswap-2.c is still failing on sparc.

Since it seems a non-workaround patch is now forthcoming, I'll hold off
on installing it, but instead keep it local for the moment.

Thanks.
        Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #20 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Also if the expression was loading a 32 bit value byte by byte then the
> transformation would be useful. I'm already working on a patch to add a cost
> model but this will just add more code to execute before taking the
> decision. It will however prevent rewriting statements if the result will
> execute slower on the target.

That sounds like the right direction to me.

> Maybe a better solution for sparc would be to add a switch for this pass and
> disable it by default on sparc. What do you think about that?

There is nothing special about SPARC, it's the same for every strict alignment
architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid predicate.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #21 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #19)
> 
> I've now regtested that patch on sparc-sun-solaris2.11 (compared to a
> bootstrap without java before) and i386-pc-solaris2.11.  No regressions,
> but gcc.c-torture/execute/bswap-2.c is still failing on sparc.

There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to
confirm me it works for him on m68k. I'd be interested in knowing if that
solves your issue as well.

[0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #23 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to Eric Botcazou from comment #20)
> 
> > Maybe a better solution for sparc would be to add a switch for this pass and
> > disable it by default on sparc. What do you think about that?
> 
> There is nothing special about SPARC, it's the same for every strict
> alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid
> predicate.

My point was two fold:

1) Even if the pass does nothing for unaligned access on target where this is
slow, a bunch of code is still executed to determine that the access is
unaligned (in fact most of the pass is executed before the address of the
access is known).

2) For some unaligned access the rewrite might be interesting, like rewriting
this:

tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24)

into this:

*((uint32_t *) &tab[1])

(considering tab[0] to be 4 byte aligned) which could end up doing one 32 bit
load at addresses &tab[0], one shift and one byte load at address &tab[4].

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #24 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #22)
> 
> I'm giving both patches combined a try right now, though SPARC bootstrap
> will take 7+ hours to complete.

Great, thanks.

> 
> Please remember to add proposed patches to the URL field of the PR,
> otherwise they are easily overlooked.

Sorry I'm not very familiar with bugzilla yet and I didn't know this was
possible. It doesn't seem I can edit anything in the PR beyond my subscription
to it and adding comments though. Have I missed something?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #24 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
[...]
>> Please remember to add proposed patches to the URL field of the PR,
>> otherwise they are easily overlooked.
>
> Sorry I'm not very familiar with bugzilla yet and I didn't know this was
> possible. It doesn't seem I can edit anything in the PR beyond my subscription
> to it and adding comments though. Have I missed something?

Ah, I see: write-after-approval maintainers do get bugzilla write
access, but your not according to the MAINTAINERS file.

Sorry for the noise.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #26 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #25)
> 
> Ah, I see: write-after-approval maintainers do get bugzilla write
> access, but your not according to the MAINTAINERS file.

Oups, my mistake, I forgot to update the file. Will do it now, thanks for
reminding me.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #23)
> (In reply to Eric Botcazou from comment #20)
> > 
> > > Maybe a better solution for sparc would be to add a switch for this pass and
> > > disable it by default on sparc. What do you think about that?
> > 
> > There is nothing special about SPARC, it's the same for every strict
> > alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid
> > predicate.
> 
> My point was two fold:
> 
> 1) Even if the pass does nothing for unaligned access on target where this
> is slow, a bunch of code is still executed to determine that the access is
> unaligned (in fact most of the pass is executed before the address of the
> access is known).
> 
> 2) For some unaligned access the rewrite might be interesting, like
> rewriting this:
> 
> tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24)
> 
> into this:
> 
> *((uint32_t *) &tab[1])
> 
> (considering tab[0] to be 4 byte aligned) which could end up doing one 32
> bit load at addresses &tab[0], one shift and one byte load at address
> &tab[4].

Yes, I think that the load may be written in non-optimal way and the expander
has a better chance to produce optimal code (considering insv availability).

I fear that if we install this workaround we'll never get at the actual
issue (which might be just PR61306?)

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #28 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #22)
>> > --- Comment #21 from Thomas Preud'homme <thomas.preudhomme at arm dot
>> > com> ---
>> >
>> > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to
>> > confirm me it works for him on m68k. I'd be interested in knowing if that
>> > solves your issue as well.
>> >
>> > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html
>> 
>> I'm giving both patches combined a try right now, though SPARC bootstrap
>> will take 7+ hours to complete.
>
> Did it work?

The bootstrap did, but the bswap-2.c execution failures remain, although
I applied both of your patches.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #30 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
Can you run the test manually under gdb and tell me what is the value for the
"out" variable in hex format?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #30 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
> Can you run the test manually under gdb and tell me what is the value for the
> "out" variable in hex format?

Sure: the -O0 test aborts at line 78, where out is

(gdb) p/x out
$11 = 0x44434241
(gdb) p (char[4])out
$12 = "DCBA"

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #32 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #31)
> > --- Comment #30 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
> > Can you run the test manually under gdb and tell me what is the value for the
> > "out" variable in hex format?
> 
> Sure: the -O0 test aborts at line 78, where out is
> 
> (gdb) p/x out
> $11 = 0x44434241
> (gdb) p (char[4])out
> $12 = "DCBA"
> 
> 	Rainer

Are you sure the patch was applied to this test? Line 78 I have "bfin.inval =
(struct ok) { 0x83, 0x85, 0x87, 0x89 };"

The next abort about this line is under a "if (out == 0x89878583)" so would not
abort either. By the way, no need to do a bootstrap again or run the whole
testsuite to try this patch, only this test was changed.
>From gcc-bugs-return-453367-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 06 09:27:46 2014
Return-Path: <gcc-bugs-return-453367-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27998 invoked by alias); 6 Jun 2014 09:27:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27905 invoked by uid 48); 6 Jun 2014 09:27:42 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
Date: Fri, 06 Jun 2014 09:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: lto
X-Bugzilla-Keywords: ABI, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc target_milestone everconfirmed
Message-ID: <bug-61123-4-jIO6JFe2ZQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61123-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61123-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00449.txt.bz2
Content-length: 539

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida123

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-06
                 CC|                            |ramana at gcc dot gnu.org
   Target Milestone|---                         |4.10.0
     Ever confirmed|0                           |1

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #34 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
Ok, committed then.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #35 from thopre01 at gcc dot gnu.org ---
Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try
again a bootstrap without any of the patch you applied locally? I would like to
see if this bug is a duplicate of PR61306 as supposed by Richard.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #35 from thopre01 at gcc dot gnu.org ---
> Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try
> again a bootstrap without any of the patch you applied locally? I would like to
> see if this bug is a duplicate of PR61306 as supposed by Richard.

Sure, sparc-sun-solaris2.11 bootstrap in progress.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #35 from thopre01 at gcc dot gnu.org ---
>> Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try
>> again a bootstrap without any of the patch you applied locally? I would
>> like to
>> see if this bug is a duplicate of PR61306 as supposed by Richard.
>
> Sure, sparc-sun-solaris2.11 bootstrap in progress.

... and fails just the same as before.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #38 from thopre01 at gcc dot gnu.org ---
I've just wrote a patch that solve a bug that can lead to the kind of issue you
are running into. I'm doing more testing right now and will let you know when
it's commited if you don't mind trying another bootstrap. Thanks for your
patience.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #39 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #38 from thopre01 at gcc dot gnu.org ---
> I've just wrote a patch that solve a bug that can lead to the kind of issue you
> are running into. I'm doing more testing right now and will let you know when
> it's commited if you don't mind trying another bootstrap. Thanks for your
> patience.

Fine.  For the moment, I'm running with Richard's workaround patch to
keep Solaris/SPARC bootstrapping.

Thanks.
        Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #40 from thopre01 at gcc dot gnu.org ---
Alright, change commited (r211778). Can you try another bootstrap with trunk to
see if your Bus error was this bug or another one still?

Thanks a lot.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #40 from thopre01 at gcc dot gnu.org ---
> Alright, change commited (r211778). Can you try another bootstrap with trunk to
> see if your Bus error was this bug or another one still?

One bootstrap is already running, but I'm about to leave for a short
vacation.  I'll get back to you when I've returned next tuesday.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
>> --- Comment #40 from thopre01 at gcc dot gnu.org ---
>> Alright, change commited (r211778). Can you try another bootstrap with trunk to
>> see if your Bus error was this bug or another one still?
>
> One bootstrap is already running, but I'm about to leave for a short
> vacation.  I'll get back to you when I've returned next tuesday.

I've just started another bootstrap with the workaround omitted, and it
fails again as it did before.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #43 from thopre01 at gcc dot gnu.org ---
Thanks. In the stage before the one that fails, could you add
-fdump-tree-all-details -fdump-rtl-all-details to the command line when
compiling that jcf-parse.c file and send me an archive with all the generated
files? Another archive with trunk + Richard Biener's patch might help but given
the time to bootstrap gcc on SPARC I'll try to find the problem only with the
broken gcc and will come back at you if I need more.

Best regards.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #43 from thopre01 at gcc dot gnu.org ---
> Thanks. In the stage before the one that fails, could you add
> -fdump-tree-all-details -fdump-rtl-all-details to the command line when
> compiling that jcf-parse.c file and send me an archive with all the generated
> files? Another archive with trunk + Richard Biener's patch might help but given
> the time to bootstrap gcc on SPARC I'll try to find the problem only with the
> broken gcc and will come back at you if I need more.

I happened to have run another bootstrap with Richard's workaround
patch, so I can easily include both.

I'm not sure I you'll find something useful, though: jcf-parse.c is
compiled during stages 2 and 3 only, and when I tried the failing
java/lang/Class.java compilation with the stage2 jc1, it failed just the
same.

Anyway, I've placed the dumps from the stage2 compilations of
jcf-parse.c at

    http://www.cebitec.uni-bielefeld.de/~ro/files/jcf-parse.dumps.good.tar.bz2
resp.
       
http://www.cebitec.uni-bielefeld.de/~ro/files/jcf-parse.dumps.bad.tar.bz2

because the files are way too large (36 MB each) to upload to bugzilla.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #45 from thopre01 at gcc dot gnu.org ---
I only looked at differences in bswap so far and it all looks ok. It correctly
detects three patterns of 16bit big endian load and replace them by 16bit
unsigned loads and cast the results to int as was done in the original pattern.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #46 from thopre01 at gcc dot gnu.org ---
After expand, the newly created 16bit big endian load becomes:

(insn 688 687 689 (set (reg:HI 482)
        (mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
     (nil))

(insn 689 688 690 (set (reg:SI 483)
        (ashift:SI (subreg:SI (reg:HI 482) 0)
            (const_int 16 [0x10])))
/vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
     (nil))

(insn 690 689 0 (set (reg/v:SI 185 [ min_line ])
        (lshiftrt:SI (reg:SI 483)
            (const_int 16 [0x10])))
/vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
     (expr_list:REG_EQUAL (zero_extend:SI (reg:HI 482))
        (nil)))

I don't understand why those two loads. Also, the HI load is not split into 2
QI ones.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #47 from Rainer Orth <ro at gcc dot gnu.org> ---
Thomas,

any progress on this one?  SPARC bootstrap has been broken for almost two
months
now (yes, there's an out-of-tree workaround, but still).

Thanks.
  Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #48 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please provide preprocessed source for jcf-parse.c and instructions on how
to configure a cross compiler from x86_64-linux.  Please also provide
disassembly around the failing place with enough context to spot it
in a cc1 generated output - best with an explanation what's wrong.

>From what Thomas says in comment #46 it looks like for some unknown
reason a HI load from a 1-byte aligned address is emitted:

(insn 688 687 689 (set (reg:HI 482)
        (mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
     (nil))

but as the bswap pass emits a plain MEM_REF with an aligned type we should
go through the following path in expand:

        if (modifier != EXPAND_WRITE
            && modifier != EXPAND_MEMORY
            && !inner_reference_p
            && mode != BLKmode
            && align < GET_MODE_ALIGNMENT (mode))
          {
            if ((icode = optab_handler (movmisalign_optab, mode))
                != CODE_FOR_nothing)
              {
                struct expand_operand ops[2];

                /* We've already validated the memory, and we're creating a
                   new pseudo destination.  The predicates really can't fail,
                   nor can the generator.  */
                create_output_operand (&ops[0], NULL_RTX, mode);
                create_fixed_operand (&ops[1], temp);
                expand_insn (icode, 2, ops);
                temp = ops[0].value;
              }
            else if (SLOW_UNALIGNED_ACCESS (mode, align))
              temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
                                        0, TYPE_UNSIGNED (TREE_TYPE (exp)),
                                        (modifier == EXPAND_STACK_PARM
                                         ? NULL_RTX : target),
                                        mode, mode);

that is, go through extract_bit_field (supposed sparc doesn't have
movmisalign and is SLOW_UNALIGNED_ACCESS for HImode and 8-bit align).

So we need to figure out why we don't go the above path or why
extract_bit_field gets things wrong.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #49 from thopre01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #48)
> 
> From what Thomas says in comment #46 it looks like for some unknown
> reason a HI load from a 1-byte aligned address is emitted:

Yep that's it. Just look at log for expand in the archive Rainer posted the
link to on this bug report and search for :1622. In the last step of gimple
(optimized) we can just see a single load. The log doesn't show the alignment
of a given load but from the code it should be correct.

Best regards.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|thopre01 at gcc dot gnu.org        |rguenth at gcc dot gnu.org

--- Comment #50 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, we also expand one from a TARGET_MEM_REF:

;;   basic block 76, loop depth 2
;;    pred:       79
  load_dst_215 = MEM[base: ptr_110, offset: 0B];

and TARGET_MEM_REF only handles the movmisalign case.  So it's either IVOPTs
not punting properly here (it does for unaligned accesses - grep for
STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much
pessimized by not considering this).

I'll fix it somewhen after the cauldron unless somebody beats me to it.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #51 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Ah, we also expand one from a TARGET_MEM_REF:
> 
> ;;   basic block 76, loop depth 2
> ;;    pred:       79
>   load_dst_215 = MEM[base: ptr_110, offset: 0B];
> 
> and TARGET_MEM_REF only handles the movmisalign case.  So it's either IVOPTs
> not punting properly here (it does for unaligned accesses - grep for
> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much
> pessimized by not considering this).

TARGET_MEM_REF is supposed to be a valid memory access for the target though
and, by definition, an unaligned access is not valid for a strict alignment
target (unless you have a movmisalign pattern), so the problem is the
TARGET_MEM_REF.

If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll need to
make sure that the costs are properly adjusted and benchmark the result.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #53 from thopre01 at gcc dot gnu.org ---
(In reply to thopre01 from comment #52)
> (In reply to Eric Botcazou from comment #51)
> > 
> > TARGET_MEM_REF is supposed to be a valid memory access for the target though
> > and, by definition, an unaligned access is not valid for a strict alignment
> > target (unless you have a movmisalign pattern), so the problem is the
> > TARGET_MEM_REF.
> 
> So we just need to identify what changes the MEM_REF that bswap introduce
> into a TARGET_MEM_REF without taking alignment into account.
> 
> After bswap it's only a MEM_REF:
> 
> load_dst_215 = MEM[(unsigned char *)load_src_277];

So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick grep. I
don't know how much this system but I can take a look after Cauldron where does
this happen and bring the right person into this discussion.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #55 from rguenther at suse dot de <rguenther at suse dot de> ---
On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
>
>--- Comment #53 from thopre01 at gcc dot gnu.org ---
>(In reply to thopre01 from comment #52)
>> (In reply to Eric Botcazou from comment #51)
>> > 
>> > TARGET_MEM_REF is supposed to be a valid memory access for the
>target though
>> > and, by definition, an unaligned access is not valid for a strict
>alignment
>> > target (unless you have a movmisalign pattern), so the problem is
>the
>> > TARGET_MEM_REF.
>> 
>> So we just need to identify what changes the MEM_REF that bswap
>introduce
>> into a TARGET_MEM_REF without taking alignment into account.
>> 
>> After bswap it's only a MEM_REF:
>> 
>> load_dst_215 = MEM[(unsigned char *)load_src_277];
>
>So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick
>grep. I
>don't know how much this system but I can take a look after Cauldron
>where does
>this happen and bring the right person into this discussion.

You need to fix may_be_unaligned (or similar) in ivopts.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #56 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #55)
> On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org"
> <gcc-bugzilla@gcc.gnu.org> wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
> >
> >--- Comment #53 from thopre01 at gcc dot gnu.org ---
> >(In reply to thopre01 from comment #52)
> >> (In reply to Eric Botcazou from comment #51)
> >> > 
> >> > TARGET_MEM_REF is supposed to be a valid memory access for the
> >target though
> >> > and, by definition, an unaligned access is not valid for a strict
> >alignment
> >> > target (unless you have a movmisalign pattern), so the problem is
> >the
> >> > TARGET_MEM_REF.
> >> 
> >> So we just need to identify what changes the MEM_REF that bswap
> >introduce
> >> into a TARGET_MEM_REF without taking alignment into account.
> >> 
> >> After bswap it's only a MEM_REF:
> >> 
> >> load_dst_215 = MEM[(unsigned char *)load_src_277];
> >
> >So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick
> >grep. I
> >don't know how much this system but I can take a look after Cauldron
> >where does
> >this happen and bring the right person into this discussion.
> 
> You need to fix may_be_unaligned (or similar) in ivopts.

So actually that function now looks completely sane (thanks Eric).  So
I still need preprocessed source and a target triplet to configure a cross
for.

There must be missing may_be_unaligned_p calls in IVOPTs.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #57 from Richard Biener <rguenth at gcc dot gnu.org> ---
Waiting for preprocessed source and configure instructions.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #58 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33181&action=edit
preprocessed input

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #59 from Rainer Orth <ro at gcc dot gnu.org> ---
Configure binutils with

configure \
    --target sparc-solaris2.11

and gcc with

configure \
    --prefix=/var/gcc/cross/sparc-solaris2.11 \
    --target sparc-solaris2.11 \
    --with-gmp=/vol/gcc \
    --with-gnu-as \
    --disable-multilib \
    --enable-languages=c++

Then compile jcf-parse.ii with

cc1plus -fpreprocessed jcf-parse.ii -quiet -mcpu=v9 -g -O2 -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -fno-common -o jcf-parse.s

  Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED

--- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, I suppose

        lduh    [%g3], %g4      ! MEM[base: ptr_110, offset: 0B], min_line

is not an instruction that works with unaligned %g3.

;; min_line_106 = (int) _215;

(insn 921 920 922 (set (reg:HI 482)
        (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
     (nil))

a (mem:HI ...) with A8.  I wonder if we should ICE somewhere if such kind
of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform?

The TARGET_MEM_REF is created via

#0  create_mem_ref_raw (type=type@entry=0x7ffff5401000, 
    alias_ptr_type=alias_ptr_type@entry=<pointer_type 0x7ffff61e3c78>, 
    addr=addr@entry=0x7fffffffd560, verify=verify@entry=true)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:401
#1  0x0000000000c3b464 in create_mem_ref (gsi=gsi@entry=0x7fffffffd600, 
    type=<integer_type 0x7ffff5401000 short unsigned int>, 
    addr=addr@entry=0x7fffffffd640, 
    alias_ptr_type=<pointer_type 0x7ffff61e3c78>, 
    iv_cand=iv_cand@entry=<ssa_name 0x7ffff66cc948>, 
    base_hint=base_hint@entry=<ssa_name 0x7ffff66cc948>, 
    speed=speed@entry=true)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:721
#2  0x0000000000c96f9a in rewrite_use_address (use=use@entry=0x18b8a10, 
    cand=cand@entry=0x1a26f50, data=<optimized out>, data=<optimized out>)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6471
#3  0x0000000000c97513 in rewrite_use (cand=0x1a26f50, use=0x18b8a10, 
    data=0x7fffffffd9c0)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6539
#4  rewrite_uses (data=data@entry=0x7fffffffd9c0)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6568
#5  0x0000000000c9cb35 in tree_ssa_iv_optimize_loop (loop=<optimized out>, 
    data=0x7fffffffd9c0)
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6894
#6  tree_ssa_iv_optimize ()
    at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6926

Ah, so the issue is that may_be_unaligned does

1706      unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
1707
1708      unsigned HOST_WIDE_INT bitpos;
1709      unsigned int ref_align;
1710      get_object_alignment_1 (ref, &ref_align, &bitpos);
1711      if (ref_align < align
1712          || (bitpos % align) != 0
1713          || (bitpos % BITS_PER_UNIT) != 0)
1714        return true;

thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_
mode alignment which is what matters on STRICT_ALIGNMENT targets.

Fix:

Index: gcc/tree-ssa-loop-ivopts.c
===================================================================
--- gcc/tree-ssa-loop-ivopts.c  (revision 213050)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step)
     return false;

   unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
+  if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align)
+    align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref)));

   unsigned HOST_WIDE_INT bitpos;
   unsigned int ref_align;

can you test and apply that patch?

Thx.

With that patch I get

        ldub    [%g3+1], %g2    ! MEM[(unsigned char *)ptr_110], MEM[(unsigned
char *)ptr_110]
        ldub    [%g3], %g1      ! MEM[(unsigned char *)ptr_110], MEM[(unsigned
char *)ptr_110]
        sll     %g1, 8, %g1     ! MEM[(unsigned char *)ptr_110],, tmp462
        or      %g2, %g1, %g1   ! MEM[(unsigned char *)ptr_110], tmp462,
min_line

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #61 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Ok, I suppose
> 
>         lduh    [%g3], %g4      ! MEM[base: ptr_110, offset: 0B], min_line
> 
> is not an instruction that works with unaligned %g3.

Right, every load must be aligned.

> ;; min_line_106 = (int) _215;
> 
> (insn 921 920 922 (set (reg:HI 482)
>         (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0
> S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
>      (nil))
> 
> a (mem:HI ...) with A8.  I wonder if we should ICE somewhere if such kind
> of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform?

No, it's undefined behavior at run time only.

> Ah, so the issue is that may_be_unaligned does
> 
> 1706      unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
> 1707
> 1708      unsigned HOST_WIDE_INT bitpos;
> 1709      unsigned int ref_align;
> 1710      get_object_alignment_1 (ref, &ref_align, &bitpos);
> 1711      if (ref_align < align
> 1712          || (bitpos % align) != 0
> 1713          || (bitpos % BITS_PER_UNIT) != 0)
> 1714        return true;
> 
> thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_
> mode alignment which is what matters on STRICT_ALIGNMENT targets.

Yes, and that's what the original implementation actually did, see:
  https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00717.html

> Fix:
> 
> Index: gcc/tree-ssa-loop-ivopts.c
> ===================================================================
> --- gcc/tree-ssa-loop-ivopts.c  (revision 213050)
> +++ gcc/tree-ssa-loop-ivopts.c  (working copy)
> @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step)
>      return false;
>  
>    unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
> +  if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align)
> +    align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref)));
>  
>    unsigned HOST_WIDE_INT bitpos;
>    unsigned int ref_align;
> 
> can you test and apply that patch?

I think that it needs to be applied on both mainline and 4.9 branch then.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
[...]
> With the patch, SPARC bootstrap concluded on mainline.  I'm seeing two
> different regressions with this patch in tree:
>
> * on i386-pc-solaris2.10, gcc.dg/pch/import-[12].c FAILs (SEGV in cc1
>   due to unaligned movaps destination)
>
> * on sparc-sun-solaris2.*, many 64-bit gfortran.dg tests (starting with
>   gfortran.dg/allocate_class_3.f90) FAIL at -O1 and above
>
> I'd like to make sure those are not related to your patch first.

It turned out that both failures are unrelated.  I'll start reghunting now.

>From my POV, the patch is good to go.  I'll next try it on the 4.9
branch as Eric asked.

    Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[tony.wang at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

wangzheyu <tony.wang at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tony.wang at arm dot com

--- Comment #64 from wangzheyu <tony.wang at arm dot com> ---
> 
> Fix:
> 
> Index: gcc/tree-ssa-loop-ivopts.c
> ===================================================================
> --- gcc/tree-ssa-loop-ivopts.c  (revision 213050)
> +++ gcc/tree-ssa-loop-ivopts.c  (working copy)
> @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step)
>      return false;
>  
>    unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
> +  if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align)
> +    align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref)));
>  
>    unsigned HOST_WIDE_INT bitpos;
>    unsigned int ref_align;
> 
> can you test and apply that patch?

Also run into a similar regression on arm target, which will generate unaligned
memory access on target which don't support unaligned data access. This patch
does fix this regression.

Thx

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #61 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
[...]
>> can you test and apply that patch?
>
> I think that it needs to be applied on both mainline and 4.9 branch then.

Testing on the 4.9 branch also completed successfully, so from my POV
the patch is good to go in both mainline and branch.

Thanks.
        Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #66 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Aug  6 11:41:13 2014
New Revision: 213661

URL: https://gcc.gnu.org/viewcvs?rev=213661&root=gcc&view=rev
Log:
2014-08-06  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61320
    * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly
    handle misaligned loads.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #67 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Aug  6 11:42:22 2014
New Revision: 213662

URL: https://gcc.gnu.org/viewcvs?rev=213662&root=gcc&view=rev
Log:
2014-08-06  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61320
    * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly
    handle misaligned loads.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivopts.c

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.10.0, 4.8.3, 4.9.2
         Resolution|---                         |FIXED
   Target Milestone|4.10.0                      |4.9.2
      Known to fail|4.8.3                       |4.9.1

--- Comment #68 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #69 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 49444 has been marked as a duplicate of this bug. ***