[Bug target/46997] New: new ia64 vector instructions are broken on HP-UX (big-endian)

[sje at cup dot hp.com]

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

   Summary: new ia64 vector instructions are broken on HP-UX
(big-endian)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


The new IA64 vector instructions added in version r167136 don't work on
HP-UX.  This is probably because HP-UX is big-endian while Linux is
little-endian.

Some of the failing tests include:

FAIL: gcc.dg/vect/fast-math-vect-complex-3.c execution test
FAIL: gcc.dg/vect/fast-math-vect-complex-3.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10a.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10a.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10b.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10b.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-18.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-18.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-20.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-20.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-21.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-21.c execution test
FAIL: gcc.dg/vect/pr37539.c execution test
FAIL: gcc.dg/vect/pr37539.c execution test
FAIL: gcc.dg/vect/slp-11.c execution test
FAIL: gcc.dg/vect/slp-11.c execution test
FAIL: gcc.dg/vect/slp-12a.c execution test
FAIL: gcc.dg/vect/slp-12a.c execution test
FAIL: gcc.dg/vect/slp-13.c execution test
FAIL: gcc.dg/vect/slp-13.c execution test
FAIL: gcc.dg/vect/slp-19.c execution test
FAIL: gcc.dg/vect/slp-19.c execution test
FAIL: gcc.dg/vect/slp-21.c execution test
FAIL: gcc.dg/vect/slp-21.c execution test
FAIL: gcc.dg/vect/slp-23.c execution test
FAIL: gcc.dg/vect/slp-23.c execution test
FAIL: gcc.dg/vect/slp-multitypes-10.c execution test
FAIL: gcc.dg/vect/slp-multitypes-10.c execution test
FAIL: gcc.dg/vect/slp-multitypes-6.c execution test
FAIL: gcc.dg/vect/slp-multitypes-6.c execution test
FAIL: gcc.dg/vect/slp-multitypes-9.c execution test
FAIL: gcc.dg/vect/slp-multitypes-9.c execution test
FAIL: gcc.dg/vect/slp-perm-2.c execution test
FAIL: gcc.dg/vect/slp-perm-2.c execution test
FAIL: gcc.dg/vect/slp-perm-3.c execution test
FAIL: gcc.dg/vect/slp-perm-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-6.c execution test
FAIL: gcc.dg/vect/slp-reduc-6.c execution test
FAIL: gcc.dg/vect/vect-107.c execution test
FAIL: gcc.dg/vect/vect-107.c execution test
FAIL: gcc.dg/vect/vect-116.c execution test
FAIL: gcc.dg/vect/vect-116.c execution test
FAIL: gcc.dg/vect/vect-35.c execution test
FAIL: gcc.dg/vect/vect-35.c execution test
FAIL: gcc.dg/vect/vect-double-reduc-5.c execution test
FAIL: gcc.dg/vect/vect-double-reduc-5.c execution test
FAIL: gcc.dg/vect/vect-iv-4.c execution test
FAIL: gcc.dg/vect/vect-iv-4.c execution test
FAIL: gcc.dg/vect/vect-iv-8.c execution test
FAIL: gcc.dg/vect/vect-iv-8.c execution test
FAIL: gcc.dg/vect/vect-iv-8a.c execution test
FAIL: gcc.dg/vect/vect-iv-8a.c execution test
FAIL: gcc.dg/vect/vect-multitypes-14.c execution test
FAIL: gcc.dg/vect/vect-multitypes-14.c execution test
FAIL: gcc.dg/vect/vect-multitypes-8.c execution test
FAIL: gcc.dg/vect/vect-multitypes-8.c execution test
FAIL: gcc.dg/vect/vect-shift-2.c execution test
FAIL: gcc.dg/vect/vect-shift-2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i2-gap.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i2-gap.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
FAIL: gcc.dg/vect/vect-strided-float.c execution test
FAIL: gcc.dg/vect/vect-strided-float.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-same-dr.c execution test
FAIL: gcc.dg/vect/vect-strided-same-dr.c execution test
FAIL: gcc.dg/vect/vect-strided-store-a-u8-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-store-a-u8-i2.c execution tes

