[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #9 from dave.anglin at bell dot net --- This is with Debian ld 2.34 on hppa-linux.
[Bug libstdc++/94275] /usr/ccs/bin/ld: Unsatisfied symbols: _ZNSs4_Rep20_S_empty_rep_storageE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94275 --- Comment #2 from dave.anglin at bell dot net --- There's a small chance the symbol disappeared due to an experimental change relating to PR 94253. Otherwise, nothing has changed in the PA back end for some time.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #12 from dave.anglin at bell dot net --- On 2020-03-23 1:37 p.m., danglin at gcc dot gnu.org wrote: > I don't see a define for __BIG_ENDIAN__. It seems we need this patch.
[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 --- Comment #7 from dave.anglin at bell dot net --- On 2020-04-09 1:53 p.m., rguenth at gcc dot gnu.org wrote: > Might also be interesting to try other strict-align targets with -fno-ipa-sra. > But - this might also be a speciality of the callee-copy ABI of hpux. I agree. The test doesn't fail on linux which we changed to caller copy.
[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 --- Comment #8 from dave.anglin at bell dot net --- On 2020-04-09 1:52 p.m., rguenth at gcc dot gnu.org wrote: > John, are you set up to bisect the testcase with an additional -fno-ipa-sra > flag? I can bisect but not in a very automated way.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #4 from dave.anglin at bell dot net --- On 2020-04-13 11:02 p.m., kargl at gcc dot gnu.org wrote: > Does math.h define fmaf? If yes, this this is bogus bug report. > If no, please disable building gfortran on hppa64. No, math.h does not define fmaf. Build was okay as of 20200403: https://gcc.gnu.org/pipermail/gcc-testresults/2020-April/558420.html === gfortran tests === Running target unix FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O0 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O1 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O2 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -g execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -Os execution test === gfortran Summary === # of expected passes51686 # of unexpected failures6 # of expected failures 201 # of unsupported tests 428 /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran version 10.0.1 20200403 (experimental) (GCC) I presume this was introduced by the following commit: commit 57391ddaf39f7cb85825c32e83feb1435889da51 Author: Fritz Reese Date: Tue Apr 7 11:59:36 2020 -0400 Fix PR fortran/93871 and re-implement degree-valued trigonometric intrinsics. 2020-04-01 Fritz Reese Steven G. Kargl gcc/fortran/ChangeLog PR fortran/93871
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #6 from dave.anglin at bell dot net --- On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > After '#include ' in trigd.c, add > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #endif > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #8 from dave.anglin at bell dot net --- On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > #ifdef HAVE_GFC_REAL_16 > #endif This one. > > Is hppa64 claiming support for a REAL type that it actually > doesn't support? Support is a fuzzy word. There's enough support to build libquadmath. > > In any event, you can extend the kludge > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #define cosl(a) cos((double)(a)) > #define sinl(a) sin((double)(a)) > #define tanl(a) tan((double)(a)) > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > #endif I have something that builds now. Need to test. I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Dave
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #10 from dave.anglin at bell dot net --- On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote: > So, hppa64 has REAL(16), but it does not use __float128 or > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead > of the above kludge you can do something like It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate. There's a similar problem with the test dec_math.f90 which has started to fail We have when the hpux long double library is available: /* Under HPUX, the __float128 type is a synonym for "long double". */ (*lang_hooks.types.register_builtin_type) (long_double_type_node, "__float128"); We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and __builtin_huge_valq. I suppose I could add "l" versions. #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif Yes, that seems an option.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #12 from dave.anglin at bell dot net ---
On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #11 from Steve Kargl ---
> On Tue, Apr 14, 2020 at 11:46:36PM +, dave.anglin at bell dot net wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>>
>> --- Comment #10 from dave.anglin at bell dot net ---
>> On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
>>> So, hppa64 has REAL(16), but it does not use __float128 or
>>> GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead
>>> of the above kludge you can do something like
>> It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate.
>> There's a similar problem with the test dec_math.f90 which has started to
>> fail
>>
>> We have when the hpux long double library is available:
>>
>> /* Under HPUX, the __float128 type is a synonym for "long double". */
>> (*lang_hooks.types.register_builtin_type) (long_double_type_node,
>> "__float128");
>>
>> We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and
>> __builtin_huge_valq.
>> I suppose I could add "l" versions.
>>
>
> This seems to be confusing the simply assumptions in
> libgfortran/kinds-override.h, which states
>
> /* What are the C types corresponding to the real(kind=10) and
>real(kind=16) types? We currently rely on the following assumptions:
> -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
> then it is necessarily the "long double" type
> -- if real(kind=16) exists, then:
> * if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
> * otherwise, real(kind=16) is "long double"
>To allow to change this in the future, we create the
>GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */
>
> #if defined(HAVE_GFC_REAL_16)
> # if defined(HAVE_GFC_REAL_10)
> # define GFC_REAL_16_IS_FLOAT128
> # if !defined(HAVE_FLOAT128)
> # error "Where has __float128 gone?"
> # endif
> # else
> # define GFC_REAL_16_IS_LONG_DOUBLE
> # endif
> #endif
>
> So, hpux does not have REAL(10) and has REAL(16). This is doing
> what it is designed to do based on the assumption that a target
> like hpux with REAL(16) will define the long double functions
> with the 'l' suffix. It seems the the fix for hpux is to change
> the test to something like
>
> # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
>
> using, of course, whatever the relevant macro. This will then
> select the 'q' suffix.
I tried the above approach yesterday but it led to a couple of undefined
symbols in libgfortran that
caused a new test fail. Possibly, the above might be a better overall approach
but this is what I ended
up doing last night:
diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..970c60952ee 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include
+#if (_POSIX_VERSION < 200112L)
+#define fmaf(a,b,c) ((a)*(b)+(c))
+#define fma(a,b,c) ((a)*(b)+(c))
+#endif
/*
For real x, let {x}_P or x_P be the closest representible number in the
@@ -169,7 +173,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
#define COSDcosd_r16
#define TANDtand_r16
-#ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */
+#if defined(GFC_REAL_16_IS_FLOAT128) || !defined(HAVE_COSL) /* libquadmath.
*/
#define SUFFIX(x) x ## q
#else
#define SUFFIX(x) x ## l
This fixed build of trigd.c. I think I need to do something similar to fix
dec_math.f90:
FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors)
Excess errors:
/usr/ccs/bin/ld: Unsatisfied symbols:
tanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
asinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
sinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
acosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
atanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
atan2l (first referenced in /var/tmp//ccLGIJFM.o) (code)
cosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
It's the only new fail.
It might be better to add configure checks for fmaf and fma.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #13 from dave.anglin at bell dot net --- On 2020-04-15 11:28 a.m., John David Anglin wrote: > I tried the above approach yesterday but it led to a couple of undefined > symbols in libgfortran that > caused a new test fail. The following symbols are missing: /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 This causes abort in PR19872.exe and other tests: 13 read(1,*)i (gdb) warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 Program received signal SIGABRT, Aborted. 0xc00423b0 in kill () from /usr/lib/dld.sl
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #16 from dave.anglin at bell dot net --- On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote: > It likely is the start of an approach, but it seems hpux is conflating > long double and __float128, where it flips between an 'l' and 'q' suffix. > gfortran simply assumes a correspondence with C types and C99 naming > conventions (e.g., sinf, sin, and sinl). If a target has REAL(4), REAL(8), > REAL(10), and REAL(16) the correspondence is float, double, long double, > and __float128, respectively. If a target has REAL(4), REAL(8), and REAL(16), > then the correspondence is float, double, and long double. There is no > __float128, and by extension, no functions with a 'q' suffix. The long > double math function will end in 'l'. It's not hpux conflating long double and __float128. On hppa, there's a IEEE 128-bit float type defined in the architecture and a limited set of arithmetic routines available to manipulate this type. There's no C99 support until HP-UX 11i version 2. Even then, no long double routines were implemented for PA-RISC. IA64 has REAL(10). There's routine for both double extended (w) and long double (l). Initially, the REAL(10) type was __float80. REAL(16) on IA64 is quad (q). __float128 is not used by HP-UX. There's no REAL(10) or REAL(16) on hppa. Treating REAL(16) as __float128 was my choice some years ago. It seemed compatible with gcc's __float128 on IA64 and I wanted to take advantage of libquadmath if possible.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #17 from dave.anglin at bell dot net --- On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote: > On Wed, Apr 15, 2020 at 06:04:08PM +0000, dave.anglin at bell dot net wrote: >> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from > This should be in libquadmath. > > % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt > strtoflt128.o: > 0880 T strtoflt128 > It is. The problem is read.o is looking for a data symbol. Need to look at libgfortran(read.o): /usr/ccs/bin/ld: Unsatisfied symbols: strtoflt128 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.a(read.o)) (data) There's a missing declaration for strtoflt128.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #18 from dave.anglin at bell dot net ---
On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> What does -fdump-tree-original show for
>
> function foo(x)
>real(16) foo, x
>foo = cos(x)
> end function foo
foo (real(kind=16) & restrict x)
{
real(kind=16) __result_foo;
__result_foo = __builtin_cosl (*x);
return __result_foo;
}
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #19 from dave.anglin at bell dot net ---
On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote:
> On Wed, Apr 15, 2020 at 06:04:08PM +0000, dave.anglin at bell dot net wrote:
>> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from
> This should be in libquadmath.
>
> % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt
> strtoflt128.o:
> 0880 T strtoflt128
>
This fixes the link issues but we are still left with cosl instead of cosq.
HP-UX doesn't support weak
very well.
diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..ba92fbd0cb1 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include
+#if (_POSIX_VERSION < 200112L)
+#define fmaf(a,b,c) ((a)*(b)+(c))
+#define fma(a,b,c) ((a)*(b)+(c))
+#endif
/*
For real x, let {x}_P or x_P be the closest representible number in the
diff --git a/libgfortran/kinds-override.h b/libgfortran/kinds-override.h
index baa0f7e1cb5..38e70be542a 100644
--- a/libgfortran/kinds-override.h
+++ b/libgfortran/kinds-override.h
@@ -34,7 +34,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */
#if defined(HAVE_GFC_REAL_16)
-# if defined(HAVE_GFC_REAL_10)
+# if defined(HAVE_GFC_REAL_10) || defined(__hpux__)
# define GFC_REAL_16_IS_FLOAT128
# if !defined(HAVE_FLOAT128)
# error "Where has __float128 gone?"
diff --git a/libquadmath/quadmath_weak.h b/libquadmath/quadmath_weak.h
index a97c813a013..2bbd2a11233 100644
--- a/libquadmath/quadmath_weak.h
+++ b/libquadmath/quadmath_weak.h
@@ -23,7 +23,7 @@ Boston, MA 02110-1301, USA. */
#include "quadmath.h"
-#if SUPPORTS_WEAK
+#if SUPPORTS_WEAK && !defined(__hpux__)
# define __qmath2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))) \
__quadmath_throw;
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #23 from dave.anglin at bell dot net --- On 2020-04-16 5:07 p.m., sgk at troutmask dot apl.washington.edu wrote: > It is unclear to me if the patch will meet everyone's > expectation. In particular, there are currently no > target-specific macros used in the Fortran frontend. > Using 'defined(__hpux__)' may make some unhappy as > it now complicates maintenance and adding new Fortran > features. Can I include "../../libgfortran/libgfortran.h" in these frontend routines? This would pull in the defines for GFC_REAL_16_IS_FLOAT128 and GFC_REAL_16_IS_LONG_DOUBLE.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #206 from dave.anglin at bell dot net --- Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and cc1plus?
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #31 from dave.anglin at bell dot net --- Fritz, I have a build going with the patch which I just attached. I realized last night that the change I made to address the problem with iroundq was wrong. I should be able to answer your questions shortly. I haven't looked at the patches in pr94694 but I believe that configure should be able to detect the core type used for REAL(16) from gfortran. kinds-override.h seems like a hack to me.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #33 from dave.anglin at bell dot net --- On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > If you have a functional gfortran you can also generate it with > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > expose the core type which gfortran uses for REAL(16) according to the target. Looking at script, I see it has same logic to disambiguate long double and float128: 16) if [ $long_double_kind -eq 10 ]; then ctype="__float128" cplxtype="_Complex float __attribute__((mode(TC)))" suffix="q" else ctype="long double" cplxtype="complex long double" suffix="l" fi ;; It always selects long double when both are REAL(16).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #35 from dave.anglin at bell dot net --- On 2020-04-22 12:27 p.m., sgk at troutmask dot apl.washington.edu wrote: > I suspect that having HPUX map > > REAL(4) <--> float ! f suffix > REAL(8) <--> double ! no suffix > REAL(16) <--> __float128 ! q suffix > > may cause issues with either ISO C binding or IEEE 754 module > or both. Why? It's what HP did? On ia64, libm contains a full quad implementation with q suffix. Both l and w sufixes are used with 80-bit floating types (long double and double extended). Many targets have double and long double both mapped to the same 64-bit floating type. So, I don't see why long double and __float128 can't be mapped to the same 128-bit floating type. It's been that way for years.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #208 from dave.anglin at bell dot net --- On 2020-04-23 11:48 a.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > Peter Bisroev changed: > >What|Removed |Added > > CC||peter.bisroev at groundlabs > dot co >||m > > --- Comment #207 from Peter Bisroev --- > (In reply to dave.anglin from comment #206) >> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and >> cc1plus? > Hi Dave, sorry for the delayed response. That is a good catch, I missed that > option before. I will be able to test this out this weekend. Will let you know > asap. I saw it perusing the comments for weak support on PA-RISC. I believe that I found that shared libraries are automatically garbage collected but applications are not. Dave
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #210 from dave.anglin at bell dot net --- On 2020-05-02 12:14 a.m., peter.bisroev at groundlabs dot com wrote: > Looks like we might have to get the fix into GNU AS first to get PCREL60B > working. I will try to look into how we can get this done hopefully next > weekend. I agree.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #212 from dave.anglin at bell dot net --- On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote: > --- Comment #211 from Jared --- > Are these errors the same as described above? > > It give the following 2 errors: > ld: The value 0xfe38a260 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x22 in > section index 222 of file > /library/home/build/tapecut5/code/lib/libsubo.a[file1.o] > ld: The value 0xfe587970 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x22 in > section index 2125 of file > /library/home/build/tapecut5/code/lib/libsubo.a[file2.o] Yes. Most likely these are references to weak symbols. Compiling with -Os might help. > > > > Using gcc version 4.2.3. On 64 bit HP-UX > Here is the raw command line. > /usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z > -L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom - > L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil > -L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar > y/home/build/tapecut5/code/spx/lib -lspx -lm -lcrypto -lssl -o > /library/home/build/tapecut5/code/bin/spectrum > > Is there a fix for this? Newer compiler or an option? > No. They block building latter versions of gcc that require g++.
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 --- Comment #30 from dave.anglin at bell dot net --- I'll test when I get a chance.
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 --- Comment #31 from dave.anglin at bell dot net --- On 2020-07-13 7:20 a.m., redi at gcc dot gnu.org wrote: > Dave, did you test this for the gcc-8 branch? Do you still want it backported > to that branch? Yes please. The patch applies cleanly on the gcc-8 branch. Then, we can close this PR. Thanks, Dave
[Bug libgomp/96661] configure:16984: error: unsupported system, cannot find Fortran int kind=16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661 --- Comment #2 from dave.anglin at bell dot net --- On 2020-08-17 2:10 p.m., burnus at gcc dot gnu.org wrote: > I do not see an easy way out; we had the same issue before with GCN and there > the solution was to add support for int128, cf. PR 96306. While this probably is possible, there is no library support for __int128. I guess as long as the "long long" type still maps to a 64-bit int this might be okay.
[Bug c++/79274] FAIL: g++.dg/tls/pr77285-2.C -std=c++11 scan-assembler _ZTH4var1B3tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79274 --- Comment #2 from dave.anglin at bell dot net --- On 2019-10-30 10:12 a.m., iains at gcc dot gnu.org wrote: > when you say "Think this is a result of emutls." - you mean that hppa is also > (Darwin does) using emuTLS? hppa uses emutls on hpux.
[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 --- Comment #1 from dave.anglin at bell dot net --- This is a target issue. I’m testing an include fix. Including stdint.h after inttypes.h would avoid the problem but I think header needs fixing. -- John David Anglin dave.ang...@bell.net
[Bug tree-optimization/93017] FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump graphite "tiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017 --- Comment #2 from dave.anglin at bell dot net --- On 2020-01-08 9:38 a.m., rguenth at gcc dot gnu.org wrote: > What ISL version are you using? dave@mx3210:~$ dpkg -l '*isl*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---==> ii libcloog-isl4:hppa 0.18.4-2 hppa Chunky Loop Generator (runtime> ii libisl-dev:hppa 0.22-2 hppa manipulating sets and relation> ii libisl15:hppa 0.18-4 hppa manipulating sets and relation> ii libisl19:hppa 0.20-2 hppa manipulating sets and relation> ii libisl22:hppa 0.22-2 hppa manipulating sets and relation> Debian 0.22-2 should be the one being used. The older libraries are linked into various gcc versions.
[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367
--- Comment #2 from dave.anglin at bell dot net ---
On 2020-01-21 9:55 p.m., dmalcolm at gcc dot gnu.org wrote:
> What's the definition of assert for this system?
extern void __assert(char *, char *, int);
# if defined(__cplusplus) && !defined(__STDCPP__)
# define assert(_EX) \
((_EX) ? (void)0 : __assert("_EX", __FILE__, __LINE__))
# else
# define assert(_EX) \
((_EX) ? (void)0 : __assert(#_EX, __FILE__, __LINE__))
# endif
I suppose an include hack could be done to add __attribute__((__noreturn__)).
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #114 from dave.anglin at bell dot net --- On 2020-01-22 7:18 p.m., peter.bisroev at groundlabs dot com wrote: > >From what I can see in my other tests, we need C++ compiler built with GCC > 4.7.4 to bootstrap GCC 6.1.0 and above. This is due to the fact that using C++ > compiler from 4.1.2 generates errors due to poisoned functions errors such as > this one: > > /opt/gcc-4.1.2/32/gcc-4.1.2/lib/gcc/ia64-hp-hpux11.31/4.1.2/include/stdlib.h:233: > error: attempt to use poisoned "calloc" > > > I specifically pointed version 6.1.0 out as it was the first version where > C++14 standard was enabled by default. So to get GCC 4.7.4 working we can > either try and figure out how to bootstrap it with HP's compiler or to work > from GCC 4.1.2 and figure out what broke with 4.2.0 and go from there. > > What are your thoughts? I would try to build 4.7.4 directly with aCC or gcc 3.3.6 (i.e., skip intermediates). Maybe just build C in your first attempt at 4.7.4. If I recall this thread correctly, the issue with C++ relates to linkonce and one-only support for C++. There are patches in this thread that fix some problems but not all... On my parisc build system, I have maxtsize set at 134217728. Maybe you should double your current value but that should be enough. This size command should show the actually text size of cc1 and cc1plus. A log of the size of cc1 is debug info. 4.1.2 is probably broken and has miscompiled 4.2.0. If you hit the same issue building 4.7.4, then it's worthwhile trying to debug the stack overflow. Getting this going is not likely to be easy... Dave
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #116 from dave.anglin at bell dot net --- On 2020-01-22 10:30 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #115 from Peter Bisroev --- > Hi Dave, > > (In reply to dave.anglin from comment #114) >> I would try to build 4.7.4 directly with aCC or gcc 3.3.6 (i.e., skip >> intermediates). > When I tried building 4.7.4 with aCC, 3-stage bootstrap completes > successfully. > It is only when I then use the newly built 4.7.4 to bootstrap itself again, > that is when I run into trouble as cc1 blows up in size when compiled with > 4.7.4. > > What I am not understanding though, is how come we can build everything > properly, all the stages when bootstraping with aCC but not with 4.7.4 itself? > I guess I can keep the binaries generated and see what is different. Will do > that soon. It's the stage1 compile flags, "-O0 -g", which generate the large binaries. Later stages are compiled with -O2. You could reduce the size of stage1 using "-Os" in STAGE1_CFLAGS and STAGE1_CXXFLAGS. I think it would be good to test 4.7.4 build with make check. > > I will also try using working 3.3.6 to try and build 4.7.4 as you have > suggested. Will let you know how that goes as well. Think your aCC build was probably fine apart from the maxtsiz issue. I would focus on it first. > >> Maybe just build C in your first attempt at 4.7.4. If I recall this thread >> correctly, the issue >> with C++ relates to linkonce and one-only support for C++. At some point, it will be necessary to investigate the capabilities of the HP linker regarding its linkonce and comdat section support. This could be run by building test programs with "aCC -S" to see generated assembly code.. > So far, whenever I have tried compiling just the C compiler with 4.7.4 I have > used the --enable-languages='c' configure flag. However it always ends up > building C++ as well. When I run "grep ^language= */config-lang.in" as > mentioned here (https://gcc.gnu.org/install/configure.html), I just get 'c++' > option and not 'c'. Maybe the ability to build C only has been deprecated? Or > maybe I am doing something wrong? Yes, the ability to build only c changed at some time in preparation for building with c++. > >> There are patches in this thread that fix some problems but not all... > Would you recommend I apply some of those patches or continue working on a > clean source tree for now? They aren't needed for 4.7.4 but will be needed for later versions. > >> On my parisc build system, I have maxtsize set at 134217728. Maybe you >> should double >> your current value but that should be enough. This size command should show >> the actually >> text size of cc1 and cc1plus. A log of the size of cc1 is debug info. > I will definitely try to use the "size" command in the future for that and > adjust maxtsize accordingly. I have definitely seen the binaries three times > your limit though. I will double check everything again though. Thanks for the > pointer! Note that maxtsiz relates to the maximum text size and not the total binary size. > >> 4.1.2 is probably broken and has miscompiled 4.2.0. If you hit the same >> issue building 4.7.4, >> then it's worthwhile trying to debug the stack overflow. > I have actually tried that as well. 4.1.2 cab build 4.7.4 perfectly fine, 3 > stage bootstrap completes successfully. It is then that 4.7.4 fails to > bootstrap itself due to maxtsize issue again. It is actually exactly the same > behavior as with aCC above. I will actually repeat the test and see what are > the sizes of the binaries in both cases and will let you know. By the way, > unless I am mistaken, should the output of stage3 be in theory the same > irrespective of whether host compiler to build stage1 was 3.3.6 or aCC? > >> Getting this going is not likely to be easy... > Does not look like it but already, thank you for your help so far! > > Cheers, > --peter >
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #122 from dave.anglin at bell dot net --- On 2020-01-25 1:18 a.m., peter.bisroev at groundlabs dot com wrote: > Hi Dave, after a bit of trial and error, I was able to get Tcl, expect and > DejaGnu to run from what I can tell. It also looks like that this is all that > is needed to run "make check-c" and "make check-c++". Would these two checks > be > good enough to start? > > I am currently running them both for 4.7.4 bootstrapped by aCC. Yes. There is a script in contrib/test_summary. If you run it in the top of your build directory and direct output to a file, it will generate a script to upload the test results to gcc. You may need to edit the mail command. Then, it will be easy for all to see results.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #123 from dave.anglin at bell dot net --- On 2020-01-24 10:50 p.m., peter.bisroev at groundlabs dot com wrote: > In the meantime, as per your suggestion, I have used the size tool to check > the > size of the text section, and it was much larger than maxtsiz. By making it > larger, I was successfully able do a 3-stage self bootstrap of 4.7.4 with > 4.7.4 > that was initially compiled with aCC. I did not have to use "-Os" with > STAGE1_CFLAGS. > Excellent. Just for reference, these are the stage1 sizes for cc1 and cc1plus on hpux: gcc-10: -bash-4.4$ /opt/gnu/bin/size cc1 cc1plus text data bss dec hex filename 55224904 5591924 360896 61177724 3a57f7c cc1 61375866 5977916 363928 67717710 4094a4e cc1plus gcc-9: -bash-4.4$ /opt/gnu/bin/size cc1 cc1plus text data bss dec hex filename 43213435 4681964 366408 48261807 2e06aaf cc1 46694968 4986436 369184 52050588 31a3a9c cc1plus On linux, the final -O2 file sizes are about 17M. The ia64 linux sizes are about 35M. Don't know why ia64 sizes are huge.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #125 from dave.anglin at bell dot net --- On 2020-01-25 7:59 p.m., peter.bisroev at groundlabs dot com wrote: > Please let me know what you would like me to try next. Let's look at testsuite log in /gcc/testsuite/gcc. This should show problem with weak. For example, UNRESOLVED: gcc.dg/weak/weak-1.c Also look at a hidden failure to see what's wrong with .hidden. Dave
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #127 from dave.anglin at bell dot net --- On 2020-01-25 9:16 p.m., peter.bisroev at groundlabs dot com wrote: > As can be seen above, stage1 binaries are just under 9 times the size of final > -O2 compiled binaries. I believe you have mentioned that this is due the use > of > -O0 for stage1 compilation. But is such increase as seen above expected? The stage1 sizes are much larger than I would have expected. However, I wouldn't worry about it since the compiler can rebuild itself. There must be a long pattern in ia64.md that's used a lot. Let's focus on issues important for c++.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #130 from dave.anglin at bell dot net --- On 2020-02-01 5:12 p.m., peter.bisroev at groundlabs dot com wrote: > At this point I have noticed that the objdump could not be executed while > running tests. Adding binutils-2.32 that I have compiled earlier to the PATH > allowed all the weak tests to pass. I obviously made some mistake running > $ make check-c check-c++ > initially, so I just kicked of another test run to see what the results will > be > using this command > $ gmake -j8 check-c check-c++ RUNTESTFLAGS="-v" I don't usually provide RUNTESTFLAGS. I only use it when I want to run a specific set of test. > > Will update you once I get the results. > > In the meantime, I wanted to ask you. Is it OK for me to add to the PATH > directory containing binutils-2.32 compiled with aCC prior to bootstrapping > GCC > 4.7.4? For bootstrapping I have provided actual utilities to configure script > directly with a flag such as `--with-as`. Currently this directory contains: > addr2line > ar > as > c++filt > elfedit > gprof > nm > objcopy > objdump > ranlib > readelf > size > strings > strip > As expected ld is missing from the above as on HPUX we need to use HP's > linker. > But what about the rest of the binaries? Will using them over comparable HP > ones cause any issues? I am asking as I have had issues with using binutils > provided binaries over system based ones when bootstrapping gcc on AIX. Yes. I do it all the time. I also configure with "--with-gnu-as --with-as=/opt/gnu/bin/as". It is import to use GNU as as it has same options and directives as it does on linux. The other programs aren't used much in the build but they are useful for debugging. > > The other question I wanted to ask, is my make check command above acceptable > or is there a better way to run these tests and get more information? There is more info in the "testsuite" directory. For example, for the c tests, look in /gcc/testsuite/gcc/gcc.log. There similar log files for every language and library. Dave
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #132 from dave.anglin at bell dot net --- On 2020-02-02 6:01 p.m., peter.bisroev at groundlabs dot com wrote: > h > Yes, I always use --with-as and --with-gnu-as on this platform. However after > putting binutils as the first entry in the PATH, the build failed as soon as > ar > from binutils got invoked. After a bit of digging around looks like my ar and > ranlib binaries from binutils are not working properly. For example: > > $ ./ar --help > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module > '/usr/lib/hpux32/libl.so.1'. > Killed > > But those symbols are present in libl.so from what I can see. For now I am > still using HP's ar and ranlib, will take a look into what is going on with > binutils ar and ranlib a bit later. This has been reported before on net. Maybe you should try using flex library. It provides the above symbols in its library.. You could try rebuilding binutils with your gcc-4.7.4 build and see how it works out. Run the testsuite. > >> There is more info in the "testsuite" directory. For example, for the c >> tests, look in >> /gcc/testsuite/gcc/gcc.log. There similar log files for every >> language and >> library. > Yep, I saw those the other day but thank you for the confirmation that I am > looking at the right files. > > Anyway, today I have rerun the "gmake -j8 check-c check-c++" so that tests can > find objdump, etc... Now a lot more tests have passed. The new results have > been sent to gcc-testresults mailing list and you can find them here: > > https://gcc.gnu.org/ml/gcc-testresults/2020-02/msg00150.html To me, the g++ test results are reasonable. So, I would suggest you try building gcc-8 or trunk with gcc-4.7.4.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #134 from dave.anglin at bell dot net --- On 2020-02-02 8:50 p.m., peter.bisroev at groundlabs dot com wrote: > The tests are from are binutils-2.32. > > - gas.log > FAIL: .file file names > FAIL: .file file names ordering > FAIL: .equ redefinitions (ELF) > FAIL: .set with expression > FAIL: good .bss / .struct data allocation directives > FAIL: gas/elf/missing-build-notes > FAIL: ia64 xdata (ilp32) > FAIL: ia64 unwind descriptors > > - binutils.log (they look like gas related failures) > FAIL: assembler generated build notes > FAIL: --localize-hidden test 1 > FAIL: readelf -S bintest I would suggest filing binutils bug reports for the above fails. Possibly, some just need xfails. Look at each test. > > Are any of these tests critical and would you want me to look at them in more > detail? The gas fails are more important than the binutils fails. The .equ, .set and .bss fails may be important. You are making progress.
[Bug ipa/92548] FAIL: gcc.dg/ipa/ipa-sra-12.c scan-ipa-dump-times sra "Will split parameter" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92548 --- Comment #3 from dave.anglin at bell dot net --- On 2020-02-05 1:31 p.m., jamborm at gcc dot gnu.org wrote: > The problem is that IPA-SRA does not handle structures passed by > invisible reference and 32bit hppa uses it. I would suggest xfailing > the scan it like we did in PR77732. John, since you can actually run > the testsuite on the target, can you do it? Okay. Thanks for working out issue.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #137 from dave.anglin at bell dot net --- On 2020-02-05 10:18 p.m., peter.bisroev at groundlabs dot com wrote: > I just had a chance to do some testing tonight. So attempting to bootstrap > 8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have > been > shown before. If I compile stage1 with '-O2' only, stage1 compiles, but > straight away we get > -- > /home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc > -nostdinc /dev/null -S -o /dev/null > -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests > cc1: internal compiler error: Segmentation fault > -- You need to at least apply patch from comment#72. This fixes regression from 4.7.x. You should also consider the last patch set from The Written Word. It was stated that it's possible to get a full bootstrap with it although there are issues.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #141 from dave.anglin at bell dot net --- On 2020-02-07 8:04 p.m., peter.bisroev at groundlabs dot com wrote: > Program received signal SIGSEGV, Segmentation fault > si_code: 1 - SEGV_MAPERR - Address not mapped to object. > 0x79e7a40 in () > (gdb) bt > #0 0x79e7a40 in () > warning: Attempting to unwind past bad PC 0x79e7a40 > #1 0x6c81c20 in > vector_builder::try_npatterns(unsigned > int)+0x2a0 () I'm not very familiar with selftest but it looks like the code has branched to a bad location in frame 1. Disassemble code around 0x6c81c20. Put a break before bad branch and try to figure out what's going wrong. Something is miscompiled. Probably it's in vector_builder.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #154 from dave.anglin at bell dot net --- On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote: > We already know that we currently cannot compile stage1 with -O0 as it causes > binaries to become huge and we get PCREL21B errors that were already described > here from HP's linker. I believe this issue needs to be fixed in bootstrap compiler. If I go back to the initial report, we had: ld: The value 0xfdf68820 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 74 of file libbackend.a[function.o] We need to go back and recompile function.c. Add "-save-temps -da". This will generate .s file and rtl dumps. I suspect the value above needs to be zero extended rather than pointer extended.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #156 from dave.anglin at bell dot net --- On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote: > However the above can be compiled with -O0 with the same compiler. So I > changed > my build line to use -O0 as well: > -- > gmake \ > STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \ > STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \ > STAGE1_TFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \ > BOOT_CFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \ > CFLAGS_FOR_TARGET='-g -O0 -D_XOPEN_SOURCE_EXTENDED' bootstrap Regarding the _XOPEN_SOURCE_EXTENDED define, I changed the PA-RISC backend to automatically enable the XOPEN extensions. See pa-hpux11.h. This makes the HP-UX c++ environment closer to Linux. I doubt you need to define STAGE1_TFLAGS. Likewise for CFLAGS_FOR_TARGET. You may want BOOT_CXXFLAGS.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #157 from dave.anglin at bell dot net --- On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote: > Just to confirm though, using gcc 4.7.4 that I have previously compiled with > aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with > default > build flags for STAGE1. Observe PCREL21B errors and manually recompile > affected > .c with "-save-temps -da". Is that correct? Right, we want to build stage1 with -O0. You can rebuild 4.7.4 or any other gcc version that demonstrates the PCREL21B error. Keep the build log so you can copy the compile options for the failing object. > > Do you want to apply any patches to 4.7.4 or compile original code as I have > done previously? No. We need to figure out why 4.7.4 generates incorrect PCREL21B relocations. Then, maybe we patch it.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #162 from dave.anglin at bell dot net --- On 2020-02-12 10:38 a.m., peter.bisroev at groundlabs dot com wrote: > The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was > compiling in parallel): > > ld: The value 0xfdc6eaf0 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file > libbackend.a[sancov.o] The value doesn't fit in 21 bits. The relocations are introduced by the assembler. You might check if the HP assembler can assemble sancov.s and see what type of relocations are used. You can run readelf on .o to see relocations. It looks like the problem is branches to weak functions. For example, br.call.sptk.many b0 = _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_# .section .gnu.linkonce.t._Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_,"ax",@progbits .align 16 .weak _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_# .proc _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_# _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_: Probably, the error arises when the call resolves to an instance that's a long way away. I think we need to find out why 21-bit branch is being used.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #166 from dave.anglin at bell dot net --- On 2020-02-12 5:26 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #165 from Peter Bisroev --- > Hi Dave, > > (In reply to dave.anglin from comment #162) >> On 2020-02-12 10:38 a.m., peter.bisroev at groundlabs dot com wrote: >>> The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was >>> compiling in parallel): >>> >>> ld: The value 0xfdc6eaf0 does not fit when applying the relocation >>> PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file >>> libbackend.a[sancov.o] >> The value doesn't fit in 21 bits. >> >> The relocations are introduced by the assembler. You might check if the HP >> assembler can assemble sancov.s and see what type of relocations are used. >> You can run readelf on .o to see relocations. > Unfortunately I was not able to assemble sancov.s using HPs assembler due to > too many syntax errors. So I tried to find something that can be compiled with > aCC. This might be a wrong approach but it was quick to test out so decided to > give it a go :) > >> It looks like the problem is branches to weak functions. > I went back to gcc 4.9.4 and tried doing stage1 bootstrap with '-O0'. As > expected, we got the same error (only relevant one shown for gimple-expr.c): > > ld: The value 0xfdf81640 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file > libbackend.a[gimple-expr.o] > > The dump for gimple-expr.c Unless I am mistaken, from the dump in attachment > 47828 it is a weak relocation. The problem is is the branch offset is too big. I believe GNU ld will create a PLTOFF entry in the PLT to handle this, but that's not happening with HP ld. In pa, we have have the -mlong-calls option which avoids these pc-relative branches. It would be helpful to know how aCC avoids this problem. > > I was then able to compile the same file but with aCC and attached results > (including an elfdump) in attachment 47829. Unless I am mistaken, weak > relocations are not being used. Is this something expected? It's the branch distance distance that's the main problem. Weak functions are available in C but they are much more common in C++. Have to run.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #168 from dave.anglin at bell dot net --- On 2020-02-13 12:24 a.m., peter.bisroev at groundlabs dot com wrote: > Tonight I have been trying to find a test case where this problem can be > reproduced with gcc and then compiled with aCC. Unfortunately no luck so far. > > With objdump I can see PCREL21B relocations in my .o files. However after the > final linking, disassembly shows direct short branch if the distance is small > enough and a call through a stub with brl.few if the distance is large enough. > I have almost no experience with IA-64 arch, but this behavior seems expected > to me. The ia64 PCREL21B relocation is very similar to the PA-RISC 2.0 R_PARISC_PCREL22F relocation. These determine the maximum branch distance by a pc-relative branch. I believe ia64 aligns code on 8-byte boundaries. PA-RISC aligns on 4-byte boundaries. So, in both cases a branch is capable of branching about 8 MB from call point. There seems to be something broken regarding stub insertion for calls to weak functions. Are we using the correct branch form for calls to weak? There doesn't seem to be a problem with branches to functions that aren't defined in the module. Could you try compiling sancov.c from gcc-8 with aCC in C++ mode. Use -S to get assembler output. What happens to weak calls (e.g., the one I pointed out previously)? Dave
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #173 from dave.anglin at bell dot net --- On 2020-02-13 1:11 p.m., peter.bisroev at groundlabs dot com wrote: > If I try to compare this to aCC dump in attachment 47840, I do not see any > calls to weak. Equivalent section to the above dump in gimple-expr.s > (_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also > gimple-expr.o.objdump on line 2099. I believe the place where with gcc we > expect to see a call to tree_operand_length() through PCREL21B reloc, aCC does > similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181). I looked at the definition and branches to _Z18tree_operand_checkPK9tree_nodeiPKciS3_ in the gimple-expr.s file that you uploaded. We have the following: .type _Z18tree_operand_checkPK9tree_nodeiPKciS3_,@function .global _Z18tree_operand_checkPK9tree_nodeiPKciS3_ .size _Z18tree_operand_checkPK9tree_nodeiPKciS3_, 784 // Routine [id=0064] ( tree_operand_check ) // === .secalias .abe$170.text, ".text" .section .abe$170.text = "axC", "progbits", .abe$comdat0010 .align 16 .proc _Z18tree_operand_checkPK9tree_nodeiPKciS3_ ..L0: // $start ARid768 = ;; // A ..L2: _Z18tree_operand_checkPK9tree_nodeiPKciS3_:: .prologue // $entry ARid770, S:r32, S:r33, S:r34, S:r35, S:r36 = ;; // A [tree.h: 3177/1] //file/line/col tree.h/3177/1 .save ar.pfs, r39 alloc r39 = ar.pfs, 5, 4, 5, 0 // M [tree.h: 3177/1] br.ret.dptk.many rp ;; // B [tree.h: 3181/3] ..L1: // $end ;; // A .endp _Z18tree_operand_checkPK9tree_nodeiPKciS3_ nop.m 0 // M nop.i 0 // I nop.m 0 // M nop.m 0 // M br.call.dptk.many rp = _Z18tree_operand_checkPK9tree_nodeiPKciS3_# ;; // B [gimple-expr.c: 658/3] add r9 = 0, r8 // M [gimple-expr.c: 658/3] .secalias .abe$comdat0010, "_Z18tree_operand_checkPK9tree_nodeiPKciS3_" The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT sections. Probably, HP ld does support weak but it's unlikely there is support for linkonce sections. See defines in config/pa/som.h. There we implimented one only support using the linker's COMDAT support. Regarding the call to _Z18tree_operand_checkPK9tree_nodeiPKciS3_, this is preceeded by a bunch of nops. This is probably to allow linker to modify call should it select a different instance of _Z18tree_operand_checkPK9tree_nodeiPKciS3_.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #174 from dave.anglin at bell dot net --- On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote: > The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT > sections. Probably, HP ld does support > weak but it's unlikely there is support for linkonce sections. See defines in > config/pa/som.h. There we implimented > one only support using the linker's COMDAT support. Is HAVE_COMDAT_GROUP defined in auto-host.h?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #177 from dave.anglin at bell dot net --- On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote: > I have tried playing around with weak using aCC, however even though it > accepts > both attribute and pragma (and complains if you misspell "weak"), both > compiler > and linker seem to ignore it. But I might have made some mistake there, will > double check tonight. Did you look at .s output? You could also test a simple program with a weak function in two objects. My sense is the situation will be similar to hppa64-hpux11. Weak is partially supported in that calls to a weak function resolve to a single instance. However, undefined weak is not really supported. While the linker errors can be overridden, the dynamic linker will object to applications with undefined weak symbols. We worked around this with a libgcc_stub.a library and a linker script. HP ld also probably leaves all the instances of weak linkonce functions contributing to bloat.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #178 from dave.anglin at bell dot net --- On 2020-02-13 6:04 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #176 from Peter Bisroev --- > (In reply to dave.anglin from comment #174) >> On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote: >>> The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT >>> sections. Probably, HP ld does support >>> weak but it's unlikely there is support for linkonce sections. See defines >>> in >>> config/pa/som.h. There we implimented >>> one only support using the linker's COMDAT support. >> Is HAVE_COMDAT_GROUP defined in auto-host.h? > For both 4.9.4 and 8.3.0, gcc/auto-host.h contains only one reference to that: > > /* Define 0/1 if your assembler and linker support COMDAT groups. */ > #ifndef USED_FOR_TARGET > #define HAVE_COMDAT_GROUP 0 > #endif > The configure test didn't find support for COMDAT groups even though aCC and HP ld support them. So, there's likely something incompatible with the default support for COMDAT groups. Could you look at configure test and see why it fails?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #182 from dave.anglin at bell dot net --- On 2020-02-14 11:04 p.m., peter.bisroev at groundlabs dot com wrote: > However just below this check, configure looks for GNU linker, and if one not > found, disables COMDAT group support even though the second test passed. > > However `--enable-comdat` configure flag seems to override this behavior. I > will try to recompile 4.7.4 with it to see what happens. That's useful information. I'll bet same applies to hppa64.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #183 from dave.anglin at bell dot net ---
On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #180 from Peter Bisroev ---
> (In reply to dave.anglin from comment #177)
>> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
>>> I have tried playing around with weak using aCC, however even though it
>>> accepts
>>> both attribute and pragma (and complains if you misspell "weak"), both
>>> compiler
>>> and linker seem to ignore it. But I might have made some mistake there, will
>>> double check tonight.
>> Did you look at .s output? You could also test a simple program with a weak
>> function
>> in two objects.
> Sorry Dave, not 100% sure what kind of test you are talking about. Something
> like this?
> --
> // func0.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 1;
> }
>
> // main.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 10;
> }
>
> int main(int argc, char * argv[]) {
> return func0(argc);
> }
> --
>
Yes. Does it link okay?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #184 from dave.anglin at bell dot net --- On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote: > So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3 > stage bootstrap went fine (running 'make check' now). Using that tried to > bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues > when linking cc1plus. For example: So, it looks like we have garbage collection for COMDAT functions but not for weak functions. I think we need to look at branch types - "br.call.sptk.many" versus "br.call.dptk.many". I suspect using the latter would fix the PCREL21B relocation issues.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #188 from dave.anglin at bell dot net --- On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote: > I have not had a chance to look through these in great detail, will do this > later today, but some things I've noticed (not sure how important they are > yet): > - aCC seems to use PCREL21BI relocations while GCC PCREL21B. That may be the clue. With GNU ld, only PCREL21BI goes through PLT. Need to look at when GNU as uses PCREL21BI instead of PCREL21B. I believe this selection is done in assembler.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #189 from dave.anglin at bell dot net --- On 2020-02-16 4:21 p.m., John David Anglin wrote: > On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote: >> I have not had a chance to look through these in great detail, will do this >> later today, but some things I've noticed (not sure how important they are >> yet): >> - aCC seems to use PCREL21BI relocations while GCC PCREL21B. > That may be the clue. With GNU ld, only PCREL21BI goes through PLT. Need to > look at when > GNU as uses PCREL21BI instead of PCREL21B. I believe this selection is done > in assembler. Sorry, only PCREL21B goes through PLT. PCREL21BI is for local (internal) calls.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #191 from dave.anglin at bell dot net --- On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #190 from Peter Bisroev --- > (In reply to dave.anglin from comment #189) >> On 2020-02-16 4:21 p.m., John David Anglin wrote: >>> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote: >>>> I have not had a chance to look through these in great detail, will do this >>>> later today, but some things I've noticed (not sure how important they are >>>> yet): >>>> - aCC seems to use PCREL21BI relocations while GCC PCREL21B. >>> That may be the clue. With GNU ld, only PCREL21BI goes through PLT. Need >>> to look at when >>> GNU as uses PCREL21BI instead of PCREL21B. I believe this selection is >>> done in assembler. >> Sorry, only PCREL21B goes through PLT. PCREL21BI is for local (internal) >> calls. > Hi Dave, I apologize for the delay in response, been a busy week so far. > However I should be able to take a look at this further tomorrow. > > As per your recommendation I will try and find out when GNU as generates > PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want > in order to match aCC behavior, right? I Peter, no problem. I've been busy... The problem seems to be that HP ld doesn't handle the PCREL21B relocation correctly when it refers to a weak function (i.e., it doesn't direct the call through the PLT). At the same time, weak references don't seem to work with aCC. As far as I can tell, the PCREL21B is generated by gas in gas/config/tc-ia64.c at line 5919. You could try changing it to PCREL21BI to see if that helps (run binutils testsuite before installing) but the change doesn't seem correct. We might need to generate a 32-bit branch to weak functions in gcc. It would be useful to find out why weak doesn't work with aCC.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #193 from dave.anglin at bell dot net ---
On 2020-02-21 7:36 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #192 from Peter Bisroev ---
> (In reply to dave.anglin from comment #191)
>> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
>> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
>> correctly when it refers
>> to a weak function (i.e., it doesn't direct the call through the PLT). At
>> the same time, weak references
>> don't seem to work with aCC.
>>
>> As far as I can tell, the PCREL21B is generated by gas in
>> gas/config/tc-ia64.c at line 5919. You could try
>> changing it to PCREL21BI to see if that helps (run binutils testsuite before
>> installing) but the change doesn't
>> seem correct. We might need to generate a 32-bit branch to weak functions
>> in gcc.
> Hi Dave, thanks for the hint! I have patched by binutils 2.32 as shown in the
> diff below.
> --
> *** ./gas/config/tc-ia64.c.orig Fri Feb 21 23:52:59 2020
> --- ./gas/config/tc-ia64.c Fri Feb 21 23:54:04 2020
> ***
> *** 5919,5925
> else if (opnd == IA64_OPND_TGT25b)
> fix->code = BFD_RELOC_IA64_PCREL21M;
> else if (opnd == IA64_OPND_TGT25c)
> ! fix->code = BFD_RELOC_IA64_PCREL21B;
> else if (opnd == IA64_OPND_TGT64)
> fix->code = BFD_RELOC_IA64_PCREL60B;
> else
> --- 5919,5925
> else if (opnd == IA64_OPND_TGT25b)
> fix->code = BFD_RELOC_IA64_PCREL21M;
> else if (opnd == IA64_OPND_TGT25c)
> ! fix->code = BFD_RELOC_IA64_PCREL21BI;
> else if (opnd == IA64_OPND_TGT64)
> fix->code = BFD_RELOC_IA64_PCREL60B;
> else
> --
>
> After recompiling binutils gas failed only two more unit tests than before:
> --
> FAIL: ia64 tls
> FAIL: ia64 relocations
> --
> After looking at both of these I guess it is expected as both of them expect
> PCREL21B instead of PCREL21BI.
>
> I have then attempted to recompile gcc 4.7.4 with this patched gas.
> Unfortunately that fails during linking when xgcc tries to build
> hpux64/libgcc_s.so.0.tmp in 64bit mode during stage 1. An example of an error
> is:
> --
> ld: Unsatisfied symbol"calloc" in file "emutls_s.o": Expect to be defined in
> the load module.
> --
>
> Taking a quick look at emutls_s.o I can see the expected reallocation
> --
> $ readelf -r ./ia64-hp-hpux11.31/hpux64/libgcc/emutls_s.o | grep calloc
> 04d2 00220079 R_IA64_PCREL21BI calloc + 0
> --
>
> But I have not dug dipper as to why the HP linker is unhappy there. Please let
> me know if you want me to do so.
This was expected. R_IA64_PCREL21BI is only supposed to be used for local
symbols.
This test confirms it.
Changing gas isn't going to help.
>
>> It would be useful to find out why weak doesn't work with aCC.
> I wanted to see if there is some offical docs on this from HP.
>
> Going through aCC's programmers guide
> (https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=emr_na-c05054285)
> for my version of aCC ("HP C/aC++ B3910B A.06.29 [Oct 18 2016]", "as: HP
> Itanium Assembler B.11.31 (HP-UX/itanium)", "ld: 92453-07 linker ld HP
> Itanium(R) B.12.65 IPF/IPF"). I cannot find anything relevant to 'weak' in
> section 3, or generally in that reference guide.
>
> "Intel(R) Itanium(R) Architecture Assembly Language Reference Guide"
> (https://software.intel.com/sites/default/files/m/d/4/1/d/8/asm_lan.pdf) does
> mention weak symbols. This is also the same syntax that HP's as seems to
> accept.
>
> However in "HP-UX Linker and Libraries User Guide"
> (https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00055697en_us)
> on page 59, for nm, it states:
> --
> Distinguish between weak and global symbols by appending * to the key letterof
> weak symbols.
> --
>
> So it looks like HP's as and ld should support weak symbols so I have decided
> to test it.
>
> --
> // main.cc
>
> extern "C" {
> void hello() __attribute__ ((weak));
> }
>
&g
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #196 from dave.anglin at bell dot net --- On 2020-02-21 10:55 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #194 from Peter Bisroev --- > (In reply to dave.anglin from comment #193) >> I presume that if you compile main.cc with g++, hello() becomes weak. You >> could test with a second instance of hello. > Yes, sorry forgot to mention that. When I compile with gcc hello() becomes > weak > as expected. One question though, what do you mean with the second instance of > hello? If you create a second object file with a second instance of hello, the linker should not complain about the second definition of hello since it is weak. It would complain about two global instances. One major difference between GNU weak definitions and HP sdef definitions is that the HP linker and dynamic loader don't like undefined sdef symbols. In PA-RISC, there's no way to override this in the dynamic loader. > The comdat testing that I have performed in comment 181 and comment 185 by > forcing the use of comdat with --enable-comdat definitely made things better > as > we got a significant reduction in PCREL21B linking errors. However some still > remained. Is it because the use of --enable-comdat did not apply to all the > code (such as libraries), or even when usage of comdat is forced, HP's ld > still > keeps unnecessary instances around? I don't know whether HP's ld removes unecessary comdat instances. Even with comdat groups enabled, I think we still have some use of weak because of how MAKE_DECL_ONE_ONLY is defined. Could you test whether the "brl" branch works? Simply take your main.s file and edit the branch to hello. This should show whether the assembler can handle it. If it assembles, look at relocation and see if program will link.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #197 from dave.anglin at bell dot net --- On 2020-02-21 11:43 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #195 from Peter Bisroev --- > Hi Dave, > > I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX > Porting Guide" > (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577&rep=rep1&type=pdf). > I know it is not from hpe.com but seems to be an official HP document HP-UX > 11i > v2 and later. > > Anyway, on page 56, it states: > -- > In Solaris, symbols can be set with a pragma to be weak, which means that > these > symbols are always overridden by any global definition. If an undefined weak > symbol is never satisfied by a global definition, it is set to 0 before the > program starts execution. HP_SECONDARY_DEF symbols are similar to Solaris weak > symbols, but there are some differences. You can use the _HP_SECONDARY_DEF > pragma to connect a weak and a strong definition (for example, _fopen and > fopen). The weak definition can be overridden by other strong definitions. > -- > > I guess that confirms your statement about sdef. > > On page 85, it states: > -- > The ELF file format provides support for global, local, and weak symbols. > Creating these symbols requires support from the compiler. The HP C and HP C++ > compilers do not provide support for weak symbols. > > The HP-UX 11i v2 and later assembler (/usr/ccs/bin/as) provides support using > the .weak directive. Example 7-3 “Weak Function Binding Using ASM” defines > weakfunc to be a weak binding to func. Details on the assembler can be found > in > the Itanium Architecture Assembly Language Reference Guide. > -- > I guess that confirms your suspicion that aCC does not support weak symbols > and > my results that .weak is supported by HP's assembler. Yes. Thus, ia64 running hpux is essentially the same as hppa64 running hpux in its support for weak (sdef) symbols. We didn't hit the long branch issue I guess because pc-relative branches go a factor of two further, and maybe the -O0 code generation is denser.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #199 from dave.anglin at bell dot net --- On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote: > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when > I try to run the binary I get an "Illegal instruction" and a core dump. The > illegal instruction seems to be the brl. I know almost nothing of IA-64 > assembly, so will read up a bit more and try to figure out what is going on > there. That suggests to me that HP's aCC generates 64-bit ELF code and gcc generates 32-bit code. Compare header info of the two executable files with readelf. I'm not sure why we are struggling with the 32-bit runtime.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #201 from dave.anglin at bell dot net --- On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote: > They both seem to be ELF32 Maybe run failing program under gdb to find faulting instruction. Compare with executable that works.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #203 from dave.anglin at bell dot net --- On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote: > Now looking at the main.o generated by gcc, the relocation seems to be as > expected but the relocation address seems to be off: > -- > 20: 04 00 00 00 01 00 [MLX] nop.m 0x0 > 21: PCREL60Bhello > 26: 00 00 00 00 00 00 brl.call.sptk.many b0=20 > 2c: 08 00 00 d0 > -- > > As can be seen above, GNU as is telling HP's ld to do the relocation at 0x21, > which falls into slot 1 and 0. However the relocation needs to be done at 0x26 > to cover slots 2 and 1. Comparing with HP as, it looks to me like the relocation should be at 0x22 and that's why the preceding nop.m instruction is being clobbered. Would you file a binutils bug report with the main.s gcc source? It looks like gcc doesn't generate brl branches and this never got tested. You can add me to the cc list.
[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 --- Comment #3 from dave.anglin at bell dot net 2013-02-04 16:03:08 UTC --- One thought I had is to add the -fpic option. This should push the function descriptor into .data.
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
--- Comment #4 from dave.anglin at bell dot net 2013-02-13 14:09:26 UTC ---
On 2013-02-12 6:03 PM, vries at gcc dot gnu.org wrote:
> I've tried to reproduce this bug by building a cross compiler using the
> hppa2.0w-unknown-linux-gnu target. I managed to build libjava, but I didn't
> manage to reproduce the bug.
Yes. it doesn't reproduce on linux.
>
> The thing I can see that's wrong is in NEXT_INSN (insn 11), which is note 152
> but which should be note 153:
> ...
> (insn 428 427 153 (sequence [
> (jump_insn:TI 151 427 11 (set (pc)
> (if_then_else (eq (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
> [123])
> (const_int 10 [0xa]))
> (label_ref:SI 165)
> (pc)))
> /test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
> 28 {*pa.md:1439}
> (expr_list:REG_DEAD (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
> [123])
> (expr_list:REG_BR_PROB (const_int 2800 [0xaf0])
> (nil)))
> -> 165)
> (insn 11 151 152 (set (reg:SI 7 %r7 [orig:129 D.12038 ] [129])
> (reg:SI 5 %r5 [orig:132 ivtmp.903 ] [132])) 40
> {*pa.md:2211}
> (nil))
> ])
> /test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
> -1
> (nil))
>
> (note 153 428 152 [bb 19] NOTE_INSN_BASIC_BLOCK)
>
> (note 152 153 276 19 ("*L$Jpc=71164") NOTE_INSN_DELETED_LABEL 395)
> ...
I'll give your patch a try later today when my current build and check
finishes. I could give you
access to this test system if the change doesn't work out.
Thanks for looking at this bug.
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242 --- Comment #7 from dave.anglin at bell dot net 2013-02-14 13:56:13 UTC --- Patch fixes ICE on hppa2.0w-hp-hpux11.11. Testsuite running...
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #2 from dave.anglin at bell dot net 2013-02-15 15:55:07 UTC --- On 2013-02-15 9:44 AM, jakub at gcc dot gnu.org wrote: > > Target doesn't use crtstuff.c. > Why? That looks like the bug to me. It only supports ELF and COFF file formats, and not SOM.
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307
--- Comment #11 from dave.anglin at bell dot net 2013-03-12 18:27:01 UTC ---
On 3/12/2013 1:59 PM, jakub at gcc dot gnu.org wrote:
> I think -fvar-tracking-assignments is disabled by default if selective
>
> scheduler is enabled, but I doubt that is the case of pa. In any case, you
>
> could try
>
> to add -fvar-tracking-assignments explicitly to dg-options.
This does seem to make a difference:
;; Function foo (foo, funcdef_no=0, decl_uid=1351, cgraph_uid=0)
Created a debug-only replacement for s offset: 0, size: 32
Created a debug-only replacement for s offset: 32, size: 8
Created a debug-only replacement for s offset: 40, size: 8
Created a debug-only replacement for s offset: 48, size: 16
foo (int x)
{
char * p;
struct S s;
Dave
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 --- Comment #12 from dave.anglin at bell dot net 2013-03-13 01:50:05 UTC --- On 12-Mar-13, at 1:48 PM, jamborm at gcc dot gnu.org wrote: > I'm just guessing, but is it possible that MAY_HAVE_DEBUG_STMTS is 0 > > even with -g on hppa-hpux? Yes, your guess is correct. 1) In dbx_debug_hooks, var_location is debug_nothing_rtx. 2) This causes flag_var_tracking to be set to 0 at toplev.c:1412. 3) flag_selective_scheduling and flag_selective_scheduling2 are both 0, so flag_var_tracking_assignments is set to flag_var_tracking at toplev.c:1435. This only happens when flag_var_tracking_assignments initially has the AUTODETECT_VALUE. Explicitly passing the -fvar_tracking_assignments option overrides this. -- John David Anglindave.ang...@bell.net
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #7 from dave.anglin at bell dot net 2013-03-13 15:23:11 UTC --- On 3/13/2013 10:42 AM, jason at gcc dot gnu.org wrote: > That's odd, the change seems unlikely to have changed the flow analysis. But > > anyway, this patch always initializes addr. Better? I hacked the original patch to avoid the error. Change fixed the test failures, so approach looks good. Will test new patch.
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 --- Comment #2 from dave.anglin at bell dot net 2013-04-04 15:57:16 UTC --- On 4-Apr-13, at 11:41 AM, redi at gcc dot gnu.org wrote: > Drat, I completely forgot these still aren't available everywhere, > sorry. There's some kind of implementation in libatomic but it hasn't been built when the error occurs. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 --- Comment #5 from dave.anglin at bell dot net 2013-04-06 15:18:44 UTC --- > --- Comment #4 from Jonathan Wakely > 2013-04-05 10:14:42 UTC --- > > Dave, does it work after rev 197512 ? Two thumbs up! Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #6 from dave.anglin at bell dot net 2013-05-03 11:27:33 UTC --- On 3-May-13, at 6:11 AM, amylaar at gcc dot gnu.org wrote: > The preprocessed testcase from the first attachment fails needs a > different > > sanity check in convert_mult_to_fma, which I have added in this > amended patch. Yes, I just found that build still fails with first patch at same place. Will try amended patch. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #7 from dave.anglin at bell dot net 2013-05-04 23:03:36 UTC --- On 3-May-13, at 6:11 AM, amylaar at gcc dot gnu.org wrote: > Created attachment 30016 > > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30016 > > amended patch Works for me. Thanks, Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/53420] [4.8 Regression] ICE in iterative_hash_expr, at tree.c:7039
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53420 --- Comment #4 from dave.anglin at bell dot net 2012-08-18 23:50:21 UTC --- On 15-Aug-12, at 4:16 AM, jakub at gcc dot gnu.org wrote: > Can you still reproduce it? My HP-UX 11.00 box had a disk failure a couple of weeks ago, so I can't reproduce it at the moment. I only saw this problem with 11.00. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #2 from dave.anglin at bell dot net 2012-08-20 16:23:57 UTC --- On 8/20/2012 11:46 AM, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 > > --- Comment #1 from Marc Glisse 2012-08-20 > 15:46:58 UTC --- > Wow, I didn't expect that patch to break a multiplication test... > It sounds like you have before and after compilers. Do you have tree-vrp dumps > from both? (I would ask if a stage1 compiler fails too, to rule out > miscompilation of the compiler, but I have no idea how ada works...) At the moment, I have no idea as to which module is broken but I believe the problem is in the Ada runtime library. I compared the .o files for the first test of the four failing tests using before and after compilers and they were identical. The ada tests are not compiled with debugging enabled, so they are a bit difficult to debug. The tests invoke a lot of arithmetic operations... > Is hwint 32 bits on this platform? I am looking for acats testresults from > other such platforms in gcc-testresults but can't find them... > Yes, hwint is 32 bits. I just fixed a couple of issues with expand_mult (PR middle-end/53823). The synth_mult code can't handle multiplication by negative coefficients when the mode is larger than a hwint. One possibility might be that this code is being invoked by another path.
[Bug debug/54460] FAIL: g++.dg/debug/dwarf2/nested-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54460 --- Comment #2 from dave.anglin at bell dot net 2012-09-02 23:41:30 UTC --- On 2-Sep-12, at 2:12 PM, sch...@linux-m68k.org wrote: > This uses yet another comment character. Thanks. I'll see if adding it to the regexp helps. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251 --- Comment #12 from dave.anglin at bell dot net 2012-09-23 22:40:10 UTC --- Test hasn't been removed. I also don't see the fail anymore. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #2 from dave.anglin at bell dot net 2012-09-30 00:50:17 UTC --- On 29-Sep-12, at 7:34 PM, paolo.carlini at oracle dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 > > --- Comment #1 from Paolo Carlini > 2012-09-29 23:34:20 UTC --- > I suppose _GLIBCXX_USE_C99_MATH_TR1 remains undefined on hppa-hpux, > right? Yes. > > In that case, I would pre-approve a patch changing each of the three > uses of > the C99 hypot in include/ext/random and include/ext/random.tcc with > std::sqrt(x*x + y*y) as a fall back, like: > > #if _GLIBCXX_USE_C99_MATH_TR1 >*__f++ = std::hypot(__x, __y); > #else >*__f++ = std::sqrt(__x * __x + __y * __y); > #endif There is an implementation of hypot, so I'm wondering if we can't do better. Testing suggestion. Dave -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #12 from dave.anglin at bell dot net 2012-09-30 16:06:52 UTC --- On 30-Sep-12, at 10:19 AM, glisse at gcc dot gnu.org wrote: > Dominique, it would be more useful if you could show your libstdc++ > config.log, > and in particular the error message you got for the test "for ISO > C99 support > to TR1 in ", to know what functions are missing on darwin > (or hppa or > others), assuming there isn't already a PR somewhere about it. FWIW, the HP-UX 11.11 list is: configure:18907: checking for ISO C99 support to TR1 in configure:19031: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/ test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/ src/.libs -B/o pt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/ hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/ include -isy stem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include-c -g - O2 -std=c+ +98 conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:67:16: error: 'acoshf' was not declared in this scope acoshf(0.0f); ^ conftest.cpp:68:16: error: 'acoshl' was not declared in this scope acoshl(0.0l); ^ conftest.cpp:70:16: error: 'asinhf' was not declared in this scope asinhf(0.0f); ^ conftest.cpp:71:16: error: 'asinhl' was not declared in this scope asinhl(0.0l); ^ conftest.cpp:73:16: error: 'atanhf' was not declared in this scope atanhf(0.0f); ^ conftest.cpp:74:16: error: 'atanhl' was not declared in this scope atanhl(0.0l); ^ conftest.cpp:77:15: error: 'cbrtl' was not declared in this scope cbrtl(0.0l); ^ conftest.cpp:80:25: error: 'copysignl' was not declared in this scope copysignl(0.0l, 0.0l); ^ conftest.cpp:82:14: error: 'erff' was not declared in this scope erff(0.0f); ^ conftest.cpp:83:14: error: 'erfl' was not declared in this scope erfl(0.0l); ^ conftest.cpp:85:15: error: 'erfcf' was not declared in this scope erfcf(0.0f); ^ conftest.cpp:86:15: error: 'erfcl' was not declared in this scope erfcl(0.0l); ^ conftest.cpp:88:15: error: 'exp2f' was not declared in this scope exp2f(0.0f); ^ conftest.cpp:89:15: error: 'exp2l' was not declared in this scope exp2l(0.0l); ^ conftest.cpp:91:16: error: 'expm1f' was not declared in this scope expm1f(0.0f); ^ conftest.cpp:92:16: error: 'expm1l' was not declared in this scope expm1l(0.0l); ^ conftest.cpp:94:21: error: 'fdimf' was not declared in this scope fdimf(0.0f, 0.0f); ^ conftest.cpp:95:21: error: 'fdiml' was not declared in this scope fdiml(0.0l, 0.0l); ^ conftest.cpp:96:22: error: 'fma' was not declared in this scope fma(0.0, 0.0, 0.0); ^ conftest.cpp:97:26: error: 'fmaf' was not declared in this scope fmaf(0.0f, 0.0f, 0.0f); ^ conftest.cpp:98:26: error: 'fmal' was not declared in this scope fmal(0.0l, 0.0l, 0.0l); ^ conftest.cpp:100:21: error: 'fmaxf' was not declared in this scope fmaxf(0.0f, 0.0f); ^ conftest.cpp:101:21: error: 'fmaxl' was not declared in this scope fmaxl(0.0l, 0.0l); ^ conftest.cpp:103:21: error: 'fminf' was not declared in this scope fminf(0.0f, 0.0f); ^ conftest.cpp:104:21: error: 'fminl' was not declared in this scope fminl(0.0l, 0.0l); ^ conftest.cpp:106:22: error: 'hypotf' was not declared in this scope hypotf(0.0f, 0.0f); ^ conftest.cpp:107:22: error: 'hypotl' was not declared in this scope hypotl(0.0l, 0.0l); ^ conftest.cpp:109:16: error: 'ilogbf' was not declared in this scope ilogbf(0.0f); ^ conftest.cpp:110:16: error: 'ilogbl' was not declared in this scope ilogbl(0.0l); ^ conftest.cpp:112:17: error: 'lgammaf' was not declared in this scope lgammaf(0.0f); ^ conftest.cpp:113:17: error: 'lgammal' was not
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #14 from dave.anglin at bell dot net 2012-09-30 17:15:24 UTC --- On 30-Sep-12, at 12:16 PM, paolo.carlini at oracle dot com wrote: > Hopeless ;) Actually, the situation might not be completely hopeless as the libquadmath support works... I had planned to implement the long double aliases but haven't had time to get around to it. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #16 from dave.anglin at bell dot net 2012-09-30 18:04:26 UTC --- I will commit the attached change if there are no objections. -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739 --- Comment #4 from dave.anglin at bell dot net 2012-10-01 23:51:23 UTC --- Thanks Ulrich for your analysis. On parisc, I believe it would be best to remove iordi3, anddi3, etc, for 32-bit targets if they are successfully split. Testing a fix. -- John David Anglindave.ang...@bell.net
[Bug target/26472] Default path for libgcc_s.sl is build directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472 --- Comment #17 from dave.anglin at bell dot net 2012-10-03 22:39:46 UTC --- On 3-Oct-12, at 6:18 PM, anilkris at hotmail dot com wrote: > I am getting the following error when I run a concurrent programs in > Oracle > R12.1.3, which calls a Pro *C executable. > > /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 > /usr/lib/dld.sl: No such file or directory > /d701/oracle/cfo/bin/CFORPPL > Program was terminated by signal 6 This issue isn't related to bug. Whether SHLIB_PATH is used or not depends on how applications and libraries are linked. The chatr program can be used to see how an application or library has been linked, and the library paths. It may be possible to use chatr to adjust the settings so the error doesn't occur. Library paths are hardcoded during linking. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #3 from dave.anglin at bell dot net 2012-10-08 14:45:48 UTC --- On 8-Oct-12, at 10:18 AM, bernds at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 > > --- Comment #2 from Bernd Schmidt > 2012-10-08 14:18:58 UTC --- > Could you attach both dumps? (and use -fsched-verbose=5) Done. > Did your test include r191838? No but the bug is still present with r191838. Dumps are from r191493. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #4 from dave.anglin at bell dot net 2012-10-08 14:45:51 UTC --- Created attachment 28389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28389 20041113-1.c.224r.sched2.txt
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #2 from dave.anglin at bell dot net 2012-10-15 11:55:29 UTC --- On 15-Oct-12, at 2:44 AM, ubizjak at gmail dot com wrote: > The patch just introduces -funwind-tables to compile flags, so I > really don't > see how this can cause any difference. I hacked configure to turn -funwind-tables off on hpux. It is the cause of the comparison difference. The difference isn't caused by incorrect code. Think the compare needs to be ignored on hpux. Dave -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #10 from dave.anglin at bell dot net 2012-10-19 18:33:27 UTC --- I'm not seeing the fail with the candidate patch.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #2 from dave.anglin at bell dot net 2012-11-04 02:52:31 UTC --- On 3-Nov-12, at 4:45 PM, amylaar at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 > > --- Comment #1 from Jorn Wolfgang Rennecke gnu.org> 2012-11-03 20:45:10 UTC --- > Could you attach preprocessed source and the exact options passsed > to cc1 > (from -v --save-temos compilation) so that I can look at this in a > cross > environment? Unfortunately, -v -save-temps doesn't save the java source from a list input. So far, I've only seen this with jc1. I imagine this is because the input is huge. This is compilation command: /home/dave/gnu/gcc/objdir/./gcc/jc1 ../../../gcc/libjava/classpath/lib/ gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide- subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline- functions -quiet -dumpbase HTML_401F.class -auxbase-strip gnu/javax/ swing/text/html/parser/.libs/HTML_401F.o -g -O2 -Wno-deprecated - version -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/home/ dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/classpath/lib/classes -fPIC -fbootclasspath=./:../../../gcc/libjava/classpath/lib/ -faux-classpath HTML_401F.zip -MD_ -MT gnu/javax/swing/text/html/parser/HTML_401F.lo - MF gnu/javax/swing/text/html/p arser/HTML_401F.deps -o HTML_401F.s Dave -- John David Anglindave.ang...@bell.net
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #6 from dave.anglin at bell dot net 2012-11-04 22:23:04 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: > The instruction call_symref_pic_post_reload has the following length > attribute setting: > > (set (attr "length") (symbol_ref "pa_attr_length_call (insn, 0)")) > > Such a length attribute is not considered variable by > shorten_branches. > > You need to include a clause that is directly in the attribute, e.g. > (and (match_test "0") (eq (match_dup 0) (pc))) Thanks Jorn for debugging this. Dave -- John David Anglindave.ang...@bell.net
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #7 from dave.anglin at bell dot net 2012-11-04 23:50:44 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: > Such a length attribute is not considered variable by > shorten_branches. > > You need to include a clause that is directly in the attribute, e.g. > (and (match_test "0") (eq (match_dup 0) (pc))) In some sense, this seems like a hack which might be optimized by an attribute processor. What about a way to mark length attributes as variable? Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #2 from dave.anglin at bell dot net 2012-11-05 00:20:16 UTC --- On 3-Nov-12, at 10:38 PM, pinskia at gcc dot gnu.org wrote: > Exposed as this is a change in the library and the compiler is > crashing with a > valid input that the change introduced. The ICE occurs because we get a TF mode REG instead of a MEM. -- John David Anglindave.ang...@bell.net
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #10 from dave.anglin at bell dot net 2012-11-06 12:26:06 UTC ---
On 5-Nov-12, at 11:20 AM, amylaar at gcc dot gnu.org wrote:
> I take back that statement about this being straightforward. We
> need valid
> minimum and maximum instruction lengths. The opaque dummy clause
> automatically
> provides a value to be included in these calculations.
This is failing at -O0:
(define_insn ""
[(set (reg:SI 29)
(div:SI (reg:SI 26) (match_operand:SI 0 "div_operand" "")))
(clobber (match_operand:SI 1 "register_operand" "=a"))
(clobber (match_operand:SI 2 "register_operand" "=&r"))
(clobber (reg:SI 26))
(clobber (reg:SI 25))
(clobber (reg:SI 31))]
"!TARGET_64BIT"
"*
return pa_output_div_insn (operands, 0, insn);"
[(set_attr "type" "milli")
(set (attr "length")
(cond [(and (match_test "0") (eq (const_int 0) (pc)))
(const_int 24)]
(symbol_ref "pa_attr_length_millicode_call (insn)")))])
The insn is actually a millicode call (branch) which needs to be able
to reach stub table. Different variants are generated depending on
pc. I modified the opaque clause a bit as I decided I didn't want to it
to depend on operand 0. Don't see how a negative length can arise.
spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/
gcc/ -fno-d
iagnostics-show-caret -O0 -w -c -o 2427-1.o /home/dave/gnu/gcc/gcc/
gcc/tests
uite/gcc.c-torture/compile/2427-1.c/home/dave/gnu/gcc/gcc/gcc/
testsuite/gcc.c-torture/compile/2427-1.c: In func
tion 'ConvertFor3dDriver':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: err
or: negative insn length
(insn 47 46 48 (parallel [
(set (reg:SI 29 %r29)
(div:SI (reg:SI 26 %r26)
(reg:SI 25 %r25)))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 19 %r19 [125]))
(clobber (reg:SI 26 %r26))(clobber (reg:SI 25
%r25))
(clobber (reg:SI 31 %r31))
]) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:8 122 {*pa.md:5433}
(nil))
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: int
ernal compiler error: in shorten_branches, at final.c:1162
0x537f7b _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../gcc/gcc/rtl-error.c:110
0x308df7 shorten_branches(rtx_def*)
../../gcc/gcc/final.c:1162
0x3094e3 rest_of_handle_shorten_branches
../../gcc/gcc/final.c:4368
Dave
--
John David Anglindave.ang...@bell.net
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #13 from dave.anglin at bell dot net 2012-11-07 00:39:01 UTC --- On 6-Nov-12, at 10:40 AM, amylaar at gcc dot gnu.org wrote: > I see now that you get INT_MAX substituted as the maximum length if > the > value is unknown. > > If you add anything to that, the value becomes negative. > I suppose your only get-out-of-jail card with the current interface, > if > you can't/won't provide a full cond with constant values, is to let > ADJUST_INSN_LENGTH obliterate the MAX_INT, and replace it with > something > sensible. It appears that I need to provide the min length instead of the max length in the opaque condition. Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when it is MAX_INT, then the error won't occur. For the call patterns, the number of permutations got out of hand and impossible to maintain. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 --- Comment #11 from dave.anglin at bell dot net 2012-11-07 17:17:47 UTC --- On 11/7/2012 8:29 AM, jakub at gcc dot gnu.org wrote: > Which test started failing? pr53410 was failing here http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg02016.html but the problem seems to have gone away in later runs. Dave
[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 --- Comment #22 from dave.anglin at bell dot net 2012-11-10 01:28:52 UTC --- If possible, I think SJLJ support should go. I can't remember the exact status of SJLJ for HP-UX 10 but a comment in hpux-unwind.h suggests that I tested dwarf2 support. I can check but it will take time. Dave -- John David Anglindave.ang...@bell.net
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #8 from dave.anglin at bell dot net --- On 25-Jul-13, at 12:51 AM, jasonwucj at gmail dot com wrote: > John, does your case happen on 32-bit only as well? Yes. -- John David Anglindave.ang...@bell.net
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #9 from dave.anglin at bell dot net --- On 25-Jul-13, at 6:56 AM, amylaar at gcc dot gnu.org wrote: > hwint.h says that HOST_WIDE_INT should be 64 bit when targeting a > machine with > 64 bit size_t. You can insure that by setting need_64bit_hwint in > gcc/config.gcc / libcpp/configure.ac . Although the former has a > different > description what it's for. So either the comment there is lacking, or > the comment in hwint.h just says how to paper over bugs in various (?) > places in the compiler that don't use the highpart of an INTEGER_CST > for > what it's for. The 32-bit linux and hpux targets have a 32-bit size_t and the error occurs with a native build. Dave -- John David Anglindave.ang...@bell.net
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #2 from dave.anglin at bell dot net ---
On 5-Sep-13, at 7:31 PM, hubicka at ucw dot cz wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
>
> --- Comment #1 from Jan Hubicka ---
>> Symbol has type data which is wrong for procedure label:
>>
>> Symbols from system_error.o:
>>
>> ValueInfo Type Scope ck HQIRCDSKLN xl reloc Name
>>
>> Data Unsat 0 .. 3 0
>> _ZNKSt14error_category23default_error_conditionEi.localalias.9
>
> The code introduces the symbol as an static alias of function.
> I.e. something like
>
> void foo (void) { }
> void foo.localalias (void) __attribute__ ((alias "foo"));
>
> Can this be latent bug in HPPA backend not handling well aliases
> like this?
> (this was indeed an issue on AIX).
I wouldn't be surprised.
I don't have assembler output or preprocessed source yet. There is
some alias
support in gas for HP-UX but I believe it may not work when we have a
call using
a function descriptor (plabel).
Dave
--
John David Anglindave.ang...@bell.net
