[Bug objc++/44518] New: [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[Bug objc++/44518] New: [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[mikpe at it dot uu dot se]

On 4_5-branch, the objc++ encode-2.mm and encode-3.mm tests started to fail
recently on several platforms:

FAIL: obj-c++.dg/encode-2.mm scan-assembler
{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=cci}i}
FAIL: obj-c++.dg/encode-3.mm -fgnu-runtime execution test

Compare e.g.

http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00958.html (s390x, r160516)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00567.html (arm, r160235)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00364.html (powerpc64,
r160235)

with

http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01078.html (s390x, r160582)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01249.html (arm, r160582)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01118.html (powerpc64,
r160582)

I suspect the PR32052 backport in r160541.

Testsuite results before and after the corresponding trunk commit (r158958)
show a similar regression.  Compare e.g.

http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02848.html (powerpc64,
r158910)

with

http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00161.html (powerpc64,
r158969)


-- 
           Summary: [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm
                    fail on several platforms
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: objc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikpe at it dot uu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-13 14:20 -------
Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
though).

Please restore the previous state by at least re-instantiating the XFAIL on the
branch.

Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
          Component|objc++                      |testsuite
     Ever Confirmed|0                           |1
           Priority|P3                          |P1
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-13 14:20:12
               date|                            |
   Target Milestone|---                         |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #2 from iains at gcc dot gnu dot org  2010-06-13 15:26 -------
Subject: Bug 44518

Author: iains
Date: Sun Jun 13 15:26:22 2010
New Revision: 160682

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160682
Log:

partial reversion of r160541.

        PR testsuite/44518
        * obj-c++.dg/encode-2.mm: XFAIL new test for all targets.
        * obj-c++.dg/encode-3.mm: Restore XFAIL run for all targets.


Modified:
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/obj-c++.dg/encode-2.mm
    branches/gcc-4_5-branch/gcc/testsuite/obj-c++.dg/encode-3.mm


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #3 from iains at gcc dot gnu dot org  2010-06-13 15:31 -------
(In reply to comment #1)
> Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
> though).

Well, of course, the patch did not cause any regressions on targets I have
access to.
These now XPASS.

I need to find out what the failing targets have in common (apart from me not
having access).  
I'll see about making some cross-tools.

powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's output)
- so there's a permutation that needs covering.

thanks for letting me know.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[mikpe at it dot uu dot se]

------- Comment #4 from mikpe at it dot uu dot se  2010-06-13 16:42 -------
(In reply to comment #3)
> powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
> output)

I've scanned the gcc-testresults list archive for May and June quite carefully,
and I don't think anyone is testing obj-c++ on i686 or x86_64 linux.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[mikpe at it dot uu dot se]

------- Comment #5 from mikpe at it dot uu dot se  2010-06-13 16:49 -------
Created an attachment (id=20903)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903&action=view)
correction to encode-2.mm

On powerpc64 encode-2.mm fails because the test case scans the assembly output
for the string "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=cci}i}", but
on
powerpc64 it is "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=CCi}i}".