[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Steve Ellcey  2011-02-07 21:32:26 
UTC ---
This is now fixed, all the tests that pass on Linux pass on HP-UX as well.

[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||sje at cup dot hp.com
 Resolution|FIXED   |

--- Comment #33 from Steve Ellcey  2011-02-09 22:44:20 
UTC ---
I am reopening this bug because I am getting a failure of
gcc.dg/torture/vector-2.c that started when this patch was checked in.  I think
this is
the same test that used to be gcc.c-torture/execute/vector-2.c.

I have a cut down test case that fails (prints 'one') when compiled with -O1
-fno-guess-branch-probability starting at r169782.  The
-fno-guess-branch-probability is needed to generate code that uses auto-inc and
trigger the bug.
This fails on IA64 Linux and HP-UX.  It does not require the -fpic flag.

Let me know if I should open a new bug instead of re-opening this one.

extern int printf(const char *, ...);
extern void exit(int);
struct __attribute__((packed)) B { unsigned short j : 1, k : 11; };
struct B sB;

void testB (void) {
int i;
unsigned int mask, v, a, r;
struct B x;
sB.k = 750;
r = 750;
x.j = sB.j = 0;
printf("%d %d\n", (int) x.j, (int) sB.j);
printf("%d %d\n", (int) sB.k, (int) r);
if (x.j != sB.j || sB.k != r) printf ("one\n");
}
int
main (void)
{
  testB ();
  exit (0);
}

[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code

[sje at cup dot hp.com]

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

--- Comment #35 from Steve Ellcey  2011-02-09 23:42:57 
UTC ---
I think it is PR47614, I tried the first patch in that defect report and it
fixed my test case.

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #15 from Steve Ellcey  2011-02-17 15:54:04 
UTC ---
I tested the patch from comment #12 on ia64-hp-hpux11.23 (in 32 and 64 bit
modes) and it looks good.  There were no regressions and the test
g++.dg/debug/pr47283.C now passes.

[Bug rtl-optimization/47866] New: gcc.dg/torture/vector-2.c fails on IA64

[sje at cup dot hp.com]

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

   Summary: gcc.dg/torture/vector-2.c fails on IA64
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


gcc.dg/torture/vector-2.c is failing on Linux and HP-UX IA64 platforms since
r165240 which is Richard Henderson's fix for PR rtl-opt/33721.  This may be a
target specific bug but the change that caused the failure to show up is not
target specific.

gcc.dg/torture/vector-2.c fails at -O2, but passes at -O0 or -O1.  With the
latest sources I can use this cutdown test case to see the difference:

#define vector __attribute__((vector_size(16) ))

vector int f0(vector int t, int a)
{
 ((int*)&t)[0] = a;
 return t;
}
vector int f1(vector int t, int a)
{
 ((int*)&t)[1] = a;
 return t;
}
int main(void)
{
  vector int a = {0, 0, 0, 0};
  vector int a0;
  a0 = f0(a, 1);
  printf("%d %d %d %d\n", a0[0], a0[1], a0[2], a0[3]);
  a0 = f1(a, 1);
  printf("%d %d %d %d\n", a0[0], a0[1], a0[2], a0[3]);
  return 0;
}


At -O0 or -O1 it prints:

1 0 0 0
0 1 0 0

At -O2 it prints:

1 0 0 0
0 0 0 0

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[sje at cup dot hp.com]

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

--- Comment #20 from Steve Ellcey  2011-03-01 21:50:38 
UTC ---
It is still working for me on ia64-hp-hpux11.23 in 32 and 64 bit
modes but it is failing on my ia64-debian-linux-gnu system.  I failed to notice
that earlier.

[Bug libstdc++/50153] hppa64-hp-hpux11.11/libstdc++-v3/include/cstdlib:106:11: error: '::abs' has not been declared

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-22
 Ever Confirmed|0   |1

--- Comment #4 from Steve Ellcey  2011-08-22 22:57:08 
UTC ---
It looks like this is caused by r177877, where libcpp was changed to
set __cplusplus to 199711L instead of 1.  I think this is interacting badly
with the HP system headers somehow.

The HP headers have checks for '__cplusplus < 199707L' and those checks
are going to be different now.

[Bug libstdc++/50153] hppa64-hp-hpux11.11/libstdc++-v3/include/cstdlib:106:11: error: '::abs' has not been declared

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2011-08-22 23:31:20 
UTC ---
I am testing an inclhack.def header file fixup for abs.  I am not sure if any
of the other header files checks on __cplusplus will be a problem but fixing
the abs problem should get us bootstrapping again.

[Bug libstdc++/50153] hppa64-hp-hpux11.11/libstdc++-v3/include/cstdlib:106:11: error: '::abs' has not been declared

[sje at cup dot hp.com]

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

--- Comment #9 from Steve Ellcey  2011-08-23 20:55:15 
UTC ---
I think all I need to do is expand the existing hpux11_abs fixinclude rule
from 'ia64-hp-hpux11*' to '*-hp-hpux11*'  I am currently testing this.

The other checks for '__cplusplus < 199707L' in the header files don't
like like they should cause problems.  They set NULL to 0 (old) vs. 0L (new),
add a define for _WCHAR_T, and set some macros to specify that the long long
type is always available.  I think all those things should be OK.

I am testing my patch but had some system problems over night so I don't have a
complete bootstrap and test yet.

[Bug libstdc++/9635] time_get<>::date_order unimplemented

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #6 from Steve Ellcey  2011-09-27 16:43:11 
UTC ---
I am curious if we think anything will be done with this bug.

I see someone proposed a patch to the C++ library a while back
(https://issues.apache.org/jira/browse/STDCXX-459) but it was not accepted.

Do the comments from C++ library issue 461
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461) affect this
bug and our ability to fix it?

[Bug libstdc++/9635] time_get<>::date_order unimplemented

[sje at cup dot hp.com]

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

--- Comment #8 from Steve Ellcey  2011-09-27 18:23:56 
UTC ---
No, the patch I mentioned was not sent to this project.  If I am reading the
web site correctly (the first link in comment #6), I think the patch was sent
to the
apache version of the C++ library.  I am not sure what relationship that has to
the GCC libstdc++.

[Bug target/49967] The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others)

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.2

--- Comment #4 from Steve Ellcey  2011-10-12 18:11:44 
UTC ---
Fixed for 4.6.2 and 4.7.0.

[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #2 from Steve Ellcey  2011-10-12 18:23:28 
UTC ---
It looks like PR50326 is fixed so this should be fixed too if it really
a duplicate.  Matthias, do you still see this problem?

[Bug libstdc++/50153] hppa64-hp-hpux11.11/libstdc++-v3/include/cstdlib:106:11: error: '::abs' has not been declared

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Steve Ellcey  2011-10-12 21:40:39 
UTC ---
Fixed.

[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Blocks||50350
 Resolution|FIXED   |

--- Comment #11 from Steve Ellcey  2011-10-13 16:15:40 
UTC ---
The bad commit listed in comment #4 was back ported to the 4.6 branch so the
check in from comment #9 should be ported over to the 4.6 branch as well.  I am
reopening the bug for that reason.

[Bug rtl-optimization/48823] gcc-4.6.0 floating-point optimization regression on ia64-Linux

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sje at cup dot hp.com
 Resolution||INVALID

--- Comment #3 from Steve Ellcey  2011-10-13 17:57:50 
UTC ---
The difference in results is due to the use of the fma instructions (fused
multiply add).  If you don't want the fma instructions to be used you should
use the -ffp-contract=on flag.  Otherwise GCC will use them and accept the
slightly different floating point results due to no rounding being done between
the multiply and the add in the fma instruction.  GCC will also do other
optimizations that may change the results of inexact floating point
instructions.

I am resolving this as invalid since this change in the least significant bit
of an inexact floating point value is reasonable without fp-contract being on.

[Bug rtl-optimization/48823] gcc-4.6.0 floating-point optimization regression on ia64-Linux

[sje at cup dot hp.com]

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

--- Comment #5 from Steve Ellcey  2011-10-13 20:16:46 
UTC ---
I am not sure any set of flags will guarantee strict IEEE floating point
behavior.  See PR37845 for some more information.

[Bug target/38018] gcc.dg/pr37106-1.c doesn't work

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED

--- Comment #4 from Steve Ellcey  2011-10-13 23:18:16 
UTC ---
This test no longer fails on IA64.  It looks like the fix was put on the
mainline in time for 4.5.0.  I don't think it is worth porting it back to
the 4.4.* line or earlier releases so I am closing it.

[Bug middle-end/37678] Failure to generate post-increment addressing

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Steve Ellcey  2011-10-17 23:18:33 
UTC ---
GCC 4.6 and GCC ToT (pre-release 4.7) both generate post-increment loads
and stores for me on IA64 Linux so I am going to close this defect.  Older
GCC's may still have this problem but I don't see us going back to fix those
versions.

[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sje at cup dot hp.com
 Resolution||FIXED

--- Comment #2 from Steve Ellcey  2011-10-20 21:31:53 
UTC ---
Fixed by adding do-skip-if to the testcase.

[Bug bootstrap/50826] New: bootstrap on 64 bit pa broken by r180194, ICE in mem_loc_descriptor

[sje at cup dot hp.com]

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

 Bug #: 50826
   Summary: bootstrap on 64 bit pa broken by r180194, ICE in
mem_loc_descriptor
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

[Bug bootstrap/50826] bootstrap on 64 bit pa broken by r180194, ICE in mem_loc_descriptor

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-10-21 20:46:46 
UTC ---
Created attachment 25573
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25573
small test case

Test case.

[Bug bootstrap/50826] bootstrap on 64 bit pa broken by r180194, ICE in mem_loc_descriptor

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey  2011-10-21 20:55:47 
UTC ---
forgot to mention that the test case needs to be compiled with -O2 -g to
reproduce the problem.

[Bug bootstrap/50826] bootstrap on 64 bit pa broken by r180194, ICE in mem_loc_descriptor

[sje at cup dot hp.com]

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

--- Comment #7 from Steve Ellcey  2011-10-25 19:53:31 
UTC ---
Bootstrapping and testing both look good with the patch.

[Bug debug/51032] [4.7 Regression] ICE in dbxout_type, at dbxout.c:2372

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Target|alpha-dec-osf5.1b,  |alpha-dec-osf5.1b,
   |i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||hppa2.0w-hp-hpux11.11
 CC||sje at cup dot hp.com
   Host|alpha-dec-osf5.1b,  |alpha-dec-osf5.1b,
   |i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||hppa2.0w-hp-hpux11.11
  Build|alpha-dec-osf5.1b,  |alpha-dec-osf5.1b,
   |i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||hppa2.0w-hp-hpux11.11

--- Comment #6 from Steve Ellcey  2011-11-08 17:33:22 
UTC ---
I see this on hppa2.0w-hp-hpux11.11 as well.

[Bug debug/51032] [4.7 Regression] ICE in dbxout_type, at dbxout.c:2372

[sje at cup dot hp.com]

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

--- Comment #10 from Steve Ellcey  2011-11-08 23:08:37 
UTC ---
I did a successful bootstrap on hppa2.0w-hp-hpux11.11 with the patch.  I am
still running the test suite.

[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Target|s390-ibm-linux  |s390-ibm-linux,ia64-hp-hpux
   ||11.23
 CC||jimis at gmx dot net, sje
   ||at cup dot hp.com
   Host|s390-ibm-linux  |s390-ibm-linux,ia64-hp-hpux
   ||11.23
  Build|s390-ibm-linux  |s390-ibm-linux,ia64-hp-hpux
   ||11.23

--- Comment #2 from Steve Ellcey  2011-11-16 00:34:16 
UTC ---
Yes, this started failing on 181279 for ia64-hp-hpux11.23 as well.
Adding Dimitrios to CC list.

[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-11-16 00:43:15 
UTC ---
I think this is a big-endian bug in fprint_whex, etc.  IA64 HP-UX is
big endian and I think s390-ibm-linux is too.

[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-16
 Ever Confirmed|0   |1

--- Comment #4 from Steve Ellcey  2011-11-16 19:19:17 
UTC ---
It looks like fprint_w is broken for systems where HOST_WIDE_INT is 'long long'
and that type is longer then type 'long'.

Inside fprint_w we call sprint_ul_rev and that function is defined to take a 
'unsigned long' argument instead of a 'long long' argument which can cause a
truncation of the incoming value that we are trying to print.

I am testing this patch to see if it fixes all the problems.

Index: ../src/trunk/gcc/final.c
===
--- ../src/trunk/gcc/final.c(revision 181279)
+++ ../src/trunk/gcc/final.c(working copy)
@@ -3585,7 +3585,7 @@ output_addr_const (FILE *file, rtx x)
   break;

 case CONST_INT:
-  fprint_w (file, INTVAL (x));
+  fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x));
   break;

 case CONST:

[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)

[sje at cup dot hp.com]

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

--- Comment #4 from Steve Ellcey  2011-12-19 18:33:07 
UTC ---
Yes, this was failing on ia64 hpux as well as hppa hpux.

[Bug rtl-optimization/47866] [4.5/4.6 Regression] gcc.dg/torture/vector-2.c fails on IA64

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2011-03-09 17:26:44 
UTC ---
I tried the patch in comment #2 and verified that it fixes vector-2.c on IA64
HP-UX and Linux and caused no regressions.

[Bug bootstrap/48161] New: [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[sje at cup dot hp.com]

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

   Summary: [4.6 regression] hppa*-*-* will not bootstrap on 4.6
branch with release checking
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


I can bootstrap GCC on hppa2.0w-hp-hpux11.11 with r170935 using the 4.6 branch
but I cannot bootstrap at r170938.  The only difference between these versions
is that DEV-PHASE was changed from experimental to prerelease.

The failure is:

/proj/opensrc_nobackup/nightly2/build-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/obj_gcc/./prev-gcc/xgcc
-B/proj/opensrc_nobackup/nightly2/build-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/obj_gcc/./prev-gcc/
-B/proj/opensrc_nobackup/nightly2/gcc-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/hppa2.0w-hp-hpux11.11/bin/
-B/proj/opensrc_nobackup/nightly2/gcc-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/hppa2.0w-hp-hpux11.11/bin/
-B/proj/opensrc_nobackup/nightly2/gcc-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/hppa2.0w-hp-hpux11.11/lib/
-isystem
/proj/opensrc_nobackup/nightly2/gcc-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/hppa2.0w-hp-hpux11.11/include
-isystem
/proj/opensrc_nobackup/nightly2/gcc-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/hppa2.0w-hp-hpux11.11/sys-include
   -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I.
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/.
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/../include
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/../libcpp/include
-I/proj/opensrc/be/hppa1.1-hp-hpux11.11/include
-I/proj/opensrc/be/hppa1.1-hp-hpux11.11/include
-I/proj/opensrc/be/hppa1.1-hp-hpux11.11/include 
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/../libdecnumber
-I/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/../libdecnumber/dpd
-I../libdecnumber   
/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/haifa-sched.c -o
haifa-sched.o
/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/haifa-sched.c: In
function 'rank_for_schedule':
/proj/opensrc_nobackup/nightly2/src/gcc-4_6-branch/gcc/haifa-sched.c:1293:1:
internal compiler error: in default_print_operand_address, at targhooks.c:344
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [haifa-sched.o] Error 1
make[3]: Leaving directory
`/proj/opensrc_nobackup/nightly2/build-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/obj_gcc/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory
`/proj/opensrc_nobackup/nightly2/build-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/obj_gcc'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory
`/proj/opensrc_nobackup/nightly2/build-hppa2.0w-hp-hpux11.11-gcc-4_6-branch/obj_gcc'
make: *** [bootstrap] Error 2

[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[sje at cup dot hp.com]

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

--- Comment #13 from Steve Ellcey  2011-03-17 20:10:06 
UTC ---
I got good builds on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.  I haven't
done a full test run yet.

[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[sje at cup dot hp.com]

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

--- Comment #14 from Steve Ellcey  2011-03-17 23:14:22 
UTC ---
I ran the GCC testsuite on the compilers I built with the patch and did not
have any regressions.

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-03-18 19:31:20 
UTC ---
Created attachment 23714
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23714
shorter test case

Shorter test case.  Reproducible on IA64 HP-UX as well with -mlp64 (and -O3
-fPIC).

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 19:33:15
 CC||sje at cup dot hp.com
 Ever Confirmed|0   |1

--- Comment #2 from Steve Ellcey  2011-03-18 19:33:15 
UTC ---
I can reproduce this using GCC 4.5.2 on HP-UX but I cannot reproduce it with
Top of tree or the 4.6 branch.

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-03-18 23:40:43 
UTC ---
It looks like this is the same problem as PR 43603 (but with a different error
result).  I can reproduce it on the trunk at r167587, but it is fixed at
r167588.

To fix it in the 4.5 branch we just need to backport the fix to PR 43603 to the
4.5 branch.

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[sje at cup dot hp.com]

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

--- Comment #9 from Steve Ellcey  2011-03-18 23:45:07 
UTC ---
Andrey,

I was just looking at PR 48191, a bug submitted against GCC 4.5.2.  It looks
like it is caused by the same problem that this patch fixes.  Can you back port
this fix to the 4.5 branch?  Also is there any reason not to close this defect
as resolved since it is fixed on the trunk and in 4.6.

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Steve Ellcey  2011-03-21 17:30:34 
UTC ---
This is a duplicate of 43603 which is fixed on ToT for 4.6 and later and should
be back ported on to the 4.5 branch.

*** This bug has been marked as a duplicate of bug 43603 ***

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[sje at cup dot hp.com]

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

--- Comment #11 from Steve Ellcey  2011-03-21 17:30:34 
UTC ---
*** Bug 48191 has been marked as a duplicate of this bug. ***

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #2 from Steve Ellcey  2011-03-21 21:42:02 
UTC ---
It looks like this is broken for HP-UX 11.11 and 11.23.  On 11.31 there is a
object that can be linked in (unix2003.o) to fix this.   Just like we currently
link in unix95.0 or unix98.o for UNIX 1995 or UNIX 1998 standards, if you link
in unix2003.o then you will get the UNIX 2003 standard and the correct C99
handling of snprintf.

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

--- Comment #4 from Steve Ellcey  2011-03-22 16:20:15 
UTC ---
I agree.  The test is not verifying whether or not snprintf is getting inlined
and that was what bug 47917 was about.  This should be a compile test that
looks for snprintf in the assembly code after compilation to verify that the
call was inlined.

In running this test on IA64 and x86, the first call is the only one that I see
getting inlined on both platforms at all optimization levels.

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2011-03-22 16:59:03 
UTC ---

I guess we disagree on what the test should be doing.  I agree that it is a
valid test for showing that nothing gets broken when doing the optimization,
but it is not a test that shows that the optimization is actually happening
(unless I am missing something).  If something were to change in GCC and we
stopped inlining snprintf, this test would continue to pass and we would not
know that we had a performance regression.

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

--- Comment #8 from Steve Ellcey  2011-03-22 17:13:29 
UTC ---
OK, that is what I was missing.  I didn't notice there was a second test to
check for that, sorry for the confusion.

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |sje at gcc dot gnu.org
   |gnu.org |

--- Comment #10 from Steve Ellcey  2011-03-22 19:42:54 
UTC ---
Yes, I can do that.  Do you know how the test fails on HP-UX 10.*?
Does it fail to compile or does it compile and then fail during execution like
it does on HP-UX 11.*?

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #13 from Steve Ellcey  2011-03-24 16:37:01 
UTC ---
Resolved by XFAIL'ing test on *-*-hpux10* and *-*-hpux1[12]*.

[Bug target/48288] [4.7 Regression] ld: Unsatisfied symbol "__iordi3" in file /test/gnu/gcc/objdir/./gcc/libgcc_eh.a

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.25 23:02:21
 CC||richard.sandiford at linaro
   ||dot org, sje at cup dot
   ||hp.com
 Ever Confirmed|0   |1

--- Comment #3 from Steve Ellcey  2011-03-25 23:02:21 
UTC ---
It looks to me like this started with r171341, Richard Sandiford's optab
cleanup patch.  I don't know exactly what the problem is but I verified that
r171340 bootstraps and r171341 does not.

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #32 from Steve Ellcey  2011-04-04 19:48:36 
UTC ---
Also failing on IA64 HP-UX and Linux.  With 171843, I get the comparision
errors, with 171845 (or ToT that includes the patch from #26), I get an ICE
during the stage2 build.



/proj/opensrc/nightly/src/trunk/gcc/errors.c:86:1: internal compiler error: in
max_issue, at haifa-sched.c:2524
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #3 from Steve Ellcey  2011-04-05 20:32:01 
UTC ---
Is this the same problem I am seeing on IA64:

/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error:
'debug_nesting' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error:
'symbol_queue' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error:
'symbol_queue_index' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error:
'symbol_queue_size' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors

I think it is coming from this change, though I don't see a ChangeLog
entry for it.


r171981 | froydnj | 2011-04-05 05:02:55 -0700 (Tue, 05 Apr 2011) | 8 lines

* debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete.
(debug_free_queue, debug_nesting, symbol_queue_index): Delete.
* final.c (debug_flush_symbol_queue, debug_queue_symbol):
Move these...
(debug_free_queue, debug_nesting, symbol_queue_index):
...and these...
* dbxout.c: ...to here.  Make static.

[Bug bootstrap/48471] New: ia64-*-* does not bootstrap due to unused variables in dbxout.c

[sje at cup dot hp.com]

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

   Summary: ia64-*-* does not bootstrap due to unused variables in
dbxout.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


I get these errors when bootstrapping on ia64-hp-hpux11.23.

/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error:
'debug_nesting' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error:
'symbol_queue' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error:
'symbol_queue_index' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error:
'symbol_queue_size' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors

I believe they were caused by this checkin:


r171981 | froydnj | 2011-04-05 05:02:55 -0700 (Tue, 05 Apr 2011) | 8 lines

* debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete.
(debug_free_queue, debug_nesting, symbol_queue_index): Delete.
* final.c (debug_flush_symbol_queue, debug_queue_symbol):
Move these...
(debug_free_queue, debug_nesting, symbol_queue_index):
...and these...
* dbxout.c: ...to here.  Make static.

[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-04-05 20:44:32 
UTC ---
FYI: I could not find a changelog entry for the r171981 change to dbxout.c.

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[sje at cup dot hp.com]

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

--- Comment #5 from Steve Ellcey  2011-04-05 20:43:47 
UTC ---
I have submitted it as PR 48471.

[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c

[sje at cup dot hp.com]

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

--- Comment #4 from Steve Ellcey  2011-04-05 21:20:09 
UTC ---
The patch looks good.  I haven't finished my bootstrap but I am in stage2 and
dbxout.c compiled correctly.

[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c

[sje at cup dot hp.com]

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

--- Comment #5 from Steve Ellcey  2011-04-05 23:12:25 
UTC ---
Bootstrap finished, everything looked good.

[Bug target/48629] New: ICE on gcc.dg/pr42389.c on ia64-*-* with -fsched-pressure

[sje at cup dot hp.com]

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

   Summary: ICE on gcc.dg/pr42389.c on ia64-*-* with
-fsched-pressure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


The test gcc.dg/pr42389.c started failing at r171845 on IA64 HP-UX and Linux.

obj_gcc/gcc/cc1 -O2 -fselective-scheduling -fsel-sched-pipelining
-fsched-pressure -quiet pr42389.c


pr42389.c: In function 'reset_path_costs':
pr42389.c:49:1: internal compiler error: in bundling, at
config/ia64/ia64.c:8842
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

ChangeLog:


2011-04-01  Bernd Schmidt  

* dwarf2out.h (dwarf2out_frame_debug_init): Declare.
* dwarf2out.c (dwarf2out_frame_debug_init): New function, broken
out of ...
(dwarf2out_frame_debug): ... here. Don't handle a NULL argument.
* final.c (final_start_function): Call the new function rather
than using a NULL argument for dwarf2out_frame_debug.

* ifcvt.c (cond_exec_process_insns): Disallow converting a block
that contains the prologue.

* haifa-sched.c (queue_insn): New arg REASON.  All callers
changed.  Print it in debugging output.

* sched-ebb.c (schedule_ebbs): Honor the BB_DISABLE_SCHEDULE flag.

* sched-ebb.c (begin_schedule_ready): Remove second argument.
Split most of the code into...
(begin_move_insn): ... here.  New function.
(ebb_sched_info): Add a pointer to it.
* haifa-sched.c (scheduled_insns): New static variable.
(sched_extend_ready_list): Allocate it.
(schedule_block): Use it to record the order of scheduled insns.
Perform RTL changes to move insns only after all scheduling
decisions have been made.
* modulo-sched.c (sms_sched_haifa_sched_info): Add NULL entry for the
begin_move_insn field.
* sel-sched-ir.c (sched_sel_haifa_sched_info): Likewise.
* sched-int.h (struct haifa_sched_info): Remove second argument
from begin_schedule_ready hook.  Add new member begin_move_insn.
* sched-rgn.c (begin_schedule_ready): Remove second argument.
(rgn_const_sched_info): Add NULL entry for the begin_move_insn field.

* haifa-sched.c (prune_ready_list): New function, broken out of
schedule_block.
(schedule_block): Use it.

[Bug target/48629] ICE on gcc.dg/pr42389.c on ia64-*-* with -fsched-pressure

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Steve Ellcey  2011-04-18 17:33:11 
UTC ---
The test is passing now on IA64 HP-UX and Linux.

[Bug target/48673] New: [4.7 Regression] GCC generates WAW and RAW conflicts on IA64.

[sje at cup dot hp.com]

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

   Summary: [4.7 Regression] GCC generates WAW and RAW conflicts
on IA64.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


Starting with version r171842, the tests gfortran.dg/sms-1.f90 and
gfortran.dg/sms-2.f90 are failing on IA64 HP-UX and Linux.  The failures
are excess messages during compilation like this:

$ 1.23-trunk/bin/gfortran -c sms-2.s <
sms-2.s: Assembler messages:
sms-2.s:413: Warning: Use of 'ldfs' violates RAW dependency 'GR%, % in 1 - 127'
(impliedf), specific resource number is 15
sms-2.s:413: Warning: Only the first path encountering the conflict is reported
sms-2.s:411: Warning: This is the location of the conflicting usage

The assembly code generated by GCC for sms-2.f90 has:

.L9:
;;
addp4 r15 = 0,r14
fadd.s f6 = f6, f7
ldfs f7 = [r15]
adds r14 = 4, r14
br.cloop.sptk.few .L9
;;

So we are changing r15 and using it in the same bundle and we should not be
doing that.   This could cause us to generate incorrect results.

To reproduce this you can compile sms-1.f90 with '-O2 -funroll-loops
-fmodulo-sched' or sms-2.f90 with '-O2 -fmodulo-sched'.

I am not sure if the problem is in the general scheduling code or in the IA64
specific target code.

[Bug target/48673] [4.7 Regression] GCC generates WAW and RAW conflicts on IA64.

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey  2011-04-27 21:58:53 
UTC ---
It looks like I was wrong about this showing up on IA64 Linux.  I am only
seeing it on IA64 HP-UX and only in 32 bit mode.  That probably means it is
related to the HP-UX pointer extension (addp4).  Do you have access to an HP-UX
system?

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-05-03 15:02:26 
UTC ---
Yes, I am seeing some new failures on IA64 HP-UX.  I do not get the stackalign
failures but I do get:

FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
DW_OP_addr[^
\n\r]*[\n\r]*[^\n\r]*staticvar1
FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
DW_OP_addr[^
\n\r]*[\n\r]*[^\n\r]*staticvar2
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+bar
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+foo

These showed up between 173204 and 173229 so they are probably due to the same
change.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2011-05-03 22:15:38 
UTC ---
The patch works for me on ia64-hp-hpux11.23.  It fixed the four new failures I
had and caused no regressions.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[sje at cup dot hp.com]

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

--- Comment #20 from Steve Ellcey  2011-05-06 23:04:21 
UTC ---
(In reply to comment #18)
> (In reply to comment #6)
> > The patch works for me on ia64-hp-hpux11.23.  It fixed the four new 
> > failures I
> > had and caused no regressions.
> 
> Steve, does the latest GDB work on ia64 hp-ux? You
> may see more regressions with the latest GDB.

GDB on ia64 hp-ux never really worked.  It only started building this year when
Joel Brobecker ported it but I was never able to get good results with it
(either testing or in actual use).

The HP WDB (based on an old GDB) works better but still has many shortcomings
when used with GCC.

[Bug tree-optimization/45781] New: GCC incorrectly puts function in .text.unlikely

[sje at cup dot hp.com]

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

   Summary: GCC incorrectly puts function in .text.unlikely
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


Created attachment 21875
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21875
Test case

If you compile the attached test case (x.c) with -O2 on ToT sources you will
find that init_target_chars is put into .text.unlikely instead of .text.  I
have verified this on IA64 HP-UX and Linux and on X86 Linux.  I do not think
this function should be put into .text.unlikely in this case and GCC 4.5 does
not do so.

It looks like this started with Honza's partial inlining change (r161382).

The following patch seems to fix the problem but I am not sure if it is the
correct fix or not.  Should node->frequency always be set in this case or
should the original value be preserved if no attribute is seen.  I do not
believe node->frequency is uninitialized because if I change the frequeny
enum in cgraph.h to make NODE_FREQUENCY_NORMAL a 0 value, the frequency
is still set to NODE_FREQUENCY_UNLIKELY_EXECUTED (unless I change predict.c).


Index: predict.c
===
--- predict.c   (revision 164573)
+++ predict.c   (working copy)
@@ -2204,6 +2204,8 @@ compute_function_frequency (void)
   else if (DECL_STATIC_CONSTRUCTOR (current_function_decl)
   || DECL_STATIC_DESTRUCTOR (current_function_decl))
 node->frequency = NODE_FREQUENCY_EXECUTED_ONCE;
+  else 
+node->frequency = NODE_FREQUENCY_NORMAL;
   return;
 }
   node->frequency = NODE_FREQUENCY_UNLIKELY_EXECUTED;

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug bootstrap/45737] Bootstrap comparison failure

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #4 from Steve Ellcey  2010-09-24 20:33:32 
UTC ---
I haven't seen this failure but I don't build with GMP and MPFR in my build
tree.  They are installed on the system instead and I use --with-gmp= and
--with-mpfr= on the configure line to point to where they live.  Doing the
build this way might give you a workaround if it is only the gmp and mpfr files
that differ during the bootstrap.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.24 21:06:43
   date||
 CC||sje at cup dot hp.com
 Ever Confirmed|0   |1

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[sje at cup dot hp.com]

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

--- Comment #5 from Steve Ellcey  2010-09-24 22:21:38 
UTC ---
I have verified that the bug shows up in r163443.  Looking at the assembly
language differences between 163442 and 163443, both versions have
_GLOBAL__I_65535_0__ZN2c12f6Ev,
a global routine to call the static initializer
(_Z41__static_initialization_and_destruction_0ii), but the new version also has
_GLOBAL__I__ZN2c12f6Ev to call the static initializer and this routine is not
global.  If I change the assembly language code to change the
GLOBAL__I__ZN2c12f6Ev function from static (.PARAM) to global (.EXPORT) then
the code will compile.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2010-09-24 23:45:28 
UTC ---
I have a patch I am testing.  It worked on the test case but I haven't fully
bootstrapped it.

Index: ipa.c
===
--- ipa.c   (revision 164578)
+++ ipa.c   (working copy)
@@ -1480,6 +1480,7 @@ build_cdtor (bool ctor_p, VEC (tree, hea
DECL_STATIC_CONSTRUCTOR (fn) = 0;
  else
DECL_STATIC_DESTRUCTOR (fn) = 0;
+ TREE_PUBLIC (fn) = 1;
  /* We do not want to optimize away pure/const calls here.
 When optimizing, these should be already removed, when not
 optimizing, we want user to be able to breakpoint in them.  */

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2010-09-30 17:41:36 
UTC ---
(In reply to comment #1)
> The decision is reasonable (I suppose partial inlining will inline the
> if (!init) case) as the function is called exactly once then and thus
> should be optimized for size and put into a separate section.

But when I compile with -O2, partial inlining doesn't inline anything.
All the calls still exist as they are in the code.  Actually, the only
reason I can see for moving init_target_chars to .text.unlikely is that
there are 3 'early returns' in fold_builtin_snprintf_chk that could prevent
the execution from ever getting to the init_target_chars call.  Maybe that is
why GCC put it in .text.unlikely.

Very strange, I added:

tree rewrite_call_expr() { return 0; }

to my test case and recompiled to see if this new code went into .text.unlikely
but for some reason that caused everything (including init_target_chars)
to be put into .text.

> 
> The question is thus, why does that break IA64 bootstrap?
> 
> If IA64 doesn't support .text.unlikely it should define
> UNLIKELY_EXECUTED_TEXT_SECTION_NAME appropriately.

Yes, I think I need to define this for IA64 HP-UX.

[Bug middle-end/45862] New: SUPPORTS_WEAK is documented as a C expression, used as a compile time constant

[sje at cup dot hp.com]

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

   Summary: SUPPORTS_WEAK is documented as a C expression, used as
a compile time constant
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


The hppa[12]*-hp-hpux11* platforms fail to bootstrap because they are using
SUPPORTS_WEAK as a C expression (as documented) but the GCC code actually
requires that SUPPORTS_WEAK be a constant because it is used in #if statements.

gcc/defaults.h contains:

# if SUPPORTS_WEAK
and
#if defined (TARGET_ASM_NAMED_SECTION) && SUPPORTS_WEAK

And looking through the defines during an hppa2.0w-hp-hpux11.11 build I see:

gcc/config/pa/som.h:#define SUPPORTS_WEAK (TARGET_SOM_SDEF && TARGET_GAS)
obj_gcc/gcc/options.h:#define target_flags global_options.x_target_flags
obj_gcc/gcc/options.h:#define MASK_GAS (1 << 4)
obj_gcc/gcc/options.h:#define TARGET_GAS ((target_flags & MASK_GAS) != 0)

This gives a syntax error when SUPPORTS_GCC expands to include
global_options.x_target_flags during compilation.  It used to not give a syntax
error (prior to r164723) but it was probably not working correctly either.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #10 from Steve Ellcey  2010-10-12 18:01:02 
UTC ---
These patches work for me on ia64 linux.  Can we get them checked in?

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #84 from Steve Ellcey  2010-10-13 17:36:15 
UTC ---

> > My patch is not finished and doesn't bootstrap, I'll look at it (promised) 
> > next
> > weekend.  I suggest just using BOOT_CFLAGS="-O2 -fno-forward-propagate".
> 
> I'll give it a try.  Currently, I have Bernd's change reverted.
> 
> Dave

I have done this on hppa64-hp-hpux11.11 and it worked for me.  (Actually, I
tweaked the code to turn off the forward propogate pass.)

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #17 from Steve Ellcey  2010-10-18 15:51:52 
UTC ---
(In reply to comment #16)
> Based on my posted test results for hppa2.0-hp-hpux11.11, this PR was
> fixed on the trunk between r163182 and r163254.
> 
> Need to find the change.

My nightly testing shows it fixed by r163218, I'll see if I can find the
exact version number.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #18 from Steve Ellcey  2010-10-18 16:55:32 
UTC ---
It looks like this was fixed (for hppa at least) in r163190.

2010-08-12  Richard Guenther  

PR tree-optimization/45232
* tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
for types with undefined overflow.
(reassociate_bb): Allow re-associating of bit and min/max
operations for types with undefined overflow.
* tree-ssa-forwprop.c (associate_plusminus): New function.
(tree_ssa_forward_propagate_single_use_vars): Call it.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #20 from Steve Ellcey  2010-10-18 17:54:42 
UTC ---
Not really, there are about 300 lines of new code (mostly in a new routine).
It might be that only the change in can_reassociate_p is needed to fix this
bug.
That would be a pretty easy backport and I verified that it fixes the testcase,
I haven't done a complete run with the change though.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #86 from Steve Ellcey  2010-10-18 19:52:39 
UTC ---
I was able to bootstrap the 32 bit PA compiler using the latest patch. I
haven't done a full test run yet but I will do that overnight.

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Steve Ellcey  2010-10-18 21:48:17 
UTC ---
Resolved by making IA64 more conservative in its bundling and not putting
multiple (predicated) instructions in one bundle if they read/write the same
register.

[Bug target/36898] Insufficient qp-mutex declarations

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sje at cup dot hp.com
 Resolution||FIXED

--- Comment #4 from Steve Ellcey  2010-10-18 21:49:10 
UTC ---
Resolved by making IA64 more conservative in its bundling and not putting
multiple (predicated) instructions in one bundle if they read/write the same
register.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #87 from Steve Ellcey  2010-10-19 16:09:57 
UTC ---
My testing on 32 bit and 64 bit PA boxes went fine.  The patch looks good to
me.

[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #3 from Steve Ellcey  2010-10-26 15:33:10 
UTC ---
I see this on all my HP-UX and Linux platforms too.

[Bug target/46044] ICE in get_attr_first_insn on ia64 Itanium

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.26 23:38:56
 CC||sje at cup dot hp.com
 Ever Confirmed|0   |1

--- Comment #2 from Steve Ellcey  2010-10-26 23:38:56 
UTC ---
I can reproduce this on the top of the 4.5 branch but not on ToT.  I am not
sure if there was a specific fix for this problem or if it doesn't happen on
ToT due to some unrelated change that makes the bug latent.

[Bug target/46044] ICE in get_attr_first_insn on ia64 Itanium

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2010-10-26 23:46:04 
UTC ---
This may be related to PR 43603.

[Bug middle-end/46204] New: g++.dg/torture/stackalign/throw-1.C fails to compile on IA64

[sje at cup dot hp.com]

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

   Summary: g++.dg/torture/stackalign/throw-1.C fails to compile
on IA64
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
  Host: ia64-*-*
Target: ia64-*-*
 Build: ia64-*-*


I am not sure exactly where this is going wrong but when
g++.dg/torture/stackalign/throw-1.C is compiled with -O3 -funroll-loops on IA64
I get an undefined label.

Here is a cutdown test case based on that test:

int global, global2;
int main()
{
int i,j,k,l,m,n;
   for (i=0; i < global; i++)
   for (k=0; k < j; k++)
   for (l=0; l < k; l++)
   for (m=0; m < l; m++)
   global2 = k;
 throw 0;
}

When I compile it I get:

g++ -O3 -funroll-loops x.C
/tmp/ccVWUtRi.o: In function `main':
x.C:(.text+0xc2): undefined reference to `.L34'
collect2: ld returned 1 exit status

[Bug rtl-optimization/46204] g++.dg/torture/stackalign/throw-1.C fails to compile on IA64

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.29 21:38:07
 CC||abel at gcc dot gnu.org
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1

--- Comment #1 from Steve Ellcey  2010-10-29 21:38:07 
UTC ---
It looks like this is a bug in the selective scheduler.  If I use
-fno-selective-scheduling then the label in question is not removed
and the program compiles correctly.

Marking it as confirmed since I see it in H.J. and Andreas test runs
sent to gcc-testresults.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #91 from Steve Ellcey  2010-10-29 22:29:10 
UTC ---
I just noticed that the latest patch is causing a failure of
gfortran.dg/large_real_kind_2.F90 with -O1 on my ia64-hp-hpux11.23 platform.

Note that the original bug we were fixing was on hppa, not ia64, and this test
doesn't fail on hppa.

On IA64 I am getting a segfault in fwprop:


#0  0x496a5c0:0 in VEC_df_mw_hardreg_ptr_stack_reserve (vec_=0xc, alloc_=1, 
file_=0x41ac338 "/proj/opensrc/sje/reg/src/trunk/gcc/df-scan.c", 
line_=2881, function_=0x41aca48 "df_ref_record")
#1  0x496a810:0 in VEC_df_mw_hardreg_ptr_stack_safe_push (vec_=0xc, 
obj_=0x40936f30, 
file_=0x41ac338 "/proj/opensrc/sje/reg/src/trunk/gcc/df-scan.c", 
line_=2881, function_=0x41aca48 "df_ref_record")
#2  0x4984470:0 in df_ref_record (cl=DF_REF_REGULAR, collection_rec=0x0, 
reg=0x65436df8, loc=0x6543b18c, bb=0x653da048, insn_info=0x40416b80, 
ref_type=DF_REF_REG_USE, ref_flags=4096)
#3  0x49858f0:0 in df_uses_record (collection_rec=0x0, loc=0x6543b18c, 
ref_type=DF_REF_REG_USE, bb=0x653da048, insn_info=0x40416b80, flags=0)
#4  0x4985bc0:0 in df_uses_record (collection_rec=0x0, loc=0x65438b08, 
ref_type=DF_REF_REG_USE, bb=0x653da048, insn_info=0x40416b80, flags=0)
#5  0x496fd40:0 in df_uses_create (loc=0x65438b08, insn=0x65438af0, 
ref_flags=0)
#6  0x6217f60:0 in try_fwprop_subst (use=0x4044b910, loc=0x6543b1a8, 
new_rtx=0x652d0050, def_insn=0x65438a28, set_reg_equal=0 '\000')
#7  0x621afd0:0 in forward_propagate_and_simplify (use=0x4044b910, 
def_insn=0x65438a28, def_set=0x65439ef0)
#8  0x621b780:0 in forward_propagate_into (use=0x4044b910)
#9  0x621bff0:0 in fwprop ()

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #93 from Steve Ellcey  2010-10-29 22:39:00 
UTC ---
(In reply to comment #92)
> See followup here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01636.html

Ah yes, that's better.

[Bug fortran/45636] Failed to fold simple Fortran string

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #13 from Steve Ellcey  2010-11-05 21:12:19 
UTC ---
I have moved gcc.c-torture/execute/pr45636.c to gcc.dg/torture/pr45636.c
and added a check for the mempcpy function so this should not fail on HP-UX or
Solaris which don't have a mempcpy function.

The change was r166378 and if the test failures are the only reason to keep
this bug report open then it we should be able to close it now.

[Bug fortran/45636] Failed to fold simple Fortran string

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from Steve Ellcey  2010-11-08 16:08:19 
UTC ---
The mempcpy is not inlined with -Os.  Presumbably because that would increase
the size of the resulting object.

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #1 from Steve Ellcey  2010-12-03 21:19:55 
UTC ---
It may be completely unrelated but I have a bunch of failures in C++ on IA64
HP-UX (and probably Linux) involving exceptions that I tracked back to the
latest GNU Assembler rather then any GCC change.  The change was made to the
ToT GAS sources on December 2 and the bug report I submitted is:

http://sourceware.org/bugzilla/show_bug.cgi?id=12287

This report mentions using ld 2.18 but it doesn't say what gas was used,
if it is not ToT then it is unrelated.

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #6 from Steve Ellcey  2011-06-08 17:35:43 
UTC ---
What would be the best way to implement 'dg-effective-target strict-align'?
A target list would be the easiest but a program that can pass/fail based
on STRICT_ALIGNMENT would probably be more robust.  I am not sure what such a
program would look like though.  Like memcpy-3.c?  I don't think we want the
dg-effective-target routines using -fdump flags like memcpy-3.c does.

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[sje at cup dot hp.com]

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

--- Comment #10 from Steve Ellcey  2011-06-08 18:12:40 
UTC ---
How about compiling this with -Wcast-align and looking for a warning message:

char *y;
typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
c *z;
void foo(void)
{
z = (c *) y;
}


I get a warning on IA64 but none on X86.  The warning is coming from
c-typeck.c.

x.c: In function 'foo':
x.c:6:13: warning: cast increases required alignment of target type
[-Wcast-align]

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[sje at cup dot hp.com]

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

--- Comment #12 from Steve Ellcey  2011-06-08 20:07:04 
UTC ---
Checking for a warning using check_no_compiler_messages seems as easy or easier
then checking the return code so I did that.  I have submitted a patch to
gcc-patches.

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00673.html

[Bug target/49349] New: gfortran.dg/char_result_3.f90 fails with -O3

[sje at cup dot hp.com]

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

   Summary: gfortran.dg/char_result_3.f90 fails with -O3
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: t...@codesourcery.com
Target: ia64-hp-hpux11*


Compiling gfortran.dg/char_result_3.f90 on IA64 HP-UX with the -O3 option
results in:

$ obj_gcc/gcc/f951 -O3 -quiet char_result_3.f90
char_result_3.f90: In function 'f4':
char_result_3.f90:71:0: internal compiler error: in bundling, at
config/ia64/ia6
4.c:8845

The failure started with r173853.

2011-05-18  Tom de Vries  

PR target/45098
* tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost

This only happens in 32 bit mode so I can't reproduce it on IA64 Linux.

If I turn off selective scheduling (-fno-selective-scheduling or
-fno-selective-scheduling2) it goes away.  I don't know if the bug is in the
scheduling or in this fix to PR 45098.

[Bug target/49349] gfortran.dg/char_result_3.f90 fails with -O3

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey  2011-06-13 19:29:56 
UTC ---
I tested the patch from comment #1 and it fixed gfortran.dg/char_result_3.f90. 
I got one regression on IA64 Linux but I can't reproduce it so I think it was
just a fluke.  There were no regressions on HP-UX.

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #7 from Steve Ellcey  2011-06-15 21:23:51 
UTC ---
I am also seeing some new failures on IA64 HP-UX (maybe Linux too, I am not
sure because my Linux run had other problems).  I see the same Fortran failures
that Dominique sees.

I also get a failure with gcc.dg/struct-by-value-1.c and I definitively tracked
that failure down to r175063.  I haven't verified that the Fortran failures
started with this exact version.

Should these bugs (mine and Dominiques) be a separate bug report?  They look
different then the IA32 failure.

[Bug rtl-optimization/49429] New: dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

   Summary: dse.c changes to fix PR44194 (r175063) cause execution
failures
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: era...@google.com
Depends on: 44194
Target: ia64-hp-hpux11* powerpc-apple-darwin9.8.0


The fix for PR 44194, version r175063, causes failures on ia64-hp-hpux11.23 and
powerpc-apple-darwin9.8.0.



gcc.dg/struct-by-value-1.c fails on HP-UX with -O2 optimization.  This was the
test I used on HP-UX to track down the specific version that caused the
failure.

These fortran tests fail on both platforms and I think are caused by the 
same checkin:


FAIL: gfortran.dg/dependency_25.f90  -O1  execution test
FAIL: gfortran.dg/dependency_25.f90  -O2  execution test
FAIL: gfortran.dg/dependency_25.f90  -Os  execution test
FAIL: gfortran.dg/der_array_1.f90  -O1  execution test
FAIL: gfortran.dg/der_array_1.f90  -O2  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O1  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O2  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer 
execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -g  execution test

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey  2011-06-15 22:37:24 
UTC ---
Created attachment 24540
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24540
Cut down version of gcc.dg/struct-by-value-1.c

This is a cutdown version of gcc.dg/struct-by-value-1.c that executes correctly
when compiled with -O2 before r175063 but calls abort after the change.

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-06-15 22:38:15 
UTC ---
Created attachment 24541
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24541
dse dump of x.c before change was made

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #4 from Steve Ellcey  2011-06-15 22:39:26 
UTC ---
Created attachment 24542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24542
dse dump of x.c after change was made

[Bug tree-optimization/49443] New: gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[sje at cup dot hp.com]

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

   Summary: gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on
IA64 after testsuite change
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: i...@il.ibm.com
Target: ia64-*-*


This Change:

r175009 | irar | 2011-06-14 00:00:37 -0700 (Tue, 14 Jun 2011) | 12 lines


* gcc.dg/vect/vect-16.c: Rename to...
* gcc.dg/vect/no-fast-math-vect16.c: ...this.
* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
for double-word vectors.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/bb-slp-10.c: Replace vect_hw_misalign with
vect_element_align.
* gcc.dg/vect/vect.exp: Run no-fast-math-* tests with

Caused gcc.dg/vect/vect-peel-3.c and gcc.dg/vect/vect-peel-4.c to
start failing on the ia64-*-* platforms (HP-UX and Linux).


FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/vect/vect-peel-4.c -flto scan-tree-dump-times vect "vectorized 1
loops" 1

[Bug tree-optimization/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-06-16 16:13:42 
UTC ---
Created attachment 24547
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24547
Dump file with vectorize details

Dump file from vect-peel-3.c when run with

-ftree-vectorize -fno-vect-cost-model -O2 -fdump-tree-vect-details