On Sat, Dec 21, 2024 at 02:28:33AM -0300, Alexandre Oliva wrote:
> On Dec 20, 2024, Jakub Jelinek <ja...@redhat.com> wrote:
> 
> > On Wed, Dec 18, 2024 at 12:59:11AM -0300, Alexandre Oliva wrote:
> >> * gcc.dg/field-merge-16.c: New.
> 
> > Note the test FAILs on i686-linux or on x86_64-linux with -m32.
> 
> Also fixed herein.
> 
> 
> A number of tests that check for specific ifcombine transformations
> fail on AVR and PRU targets, whose type sizes and alignments aren't
> conducive of the expected transformations.  Adjust the expectations.
> 
> Most execution tests should run successfully regardless of the
> transformations, but a few that could conceivably fail if short and
> char have the same bit width now check for that and bypass the tests
> that would fail.
> 
> Conversely, one test that had such a runtime test, but that would work
> regardless, no longer has that runtime test, and its types are
> narrowed so that the transformations on 32-bit targets are more likely
> to be the same as those that used to take place on 64-bit targets.
> This latter change is somewhat obviated by a separate patch, but I've
> left it in place anyway.
> 
> Regstrapped on x86_64-linux-gnu.  I'd appreciate if someone who can test
> AVR and PRU would confirm that it fixes all field-merge-* failures.  Ok
> to install?


Hi Alexandre,

All failures are now fixed for PRU:
  make check-gcc-c RUNTESTFLAGS="--target_board=pru-sim dg.exp=field-merge-*.c"
  # of expected passes            36

But several failures remain for AVR:
  FAIL: gcc.dg/field-merge-1.c (test for excess errors)
  FAIL: gcc.dg/field-merge-1.c execution test
  FAIL: gcc.dg/field-merge-11.c (test for excess errors)
  FAIL: gcc.dg/field-merge-11.c execution test
  FAIL: gcc.dg/field-merge-17.c execution test
  FAIL: gcc.dg/field-merge-3.c (test for excess errors)
  FAIL: gcc.dg/field-merge-4.c (test for excess errors)
  FAIL: gcc.dg/field-merge-5.c (test for excess errors)

I've attached the test log for AVR.  The tests seem to rely on int being
at least 32 bits, so you might consider adding a filter:
  /* { dg-require-effective-target int32plus } */

Regards,
Dimitar

Attachment: gcc.log.gz
Description: application/gzip

Reply via email to