Note the different case for the "CC" part.  That's because the test case
instantiates a Vec with plain char and expects it to mangle to "c".  However,
plain char maps to either signed or unsigned char depending on the machine, and
those two types mangle differently.  Apparently "c" corresponds to signed char.
Adjusting the test case to explicitly say "signed char" fixes it on powerpc64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #6 from iains at gcc dot gnu dot org  2010-06-13 17:04 -------
(In reply to comment #4)
> (In reply to comment #3)
> > powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
> > output)
> 
> I've scanned the gcc-testresults list archive for May and June quite carefully,
> and I don't think anyone is testing obj-c++ on i686 or x86_64 linux.

I always test i686-pc-linux-gnu .. and some of the regression test machines
include various permutations.
Hopefully, I'll be able to test x86_64 in the not-too-distant future.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #7 from iains at gcc dot gnu dot org  2010-06-13 17:07 -------
(In reply to comment #5)
> Created an attachment (id=20903)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903&action=view) [edit]
> correction to encode-2.mm
> 
> On powerpc64 encode-2.mm fails because the test case scans the assembly output
> for the string "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=cci}i}", but
> on
> powerpc64 it is "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=CCi}i}".
> 
> Note the different case for the "CC" part.  That's because the test case
> instantiates a Vec with plain char and expects it to mangle to "c".  However,
> plain char maps to either signed or unsigned char depending on the machine, and
> those two types mangle differently.  Apparently "c" corresponds to signed char.
> Adjusting the test case to explicitly say "signed char" fixes it on powerpc64.

Indeed, good catch, thanks.
I'll stick that in the melting pot for the next round - there are other encode
updates needed.
Too late to do any more for 4.5.1 anyway, I suspect.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[mikpe at it dot uu dot se]

------- Comment #8 from mikpe at it dot uu dot se  2010-06-13 17:15 -------
On ARM encode-2.mm fails in part for the same "plain char mangles differently"
reason as on powerpc64, but also due to a backend oddity.  Here's how the
string is output in the assembly file on ARM:

        .ascii  "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=CC"
        .ascii  "i}i}\000"

For some reason the ARM backend breaks not very long string literals into
chunks.  That's ok in principle because the data is correct in the object file,
but it means that testsuite "scan-assembler" operations become unreliable. 
Ideally the test should scan the object file for the string instead, but there
doesn't seem to be a way to do that.

It seems gcc on i686 will also break up long string literals, but it allows for
much much longer strings before doing that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #9 from iains at gcc dot gnu dot org  2010-06-13 17:20 -------
(In reply to comment #8)
> On ARM encode-2.mm fails in part for the same "plain char mangles differently"
> reason as on powerpc64, but also due to a backend oddity.  Here's how the
> string is output in the assembly file on ARM:
> 
>         .ascii  "{?={Vec<double>=ddi}{Vec<float>=ffi}fd{Vec<char>=CC"
>         .ascii  "i}i}\000"
> 
> For some reason the ARM backend breaks not very long string literals into
> chunks.  That's ok in principle because the data is correct in the object file,
> but it means that testsuite "scan-assembler" operations become unreliable. 
> Ideally the test should scan the object file for the string instead, but there
> doesn't seem to be a way to do that.
> 
> It seems gcc on i686 will also break up long string literals, but it allows for
> much much longer strings before doing that.

I can put a target-specific scanasm (once I know what to scan for).  They look
a little unwieldy - but they work.

Just having a go at making some cross-tools - at least that's a start for asm
syntax issues.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[mikpe at it dot uu dot se]

------- Comment #10 from mikpe at it dot uu dot se  2010-06-13 17:42 -------
Created an attachment (id=20904)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20904&action=view)
correction to encode-3.mm

The powerpc64 failure in encode-3.mm was also caused by a plain char mangling
difference.  This patch fixes it by explicitly using 'signed char'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #11 from iains at gcc dot gnu dot org  2010-07-03 08:16 -------
Subject: Bug 44518

Author: iains
Date: Sat Jul  3 08:15:59 2010
New Revision: 161769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161769
Log:

2010-07-03  Iain Sandoe  <iains@gcc.gnu.org>
            Mikael Pettersson  <mikpe@it.uu.se>

        PR testsuite/44518
        * obj-c++.dg/encode-2.mm: Produce object and save temps.
        Make signed-ness of chars explicit.  Scan the object for
        strings that are split by some target assemblers.
        * obj-c++.dg/encode-3.mm: Make the signed-ness of chars
        explicit.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/obj-c++.dg/encode-2.mm
    trunk/gcc/testsuite/obj-c++.dg/encode-3.mm


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

------- Comment #12 from iains at gcc dot gnu dot org  2010-07-11 09:55 -------
back-ported to 4.5 as r162037, closing as fixed


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518