[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #14 from dave.anglin at bell dot net --- On 2024-05-29 8:17 a.m., ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 > > --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #12 from dave.anglin at bell dot net --- >> It will be a few days before I can test. I've had three hard drives fail on >> my >> main hppa >> system in the past few weeks. > I guess it's best to postpone committing to the gcc-14 branch until you > can report hppa results then. Btw., when you're ready, could you also > check the libbacktrace test results (no .sum file, unfortunately, just > buried deeply in make check output) for comparison? Thanks. Change fixes the following libstdc++ tests on hppa-linux: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test The libbacktrace tests all pass on hppa-linux.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #12 from dave.anglin at bell dot net --- It will be a few days before I can test. I've had three hard drives fail on my main hppa system in the past few weeks.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #13 from dave.anglin at bell dot net --- With the patch, we now have: name7161.cc:5: error: #error '__cpp_lib_text_encoding' is false compiler exited with status 1 UNSUPPORTED: std/text_encoding/cons.cc -std=gnu++26 UNSUPPORTED: std/text_encoding/members.cc -std=gnu++26 name7161.cc:5: error: #error '__cpp_lib_text_encoding' is false compiler exited with status 1 UNSUPPORTED: std/text_encoding/requirements.cc -std=gnu++26 The FAILs are gone.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #11 from dave.anglin at bell dot net --- On 2024-03-22 3:00 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > --- Comment #10 from Jonathan Wakely --- > This two depend on _GLIBCXX_USE_NL_LANGINFO_L which is set by: > >AC_TRY_COMPILE([ >#include >#if __has_include() ># include >#endif >#include >],[ > locale_t loc = newlocale(LC_ALL_MASK, "", (locale_t)0); > const char* enc = nl_langinfo_l(CODESET, loc); > freelocale(loc); >], [ac_nl_langinfo_l=yes], [ac_nl_langinfo_l=no]) newlocale/freelocale aren't supported on hpux, so test needs to be skipped or xfailed. https://www.gnu.org/software/gnulib/manual/html_node/newlocale.html
[Bug libstdc++/114368] FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368 --- Comment #2 from dave.anglin at bell dot net --- I'll see if it's reproducible,
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #10 from dave.anglin at bell dot net --- Warning is fixed on hppa.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #13 from dave.anglin at bell dot net ---
On 2024-03-10 12:15 a.m., law at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
>
> --- Comment #12 from Jeffrey A. Law ---
> Aren't we compiling for PA2.0? If so, shouldn't we have a full 14 bit offset
> support, even when a load/store hits the FP register file (feel free to
> correct
> me if I'm wrong, it's only been 20 years since I worked on this stuff ;-)
Unfortunately, the PA2.0 relocation for 14-bit offsets in floating-point loads
and stores is broken
and can't be used on linux. Works fine on hpux.
Needs to be fixed.
>
> So I don't really see why the offsets are an issue here.
At this time, we are limited to 5-bit offsets for floating-point loads and
stores.
>
>
> If we were compiling for PA1.0/PA1.1, then yes, there's a real issue, but it's
> with allowing the larger offsets as a legitimate address. That's lying to the
> compiler, reload in particular and as I said, it's ultimately going to
> backfire
> -- even with the workaround since you're going to have DImode loads/stores to
> the FP register file due to xmpyu or potentially even memcpy and friends. I
> already tried what you're doing years ago. It's doomed to failure.
>
> You might think this is a reload problem. But I'm far from convinced. It
> smells much more like a PA backend issue to me.
I think the problem is with pa_secondary_reload. There is code in
pa_emit_move_sequence
to handle reloads for for floating-point loads/stores from REG+D addresses but
it isn't being
used.
In non-pic code, the reloads appear to be handled correctly. In pic code,
reload doesn't know
how to handle a REG+D address where the REG contains the address of a
symbol_ref:
(insn 10 11 12 2 (set (reg/f:SI 146)
(mem/u/c:SI (lo_sum:SI (reg:SI 113)
(unspec:SI [
(symbol_ref:SI ("indirect_child") )
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 113)
(expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child") )
(nil
In theory, it seems to me reload could try reloading D to a register. The
offsets are limited to 14 bits
and the ldo instruction can handle that directly.
[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428 --- Comment #5 from dave.anglin at bell dot net --- On 2024-03-06 5:06 a.m., rearnsha at gcc dot gnu.org wrote: > I'm guessing it's this that's causing the problem because int and int* are the > same size on 32-bit targets. So would changing the test to: > > - int arr[20]; > + char arr[20]; > > be enough? AFAIK we don't have any targets with 8-bit pointers. Test passes with the attached change on hppa-unknown-linux-gnu.
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 --- Comment #15 from dave.anglin at bell dot net --- On 2024-03-01 5:42 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 > > Jonathan Wakely changed: > > What|Removed |Added > >Attachment #57540|0 |1 > is obsolete|| > > --- Comment #14 from Jonathan Wakely --- > Created attachment 57591 >--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57591=edit > Do not define lock-free atomic aliases if not fully lock-free > > Here's all of that as a single (slightly cleaned up) patch. > With this change, lock_free_aliases.cc fails test for excess errors: Excess errors: /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:7: error: #error "Feature test macro for lock-free type aliases is missing in " /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:19: error: 'atomic_signed_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:19: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:20: error: 'atomic_unsigned_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:20: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:25: error: 'atomic_signed_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:25: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:26: error: 'atomic_unsigned_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:26: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:29: error: 'atomic_signed_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:29: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:30: error: 'atomic_unsigned_lock_free' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:30: error: template argument 1 is invalid /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:33: error: 'std::atomic_signed_lock_free' has not been declared /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:34: error: 'std::atomic_unsigned_lock_free' has not been declared This is with my posted cmath patch.
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #11 from dave.anglin at bell dot net ---
On 2024-02-29 12:44 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
>
> --- Comment #10 from Jonathan Wakely ---
> This additional change should fix that:
>
> --- a/libstdc++-v3/src/c++20/tzdb.cc
> +++ b/libstdc++-v3/src/c++20/tzdb.cc
> @@ -643,6 +643,7 @@ namespace std::chrono
> void unlock() { infos_mutex.unlock(); }
> };
>
> +#if __cpp_lib_atomic_lock_free_type_aliases
> #if defined __GTHREADS && __cpp_lib_atomic_wait
> // Atomic count of unexpanded ZoneInfo objects in the infos vector.
> // Concurrent access is allowed when all objects have been expanded.
> @@ -704,6 +705,7 @@ namespace std::chrono
> #endif // __GTHREADS && __cpp_lib_atomic_wait
>
> RulesCounter rules_counter;
> +#endif // __cpp_lib_atomic_lock_free_type_aliases
> #else // TZDB_DISABLED
> _Impl(weak_ptr) { }
> struct {
Now we get:
libtool: compile: /home/dave/gnu/gcc/objdir64/./gcc/xgcc -shared-libgcc
-B/home/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/sys-include -fno-checking
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/../libgcc
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++20
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=tzdb.lo -fimplicit-templates -O2 -g -I. -c
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc -DPIC
-D_GLIBCXX_SHARED -o tzdb.o
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function
'std::chrono::sys_info
std::chrono::time_zone::_M_get_sys_info(std::chrono::sys_seconds) const':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:781:30: error: 'struct
std::chrono::time_zone::_Impl' has no member named 'rules_counter'; did
you mean 'RulesCounter'?
781 | lock_guard lock(_M_impl->rules_counter);
| ^
| RulesCounter
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:971:18: error: 'struct
std::chrono::time_zone::_Impl' has no member named 'rules_counter'; did
you mean 'RulesCounter'?
971 | _M_impl->rules_counter.decrement();
| ^
| RulesCounter
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'const
std::chrono::tzdb& std::chrono::reload_tzdb()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:1490:24: error: 'struct
std::chrono::time_zone::_Impl' has no member named 'rules_counter';
did you mean 'RulesCounter'?
1490 | impl.rules_counter.increment();
| ^
| RulesCounter
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #9 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Caused build error:
libtool: compile: /home/dave/gnu/gcc/objdir64/./gcc/xgcc -shared-libgcc
-B/home
/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-hp
-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/li
bstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++
-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/bin/
-B/opt/gnu6
4/gcc/gcc-14/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp-h
pux11.11/include -isystem /opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/sys-include
-fno-checking -I/home/dave/gnu/gcc/gcc/libstdc++-v3/../libgcc
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++20
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=tzdb.lo -fimplicit-templates -O2 -g -I. -c
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc -DPIC
-D_GLIBCXX_SHARED -o tzdb.o
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:654:9: error:
'atomic_signed_lock_free' does not name a type
654 | atomic_signed_lock_free counter{0};
| ^~~
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:706:18: error:
'atomic_signed_lock_free' was not declared in this scope; did you mean
'atomic_is_lock_free'?
706 | RulesCounter rules_counter;
| ^~~
| atomic_is_lock_free
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:706:41: error: template
argument 1 is invalid
706 | RulesCounter rules_counter;
| ^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::increment()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:658:11: error: 'counter' was
not declared in this scope; did you mean 'count'?
658 | { counter.fetch_add(1, memory_order::relaxed); }
| ^~~
| count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::decrement()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:668:17: error: 'counter' was
not declared in this scope; did you mean 'count'?
668 | if (++counter == 0)
| ^~~
| count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::lock()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:679:25: error: 'counter' was
not declared in this scope; did you mean 'count'?
679 | for (auto c = counter.load(memory_order::relaxed); c != 0;)
| ^~~
| count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::unlock()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:697:24: error: 'counter' was
not declared in this scope; did you mean 'count'?
697 | if (auto c = counter.load(memory_order::relaxed); c < 0)
| ^~~
| count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function
'std::chrono::sys_info
std::chrono::time_zone::_M_get_sys_info(std::chrono::sys_seconds) const':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:969:32: error: request for
member 'decrement' in '((const
std::chrono::time_zone*)this)->std::chrono::time_zone::_M_impl.std::unique_ptr::operator->()->std::chrono::time_zone::_Impl::rules_counter',
which is of non-class type 'int'
969 | _M_impl->rules_counter.decrement();
| ^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'const
std::chrono::tzdb& std::chrono::reload_tzdb()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:1488:38: error: request for
member 'increment' in
'impl.std::chrono::time_zone::_Impl::rules_counter', which is of non-class type
'int'
1488 | impl.rules_counter.increment();
| ^
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/atomic_wait.h:51,
from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/atomic_base.h:42,
from
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 --- Comment #8 from dave.anglin at bell dot net --- On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote: > Patch posted: > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html Will test on hppa64-hp-hpux11.11 on my next build.
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 --- Comment #6 from dave.anglin at bell dot net --- On 2024-02-26 7:22 a.m., redi at gcc dot gnu.org wrote: > OK then I think we don't want these aliases to be defined at all (which means > we cannot be fully C++20 conformant) and the test should be xfailed or > skipped. That's what I was thinking.
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 --- Comment #4 from dave.anglin at bell dot net --- On 2024-02-26 5:54 a.m., redi at gcc dot gnu.org wrote: > I assume the problem is that the ATOMIC_xxx_LOCK_FREE macros have value 1 not > 2, so they're not unconditionally lock-free. > > Are any of the atomic integer types always lock-free for this target? No. The only "lock free" operations are load and clear word/double word. On linux, we fudge the support in the kernel where we can disable interrupts but the operation still can spin.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #7 from dave.anglin at bell dot net --- On 2024-02-25 4:04 p.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > --- Comment #6 from dave.anglin at bell dot net --- > The for HP-UX doesn't do this sort of thing: >> extern double acos(double __x) __ATTR_CONST__; >> #define acosf acos /**< The alias for acos(). */ >> >> Technically, avr doesn't have a proper acosf. If float and double differ, >> acos >> won't handle exceptional >> values correctly for acosf. So, I think the AC_DEFINEs for the float >> variants >> should be removed or >> conditioned on some libc version. > With my proposed patch, the avr defines for the float variants in > crossconfig.m4 can be removed > and the code will fallback to using the float stubs. But I need to move the undefs for the C99 math funcs forward before the declarations.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #6 from dave.anglin at bell dot net --- The for HP-UX doesn't do this sort of thing: > extern double acos(double __x) __ATTR_CONST__; > #define acosf acos /**< The alias for acos(). */ > > Technically, avr doesn't have a proper acosf. If float and double differ, > acos > won't handle exceptional > values correctly for acosf. So, I think the AC_DEFINEs for the float variants > should be removed or > conditioned on some libc version. With my proposed patch, the avr defines for the float variants in crossconfig.m4 can be removed and the code will fallback to using the float stubs.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #4 from dave.anglin at bell dot net --- On 2024-02-25 2:21 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > Jonathan Wakely changed: > > What|Removed |Added > > See Also||https://gcc.gnu.org/bugzill > ||a/show_bug.cgi?id=111639 I haven't tested my hpux changes to crossconfig.m4. I just added new defines for some float math functions that were missing from the list and slightly reorganized the list into something slightly closer to alphabetical order. The for HP-UX doesn't do this sort of thing: extern double acos(double __x) __ATTR_CONST__; #define acosf acos /**< The alias for acos(). */ Technically, avr doesn't have a proper acosf. If float and double differ, acos won't handle exceptional values correctly for acosf. So, I think the AC_DEFINEs for the float variants should be removed or conditioned on some libc version. In my package, configure checks were added so that we now check all the C99 float variants. As a result, we now use the libc version instead of the stub version for some functions.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #3 from dave.anglin at bell dot net --- On 2024-02-25 2:21 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > Jonathan Wakely changed: > > What|Removed |Added > > See Also||https://gcc.gnu.org/bugzill > ||a/show_bug.cgi?id=86553 If a target has inconsistent declarations for any standard C99 functions, they should be fixed using a fixincludes hack. Originally, I wrote a patch to add declarations for missing C99 functions on hpux to math.h. They were declared when __cplusplus was defined. But then I realized they would be better in cmath as then all targets could potentially benefit. They could be guarded by something like _GLIBCXX_NEED_C99_DECLARATIONS. It could go in os_defines.h. On hpux11, the configure checks are sufficient. I think they are also sufficient on linux (test in progress).
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #2 from dave.anglin at bell dot net --- On 2024-02-25 2:17 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > Jonathan Wakely changed: > > What|Removed |Added > > See Also||https://gcc.gnu.org/bugzill > ||a/show_bug.cgi?id=79700 The patch I posted allows HP-UX targets to make use of the above change. I defined _GLIBCXX_USE_C99_MATH_FUNCS and _GLIBCXX_USE_BUILTIN_FMAF in config/os/hpux/os_defines.h: +// Import C99 functions in in in namespace std in C++11. +// Missing functions are handled by stubs. The fma, nexttoward, scalbln +// and tgamma are missing in HP-UX 11. Many float variants are supported. +#define _GLIBCXX_USE_C99_MATH_FUNCS 1 +#define _GLIBCXX_USE_C99_MATH_TR1 1 Had to add double stubs for fma, nexttoward, scalbln and tgamma to complete the set of required functions. Currently, _GLIBCXX_USE_C99_MATH_FUNCS and _GLIBCXX_USE_C99_MATH_TR1 are only enabled when configure detects the full set of C99 functions.
[Bug rtl-optimization/114062] "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove, at alloc-pool.h:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062 --- Comment #3 from dave.anglin at bell dot net --- On 2024-02-23 4:09 a.m., doko at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062 > > --- Comment #2 from Matthias Klose --- > this is seen when building with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 > and applying the proposed patch from PR114065. I built gcc-13 12.2.0 package successfully outside buildd on mx3210. c8000a buildd failed for the third time building gcc-14: In file included from ../../src/gcc/hash-table.h:248, from ../../src/gcc/coretypes.h:498, from ../../src/gcc/analyzer/call-details.cc:24: ../../src/gcc/vec.h:2314:51: internal compiler error: in pop, at vec.h:1056 2314 | vec::contains (const T ) const | ^ /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ianalyzer -I../../src/gcc -I../../src/gcc/analyzer -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o analyzer/call-string.o -MT analyzer/call-string.o -MMD -MP -MF analyzer/.deps/call-string.TPo ../../src/gcc/analyzer/call-string.cc 0xd2415f cp_lexer_rollback_tokens ../../src/gcc/cp/parser.cc:1438 0xda56cf cp_parser_parse_definitely ../../src/gcc/cp/parser.cc:35798 0xd73367 cp_parser_direct_declarator ../../src/gcc/cp/parser.cc:23928 0xd72fc3 cp_parser_declarator ../../src/gcc/cp/parser.cc:23773 0xd7116f cp_parser_init_declarator ../../src/gcc/cp/parser.cc:23257 0xd9b2b7 cp_parser_single_declaration ../../src/gcc/cp/parser.cc:33240 0xd98937 cp_parser_template_declaration_after_parameters ../../src/gcc/cp/parser.cc:32793 0xd9a93f cp_parser_explicit_template_declaration ../../src/gcc/cp/parser.cc:33066 0xd9aa1f cp_parser_template_declaration_after_export ../../src/gcc/cp/parser.cc:33085 0xd5d9fb cp_parser_template_declaration ../../src/gcc/cp/parser.cc:18171 0xd546af cp_parser_declaration ../../src/gcc/cp/parser.cc:15502 0xd54cd3 cp_parser_toplevel_declaration ../../src/gcc/cp/parser.cc:15594 0xd2e99b cp_parser_translation_unit ../../src/gcc/cp/parser.cc:5279 0xe09b87 c_parse_file() ../../src/gcc/cp/parser.cc:51202 0x1200863 c_common_parse_file() ../../src/gcc/c-family/c-opts.cc:1311 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ianalyzer -I../../src/gcc -I../../src/gcc/analyzer -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o analyzer/call-summary.o -MT analyzer/call-summary.o -MMD -MP -MF analyzer/.deps/call-summary.TPo ../../src/gcc/analyzer/call-summary.cc /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #1 from dave.anglin at bell dot net --- On 2024-02-15 2:01 p.m., sjames at gcc dot gnu.org wrote: > People are getting eager to require LRA. Please port the PA target to LRA (see > PR113932). Having tried this once, I know it's non trivial on PA.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 --- Comment #2 from dave.anglin at bell dot net --- On 2024-02-07 2:43 a.m., redi at gcc dot gnu.org wrote: > Using #include definitely won't work, that would just create a cycle between > the libstdc++ versions of stdlib.h and cstdlib, at least for all targets that > don't have stdlib.h in include-fixed. Are you sure? The file punct.cc compiles successfully on hppa-unknown-linux-gnu using #include. It doesn't have stdlib.h in include-fixed. Doing a full build.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #20 from dave.anglin at bell dot net --- On 2024-01-11 2:05 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 > > --- Comment #19 from Jakub Jelinek --- > I think stringpool hash table is never purged (unless libgccjit and > reinitializes stuff), so once something is looked up, it will be findable > later > on as well. Okay, then maybe get_identifier is the correct function to use.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #18 from dave.anglin at bell dot net --- On 2024-01-11 1:25 p.m., jakub at gcc dot gnu.org wrote: > The allocation is completely intentional, exactly to be able to track whether > it was referenced or not. Otherwise the exercise makes no sense. In assemble_external_libcall, it's intentional. But in process_pending_assemble_externals, all the allocations that are going to happen should have already happened. It is called in final. When the name encoding wasn't stripped, get_identifier just created a new identifier node that wasn't referenced. I tend to think there's a problem if the identifier node doesn't already exist in process_pending_assemble_externals.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #16 from dave.anglin at bell dot net --- On 2024-01-11 12:37 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 > > --- Comment #14 from Jakub Jelinek --- > (In reply to John David Anglin from comment #13) >> Although the patch fixes the udlit-namespace.C test, I think the patch >> still isn't correct. I think the code should use maybe_get_identifier >> instead of get_identifier. See assemble_name_resolve. > Why do you think so? When assemble_external_libcall is called, it calls > get_identifier to make sure such an identifier exists. get_identifier allocates a new identifier node if one doesn't exist. While it may not matter much at this point, I don't think this code should be allocating new identifier nodes. assemble_name_resolve avoids creating new nodes. > > Though, if the targetm.strip_name_encoding call is needed, it should be done > not just in process_pending_assemble_externals, but also in > assemble_external_libcall. Will look at.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #11 from dave.anglin at bell dot net --- On 2024-01-09 3:03 p.m., dave.anglin at bell dot net wrote: > The new code in process_pending_assemble_externals() doesn't strip the name > encoding > from XSTR (symbol, 0). Maybe that's the problem. Stripping the name encoding fixes the problem.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #10 from dave.anglin at bell dot net --- On 2024-01-09 2:56 p.m., dave.anglin at bell dot net wrote: > I have to think issue is with get_identifier(). Will have to do another build > to debug further. The new code in process_pending_assemble_externals() doesn't strip the name encoding from XSTR (symbol, 0). Maybe that's the problem.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #9 from dave.anglin at bell dot net --- On 2024-01-09 1:00 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 > > --- Comment #8 from Jakub Jelinek --- > Note, normally TREE_SYMBOL_REFERENCED should be set through something like > output_addr_const (or whatever else) -> assemble_name -> assemble_name_resolve > -> mark_referenced. Why doesn't trigger that on PA? Or does it trigger, but > the assembler requires the externs to be before the calls? As far as I can tell, mark_referenced() is called for the symbols in question. I don't believe the assembler requires the externs (.type statments) to be before the calls. I have to think issue is with get_identifier(). Will have to do another build to debug further.
[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
--- Comment #5 from dave.anglin at bell dot net ---
On 2024-01-08 3:49 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
>
> --- Comment #4 from Jakub Jelinek ---
> What about:
> --- libgomp/configure.ac.jj 2023-11-02 07:49:21.693801244 +0100
> +++ libgomp/configure.ac2024-01-08 21:46:21.014765685 +0100
> @@ -343,7 +343,7 @@ AX_COUNT_CPUS
> AC_CHECK_PROGS(FLOCK, flock)
> # Fallback if 'perl' is available.
> if test -z "$FLOCK"; then
> - AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
> + AC_CHECK_PROG(FLOCK, perl, \$(abs_top_srcdir)/testsuite/flock)
> fi
>
> AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
> --- libgomp/configure.jj2024-01-06 02:29:24.566795886 +0100
> +++ libgomp/configure 2024-01-08 21:46:23.799726387 +0100
> @@ -16655,7 +16655,7 @@ do
> test -z "$as_dir" && as_dir=.
> for ac_exec_ext in '' $ac_executable_extensions; do
> if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> -ac_cv_prog_FLOCK="$srcdir/testsuite/flock"
> +ac_cv_prog_FLOCK="\$(abs_top_srcdir)/testsuite/flock"
> $as_echo "$as_me:${as_lineno-$LINENO}: found
> $as_dir/$ac_word$ac_exec_ext"
>> &5
> break 2
> fi
>
Works.
Thanks,
Dave
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #7 from dave.anglin at bell dot net ---
On 2024-01-08 9:29 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> Jakub Jelinek changed:
>
> What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #6 from Jakub Jelinek ---
> (In reply to John David Anglin from comment #5)
>> The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs. This fixes
>> problem on hppa64-hpux:
>>
>> bash-5.1$ git diff gcc/varasm.cc
>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
>> index 69f8f8ee018..0a1cc022023 100644
>> --- a/gcc/varasm.cc
>> +++ b/gcc/varasm.cc
>> @@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
>> for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
>> {
>> rtx symbol = XEXP (list, 0);
>> - tree id = get_identifier (XSTR (symbol, 0));
>> - if (TREE_SYMBOL_REFERENCED (id))
>> - targetm.asm_out.external_libcall (symbol);
>> + targetm.asm_out.external_libcall (symbol);
>> }
>>
>> pending_assemble_externals = 0;
>>
>> If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
>> check into the bpf target.
> Then the bug is that it isn't set when they are actually referenced.
Exactly. This has been a problem for a long time. There is a work around in
the define
for ASM_OUTPUT_EXTERNAL_LIBCALL in pa/som.h. Issue is also mentioned in
sol2.cc.
[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192 --- Comment #2 from dave.anglin at bell dot net --- On 2024-01-02 10:21 a.m., tschwinge at gcc dot gnu.org wrote: > Aha, sorry. Does it work if you changes: > > -AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock) > +AC_CHECK_PROG(FLOCK, perl, $ac_abs_srcdir/testsuite/flock) No, we get: ERROR: couldn't execute "/testsuite/flock": no such file or directory I see top_srcdir is used in some files.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #2 from dave.anglin at bell dot net --- On 2023-12-30 1:30 p.m., pinskia at gcc dot gnu.org wrote: > I figured it would be PA RISC which would have issues with this too. It's only an issue on hpux.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #47 from dave.anglin at bell dot net ---
On 2023-11-13 4:33 a.m., manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #44 from Manolis Tsamis ---
> (In reply to John David Anglin from comment #39)
>> In the f-m-o pass, the following three insns that set call clobbered
>> registers r20-r22 are pulled from loop:
>>
>> (insn 186 183 190 29 (set (reg/f:SI 22 %r22 [478])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 388 [0x184]))) "../Python/compile.c":5964:9 120
>> {addsi3}
>> (nil))
>> (insn 190 186 187 29 (set (reg/f:SI 21 %r21 [479])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 392 [0x188]))) "../Python/compile.c":5964:9 120
>> {addsi3}
>> (nil))
>> (insn 194 191 195 29 (set (reg/f:SI 20 %r20 [480])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 396 [0x18c]))) "../Python/compile.c":5964:9 120
>> {addsi3}
>> (nil))
>>
>> They are used in the following insns before call to compiler_visit_expr1:
>>
>> (insn 242 238 258 32 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int
>> *)prephit
>> mp_37 + 388B]+0 S4 A32])
>> (reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173]))
>> "../Python/compile.c"
>> :5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173])
>> (expr_list:REG_DEAD (reg/f:SI 22 %r22 [478])
>> (nil
>> (insn 258 242 246 32 (set (reg:SI 26 %r26)
>> (reg/v/f:SI 5 %r5 [orig:198 c ] [198]))
>> "../Python/compile.c":5969:15 42 {*pa.md:2193}
>> (nil))
>> (insn 246 258 250 32 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int
>> *)prephitmp_37 + 392B]+0 S4 A32])
>> (reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169]))
>> "../Python/compile.c":5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169])
>> (expr_list:REG_DEAD (reg/f:SI 21 %r21 [479])
>> (nil
>> (insn 250 246 254 32 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int
>> *)prephitmp_37 + 396B]+0 S4 A32])
>> (reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145]))
>> "../Python/compile.c":5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145])
>> (expr_list:REG_DEAD (reg/f:SI 20 %r20 [480])
>> (nil
>>
>> After the call, we have:
>>
>> (insn 1241 269 273 30 (set (reg/f:SI 22 %r22 [478])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 273 1241 1242 30 (set (mem:SI (plus:SI (reg/f:SI 22 %r22 [478])
>> (const_int 388 [0x184])) [4 MEM[(int *)_107 + 388B]+0 S4
>> A32])
>> (reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 1242 273 277 30 (set (reg/f:SI 21 %r21 [479])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 277 1242 1243 30 (set (mem:SI (plus:SI (reg/f:SI 21 %r21 [479])
>> (const_int 392 [0x188])) [4 MEM[(int *)_107 + 392B]+0 S4
>> A32])
>> (reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 1243 277 281 30 (set (reg/f:SI 20 %r20 [480])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 281 1243 299 30 (set (mem:SI (plus:SI (reg/f:SI 20 %r20 [480])
>> (const_int 396 [0x18c])) [4 MEM[(int *)_107 + 396B]+0 S4
>> A32])
>> (reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>>
>> We have lost the offsets that were added initially to r20, r21 and r22.
>>
>> Previous ce3 pass had:
>>
>> (insn 272 269 273 30 (set (reg/f:SI 22 %r22 [478])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 388 [0x184]))) "../Python/compile.c":5970:20 120
>> {addsi3}
>> (nil))
>> (insn 273 272 276 30 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int
>> *)_107 + 388B]+0 S4 A32])
>> (reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 276 273 277 30 (set (reg/f:SI 21 %r21 [479])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 392 [0x188]))) "../Python/compile.c":5970:20 120
>> {addsi3}
>> (nil))
>> (insn 277 276 280 30 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int
>> *)_107 + 392B]+0 S4 A32])
>> (reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>>
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #32 from dave.anglin at bell dot net --- At this point, I don't have gcc-14 builds that bracket the f-m-o change. Maybe Sam can check. I'm trying to determine RTL pass where things go bad.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #28 from dave.anglin at bell dot net --- On 2023-11-08 7:07 p.m., law at gcc dot gnu.org wrote: > Do we already have a dump for the key function? Presumably f-m-o doesn't > trigger*that* much. And if this is triggering w/o LTO we can probably move > to > cross debugging and analysis of those dump files and assembly code with and > without f-m-o enabled, narrowing our focus on the key function. I tried looking at the difference with and without f-m-o and it was quite large. The difference with and without strict aliasing is much smaller. The main differences that I saw relate to the inlining of compiler_visit_expr and compiler_visit_expr1.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #27 from dave.anglin at bell dot net --- On 2023-11-08 7:00 p.m., John David Anglin wrote: > On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 >> >> --- Comment #23 from Sam James --- >> (In reply to Andrew Pinski from comment #21) >>> The other option to try is -fstack-reuse=none. There is definitely known >>> issues with the code that coalesces stack variables together too (see PR >>> 111843 for examples). >> I had a good feeling about this but no, didn't help when applied to >> compile.o. > At this point, I don't know whether this is a python or gcc bug. I scanned > for unions in compile.i > that might be problematic but I didn't find anything obvious. Note -no-strict-aliasing affects the inlining of compiler_visit_expr. It is not inlined with -no-strict-aliasing.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #24 from dave.anglin at bell dot net --- On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 > > --- Comment #23 from Sam James --- > (In reply to Andrew Pinski from comment #21) >> The other option to try is -fstack-reuse=none. There is definitely known >> issues with the code that coalesces stack variables together too (see PR >> 111843 for examples). > I had a good feeling about this but no, didn't help when applied to compile.o. At this point, I don't know whether this is a python or gcc bug. I scanned for unions in compile.i that might be problematic but I didn't find anything obvious.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #20 from dave.anglin at bell dot net --- On 2023-11-08 2:07 p.m., pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 > > --- Comment #18 from Andrew Pinski --- > I wonder if -fno-strict-aliasing works around the issue too? > I get the feeling that `fold mem offset pass` allows the aliasing code to have > a better time with the offset and that might be expose more aliasing issues. > > The other thing to try is add `-fno-schedule-insns2 -fno-schedule-insns` > instead of `-fno-strict-aliasing` as the scheduler is normally where the > aliasing issues are exposed on the RTL level ... Both -fno-strict-aliasing and -fno-schedule-insns2 applied to compiler_visit_expr() work around issue.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #17 from dave.anglin at bell dot net ---
On 2023-11-08 9:42 a.m., jeffreyalaw at gmail dot com wrote:
> I'd probably continue with the process of narrowing down what code is
> affected using the attributes. We already know the file, narrowing it
> down to a function might help considerably with the evaluation effort.
The problem seems to be in compiler_visit_expr().
-static int compiler_visit_expr(struct compiler *, expr_ty);
+static int compiler_visit_expr(struct compiler *, expr_ty)
__attribute__((optimize("no-inline-small-functions")));
Python builds okay if this function is not inlined, if it is compiled at -O1,
or if -fno-inline-small-functions is
specified as above. Can't specify -fno-fold-mem-offsets as a function
attribute.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #14 from dave.anglin at bell dot net --- On 2023-11-07 8:36 p.m., sjames at gcc dot gnu.org wrote: > If I instrument certain functions in compile.c with no optimisation attribuet > or build the file with -fno-fold-mem-offsets, Python works, so I'm reasonably > sure this is the relevant object. I believe this bug is related to https://gcc.gnu.org/PR97431 I see the same fault with using debian/rules and -finline-small-functions option. Debian has been building with -fno-inline-small-functions on sh and hppa. This hides problem.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #10 from dave.anglin at bell dot net --- On 2023-11-06 5:49 p.m., sjames at gcc dot gnu.org wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x412083f0 in _PyST_GetSymbol (name=0xf9a34a00, ste=) at > Python/symtable.c:396 > 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); > (gdb) x/20i $pc > => 0x412083f0 <_PyST_GetScope+20>: ldw c(r26),r26 r26=0x34, so the ldw will fault. It appears r26 and r25 have been exchanged in the code prior to <_PyST_GetScope+20>. In any case, the problem is with the ste argument passed to _PyST_GetSymbol.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #7 from dave.anglin at bell dot net --- On 2023-11-06 5:20 p.m., law at gcc dot gnu.org wrote: > The biggest concern I'd have with f-m-o on the PA would be the > implicit segment selection that happens on the base register -- but it would > only be an issue if we are faulting on an unscaled indexed addressing mode and > only if the linux-gnu port was actually putting different values into the > space > registers. The linux-gnu port does not put different values into the space resisters.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #3 from dave.anglin at bell dot net --- On 2023-11-06 4:00 p.m., sjames at gcc dot gnu.org wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); > (gdb) bt > #0 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > #1 _PyST_GetScope (ste=, name=0xf9a33a60) at > Python/symtable.c:406 Probably, ste is NULL or in page 0, and it's symtable.c that's miscompiled. There's not a lot of testing of gcc-14 on hppa yet.
[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 --- Comment #10 from dave.anglin at bell dot net --- On 2023-10-06 3:50 a.m., rguenth at gcc dot gnu.org wrote: > Does it work on trunk? No. Test results with gcc trunk are identical to with Debian gcc-13. Tried just rebuilding s_fma.c, and a full build and check.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #20 from dave.anglin at bell dot net --- On 2023-07-19 6:10 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 > > --- Comment #17 from Jonathan Wakely --- > (In reply to Jonathan Wakely from comment #16) >> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for >> excess errors) >> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution >> test > Oops, sorry, not that one! As mentioned, that will be UNSUPPORTED for > hpux11.11 Yes, stoll and stoull tests are UNSUPPORTED. We also have: UNSUPPORTED: 21_strings/basic_string/numeric_conversions/char/stold.cc The rest of the non wide character conversion tests pass. The stoll and stoull tests pass when dg-require-string-conversions is 1. The stold test fails, I think because it returns LDBL_MAX instead of HUGE_VALL (inf). See _GLIBCXX_HAVE_BROKEN_STRTOLD comment in /config/os/hpux/os_defines.h. There is a problem with std::stof. It throws an out of range exception for 0. It needs to check for 0 value.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #18 from dave.anglin at bell dot net ---
On 2023-07-19 6:10 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #16 from Jonathan Wakely ---
> This should be fixed now, and you should see these in libstdc++.sum
>
> PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
>
> The char/stoll.cc and char/stoull.cc tests would actually pass for hpux11.11
> as
> well, but they have the { dg-require-string-conversions "" } check which
> fails.
Had the following fails with attached patch:
Running target unix
FAIL: 20_util/from_chars/4.cc execution test
FAIL: 20_util/from_chars/8.cc execution test
FAIL: 20_util/to_chars/float128_c++23.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc (test for
excess errors)
UNRESOLVED: 21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc
compilation failed to produce executable
FAIL: 26_numerics/headers/cmath/constexpr_std_c++23.cc (test for excess errors)
FAIL: 26_numerics/headers/cmath/functions_std_c++23.cc (test for excess errors)
FAIL: 26_numerics/headers/cmath/nextafter_c++23.cc (test for excess errors)
UNRESOLVED: 26_numerics/headers/cmath/nextafter_c++23.cc compilation failed to
produce executable
FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test
FAIL: 27_io/basic_ofstream/open/wchar_t/noreplace.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test
FAIL: 29_atomics/atomic/compare_exchange_padding.cc execution test
FAIL: 29_atomics/atomic/lock_free_aliases.cc (test for excess errors)
FAIL: 29_atomics/atomic_ref/compare_exchange_padding.cc execution test
=== libstdc++ Summary ===
# of expected passes 14134
# of unexpected failures 15
# of expected failures 106
# of unresolved testcases 2
# of unsupported tests 1014
The stof.cc and stold.cc tests fail in try-catch.
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_co
nversions/char/stof.cc:128: void test01(): Assertion 'test' failed.
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_co
nversions/char/stold.cc:95: void test01(): Assertion 'test' failed.
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
Will retest with your commit.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #11 from dave.anglin at bell dot net ---
On 2023-07-14 5:58 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #10 from Jonathan Wakely ---
> And this should fix it:
>
> --- a/libstdc++-v3/include/c_global/cstdlib
> +++ b/libstdc++-v3/include/c_global/cstdlib
> @@ -256,6 +256,20 @@ namespace std
> using ::__gnu_cxx::strtold;
> } // namespace std
>
> +#else // ! _GLIBCXX_USE_C99_STDLIB
> +
> +// We also check for strtof and strtold separately from
> _GLIBCXX_USE_C99_STDLIB
> +
> +#if _GLIBCXX_HAVE_STRTOF
> +#undef strtof
> +namespace std { using ::strtof; }
> +#endif
> +
> +#if _GLIBCXX_HAVE_STRTOLD
> +#undef strtold
> +namespace std { using ::strtold; }
> +#endif
> +
> #endif // _GLIBCXX_USE_C99_STDLIB
>
> } // extern "C++"
Yes, this works.
hppa64-hpux does not have have strtof. Could std::stof be implemented using
strtod in this case?
I'm thinking a test to check the presence and maybe compliance of these
routines might be good.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #8 from dave.anglin at bell dot net ---
On 2023-07-13 2:16 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #7 from dave.anglin at bell dot net ---
> On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote:
>> ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36:
>> error:
>> 'strtold' is not a member of 'std'; did you mean 'strtoll'?
> That's a problem with stdlib.h header.
I thought this was because we lack _NAMESPACE_STD_START and _NAMESPACE_STD_END
statements
around the strtold declaration in stdlib.h, but this didn't help. Maybe we lack
a define for _NAMESPACE_STD
/* ANSI C++ namespace std support */
#ifdef _NAMESPACE_STD
#define _NAMESPACE_STD_START namespace std {
#define _NAMESPACE_STD_END }
or maybe "using::strtold" additions are needed to various cstdlib files in gcc.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #7 from dave.anglin at bell dot net --- On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote: > ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error: > 'strtold' is not a member of 'std'; did you mean 'strtoll'? That's a problem with stdlib.h header.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #6 from dave.anglin at bell dot net ---
On 2023-07-13 1:09 p.m., redi at gcc dot gnu.org wrote:
> I'm testing this, which should define std::stof and std::stold for hpux11.11:
>
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> stod(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
>
> -#if _GLIBCXX_USE_C99_STDLIB
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
> // NB: strtof vs strtod.
> inline float
> stof(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
> +#endif
>
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx);
> }
> @@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return std::stod(__str, __idx); }
> -#endif // _GLIBCXX_USE_C99_STDLIB
> +#endif
We get this error with the above:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
In file included from ./hppa64-hp-hpux11.11/libstdc++-v3/include/string:54,
from xxx.cc:1:
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function
'long double std::__cxx11::stold(const std::string&, std::size_t*)':
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error:
'strtold' is not a member of 'std'; did you mean 'strtoll'?
4161 | { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(),
__idx); }
| ^~~
| strtoll
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #2 from Jonathan Wakely ---
> Created attachment 55534
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
> libstdc++: std::stoi etc. do not need C99 support
>
> Dave, does this patch work for hppa64-hp-hpux11.11 ?
Yes.
>
> It should allow you to compile + run the code below:
>
> #include
> int main()
> {
>std::string z = "0";
>return std::stoi(z) + std::stol(z) + std::stoul(z) + std::stoll(z)
> + std::stoull(z) + std::stod(z);
> }
The above code compiles and runs successfully on hppa64-hp-hpux11.11 with the
patch.
>
> I'm not sure if double and long double are the same representation on this
> target, but if they are then std::stold("0.0") should work too.
Adding std::stold("0.0") to test, we get:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
xxx.cc: In function 'int main()':
xxx.cc:6:48: error: 'stold' is not a member of 'std'
6 | + std::stoull(z) + std::stod(z) + std::stold("0.0");
| ^
xxx.cc:2:1: note: 'std::stold' is defined in header ''; this is
probably fixable by adding '#include '
1 | #include
+++ |+#include
2 | int main()
On hpux, double and long double have different representations (they are same
on linux). hpux11.11 has both
strtod and strtold. strtold is checked for:
/* Define to 1 if you have the `strtof' function. */
/* #undef HAVE_STRTOF */
/* Define to 1 if you have the `strtold' function. */
#define HAVE_STRTOLD 1
There doesn't seem to be a configure check for strtod.
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 --- Comment #1 from dave.anglin at bell dot net --- Note this occurs in stage1. Bug was introduced in commit 957ae90406591739b68e95ad49a0232faeb74217.
[Bug middle-end/109478] FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-04-12 7:31 a.m., rguenth at gcc dot gnu.org wrote:
> and the RTL for the argument is
>
> (parallel:BLK [])
>
> ick. pa_function_arg runs into
>
> 9786 arg_size = pa_function_arg_size (mode, type);
> 9800 if (arg_size > 1)
> (gdb) p arg_size
> $7 = 0
>
> so isn't able to decipher things down to a "valid" argument spec. Note
> above for the argument type we have TYPE_SIZE == 0 but a very
> large TYPE_SIZE_UNIT.
>
> One "obvious" mistake is to use 'int arg_size' for the HOST_WIDE_INT
> pa_function_arg_size return value. Adjusting also downstream variable
> types helps to some extent but then we ICE in
Yes, this is wrong. However, pa_function_arg only handles the distribution of
arguments to registers.
It's should return NULL_RTX for "large" arg_size values. Don't know why this
didn't show up before.
>
> during RTL pass: dwarf2
> t.ii: In function 'void c(...)':
> t.ii:4:23: internal compiler error: in dwarf2out_frame_debug_expr, at
> dwarf2cfi.cc:1960
> 4 | void c(...) { c(a()); }
>| ^
> 0x12bd9d2 dwarf2out_frame_debug_expr
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:1960
> 0x12bea15 dwarf2out_frame_debug
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:2367
> 0x12bf81b scan_insn_after
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:2726
> 0x12bfe3c scan_trace
>
> seeing
>
> (set (reg:DI 1 %r1)
> (plus:DI (reg/f:DI 30 %r30)
> (const_int 4611686018427379840 [0x3fffe080])))
Need to investigate where this stack adjustment comes from.
Even if we force the const_int to memory, this will never work with real
hardware. The maximum physical
address size is 44 bits.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #12 from dave.anglin at bell dot net --- On 2023-04-05 10:56 a.m., ebotcazou at gcc dot gnu.org wrote: > Nice work! Your comments were accurate and very helpful. Thanks, dave
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #7 from dave.anglin at bell dot net --- On 2023-04-03 4:46 p.m., ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 > > --- Comment #6 from Eric Botcazou --- >> As far as I can tell, this test has always failed on both 32-bit linux and >> hpux. > Does libgcc/config/pa/milli64.S contain CFI directives or EH tables? No.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #4 from dave.anglin at bell dot net --- On 2023-04-02 12:54 p.m., ebotcazou at gcc dot gnu.org wrote: >> I believe hppa-linux can unwind through signal frames. VDSO support was >> added fairly recently. > Does the unwinder compensate for the signal vs non-signal discrepancy? See > __gnat_adjust_context_for_raise in ada/init.c:470 for possible tweaks. I don't think it does with VDSO kernels. The unwinder uses MD_FALLBACK_FRAME_STATE_FOR with non VDSO kernels.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #2 from dave.anglin at bell dot net --- I believe hppa-linux can unwind through signal frames. VDSO support was added fairly recently. The unwind tests in glibc all pass. GDB needs an update to unwind through signal frames with recent kernels.
[Bug target/109376] FAIL: gnat.dg/prot7.adb (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109376 --- Comment #2 from dave.anglin at bell dot net --- I would judge the test should be skipped on hppa.
[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396 --- Comment #4 from dave.anglin at bell dot net --- I currently have 2.36.
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 --- Comment #2 from dave.anglin at bell dot net --- On 2023-01-18 4:07 p.m., pinskia at gcc dot gnu.org wrote: > Basically C[TL]Z_DEFINED_VALUE_AT_ZERO macro does not always use its arguments > so they don't get marked as used ... Yes. PA uses the default defines for these macros.
[Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #56 from dave.anglin at bell dot net --- On 2023-01-09 6:20 a.m., redi at gcc dot gnu.org wrote: > Maybe like this. Actually, the change i sent was for libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc. It still fails. No objection to the approach.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 --- Comment #7 from dave.anglin at bell dot net --- On 2023-01-06 12:44 p.m., ian at airs dot com wrote: > If LTO doesn't work HP/UX, do you have a simple test that the configure script > could run to see whether it works? Will investigate.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 --- Comment #2 from dave.anglin at bell dot net --- On 2023-01-05 2:23 p.m., ian at airs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 > > Ian Lance Taylor changed: > > What|Removed |Added > > CC||ian at airs dot com > > --- Comment #1 from Ian Lance Taylor --- > Does HP/UX 11.11 use ELF? The 64-bit target uses ELF. > If so, I guess we need a configure test to see > whether the linker supports the --build-id option. If it doesn't, I guess we > need to skip the debuginfo tests. Currently, HP ld is the only working linker and it doesn't support the --build-id option. GNU ld has problems with shared library support.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #8 from dave.anglin at bell dot net --- On 2023-01-04 7:54 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 > > --- Comment #7 from Jonathan Wakely --- > Does that fix it? I just started a new build and check.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #19 from dave.anglin at bell dot net ---
On 2022-11-28 4:39 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
>
> --- Comment #18 from Jakub Jelinek ---
> Or better yet
> #include
> #include
>
> int
> main ()
> {
>char *end;
>const char *p = "6e-4966";
>long double l = strtold (p, );
>if (l != __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>p = "1e-4965";
>l = strtold (p, );
>if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>p = "2e-4965";
>l = strtold (p, );
>if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>return 0;
> }
> so that we know if it is just the denorm_min() case or also other denormals.
I tried both test cases with a recent build of gcc-12. Neither failed at O0 or
O2. Nothing was printed.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #16 from dave.anglin at bell dot net --- This is what the test prints: 6.47518e-4966 6e-4966 xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 == ptr1' failed. ABORT instruction (core dumped)
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #14 from dave.anglin at bell dot net --- /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc :77: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 == ptr1 ' failed. FAIL: 20_util/to_chars/float128_c++23.cc execution test
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #15 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> hen I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline
>> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common
>> -fmath-errno-fno-pie -fopt-info-vec
> and nothing actually vectorized. Besides the PRE there seems to be a missed
> DSE at the end (when vectorization is enabled as after the change):
>
> # DEBUG BEGIN_STMT
> memset (__space.__c, 64, 1024);
> # DEBUG BEGIN_STMT
> + sizes[0] = 16;
> sizes[1] = 1024;
> sizes[2] = 1040;
>
> otherwise I see nothing suspicious in differences in .optimized when
> comparing -fdump-tree-optimized with/without -fno-tree-vectorize.
>
I'm not sure what's going on with the sizes[0] statement but the main
difference in .optimize with and without pre
seems to be in the handling of the old_length variable in do_test:
Removing basic block 86
int do_test ()
{
- unsigned int ivtmp.23;
- size_t old_length;
+ unsigned int ivtmp.28;
void * r;
void * c;
size_t l;
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #14 from dave.anglin at bell dot net --- On 2022-08-10 1:38 p.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 > > --- Comment #13 from dave.anglin at bell dot net --- > On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote: >> You could try if -fno-tree-pre reproduces it also before the change. > It doesn't. But the test does not fail after the change with -fno-tree-pre.
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #13 from dave.anglin at bell dot net --- On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote: > You could try if -fno-tree-pre reproduces it also before the change. It doesn't.
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #12 from dave.anglin at bell dot net --- On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote: > When I try with a cc1 cross I see > >> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline >> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common >> -fmath-errno-fno-pie -fopt-info-vec > and nothing actually vectorized. Besides the PRE there seems to be a missed > DSE at the end (when vectorization is enabled as after the change): > > # DEBUG BEGIN_STMT > memset (__space.__c, 64, 1024); > # DEBUG BEGIN_STMT > + sizes[0] = 16; > sizes[1] = 1024; > sizes[2] = 1040; > > otherwise I see nothing suspicious in differences in .optimized when > comparing -fdump-tree-optimized with/without -fno-tree-vectorize. I had tried -fno-tree-vectorize and it made no difference to the test. So, it seems GCC is miscompiled with the -ftree-vectorize change. I thought of building GCC with -fno-tree-vectorize as a test. > > You could try if -fno-tree-pre reproduces it also before the change. > Will try.
[Bug tree-optimization/106480] FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for warnings, line 33)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106480
--- Comment #2 from dave.anglin at bell dot net ---
On 2022-08-01 5:12 a.m., rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106480
>
> Richard Biener changed:
>
> What|Removed |Added
>
> Keywords||testsuite-fail
>
> --- Comment #1 from Richard Biener ---
> Both are guarded like
>
>p->a0[0] = 4; p->a0[1] = 5; // { dg-warning "\\\[-Wstringop-overflow"
> "pr102706" { target { vect_slp_v2hi_store_align && { !
> vect_slp_v4hi_store_unalign } } } }
>
> the vect_slp_* predicates according to comments implement exactly the case in
> the testsuite, but for some reason it doesn't work on hppa?
Yes, I guess this implies a problem with
# Return the true if target support vectorization of 4-byte short stores
# with 4-byte aligned address at plain O2.
proc check_effective_target_vect_slp_v2hi_store_align { } {
set pattern {add new stmt: MEM }
set macro "TEST_V2HI_2"
return [check_cached_effective_target vect_slp_v2hi_store_align {
expr [check_vect_slp_store_usage $pattern $macro ] }]
}
# Return the true if target support vectorization of 8-byte short stores
# with unaligned address at plain O2.
# NB: This target should be removed after real issues are fixed for
# -Wstringop-overflow with O2 vect. Be careful if you want to reuse
# this target since tests in check_vect_slp_store_usage
# is the exact match of relative testcases
proc check_effective_target_vect_slp_v4hi_store_unalign { } {
set pattern {add new stmt: MEM }
set macro "TEST_V4HI"
return [check_cached_effective_target vect_slp_v4hi_store_unalign {
expr [check_vect_slp_store_usage $pattern $macro ] }]
}
in target-supports.exp.
[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #6 from dave.anglin at bell dot net --- On 2022-07-29 8:50 a.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 > > --- Comment #5 from dave.anglin at bell dot net --- > On 2022-07-28 4:12 a.m., rguenth at gcc dot gnu.org wrote: >> Can you check trunk / the gcc 12 branch head? > Test fails in the same way with trunk. Aside from a couple of .stringz and .ident assembler statements, there is no difference in the assembly code generated by "GCC: (GNU) 13.0.0 20220728 (experimental) [master r13-1220-g7c1c7e120cc]" and "GCC: (Debian 12.1.0-7) 12.1.0".
[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #5 from dave.anglin at bell dot net --- On 2022-07-28 4:12 a.m., rguenth at gcc dot gnu.org wrote: > Can you check trunk / the gcc 12 branch head? Test fails in the same way with trunk.
[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363 --- Comment #11 from dave.anglin at bell dot net --- On 2022-02-22 4:15 a.m., mathieu.malaterre at gmail dot com wrote: > [...] > libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to > `kcapi_rng_generate' > /usr/lib/gcc-cross/hppa-linux-gnu/10/../../../../hppa-linux-gnu/bin/ld: > libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to > `kcapi_memset_secure' > [...] As I tried to say previously, the problem was with the asm used in libkcapi.
[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363 --- Comment #7 from dave.anglin at bell dot net --- On 2022-02-03 12:13 p.m., danglin at gcc dot gnu.org wrote: > If I was to guess, I suspect the problem is with asm. Maybe a '\t' > is needed before .symver on hppa. The hppa assembler wants white space > before directives. That is fixed in this commit: https://github.com/smuellerDD/libkcapi/commit/3e9a1494dd2401094675fb54b1013022bd7933b8
[Bug libstdc++/103890] Generated baseline symbol file seems to have redundant lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890 --- Comment #2 from dave.anglin at bell dot net --- Is that what we want?
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #12 from dave.anglin at bell dot net --- On 2021-12-29 12:26 p.m., fxcoudert at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 > > --- Comment #10 from Francois-Xavier Coudert > --- > Created attachment 52086 >--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52086=edit > adjust testcase > > David, could you kindly test the attached patch, to see if it fixes things? Tests pass with patch on hppa-unknown-linux-gnu.
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #11 from dave.anglin at bell dot net --- On 2021-12-29 12:26 p.m., fxcoudert at gcc dot gnu.org wrote: > David, could you kindly test the attached patch, to see if it fixes things? Added patch to my build tree.
[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121 --- Comment #2 from dave.anglin at bell dot net --- On 2021-11-08 4:24 a.m., rguenth at gcc dot gnu.org wrote: > David, can you try adding > -fno-tree-vectorize to the command line to see if that silences the > diagnostic? It does not silence the diagnostic.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #3 from dave.anglin at bell dot net --- This occurs in stage3, so it's probably an optimization bug.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #2 from dave.anglin at bell dot net --- On 2021-09-22 9:14 a.m., rguenth at gcc dot gnu.org wrote: > what's MAX_BITSIZE_MODE_ANY_INT in insn-modes.h? (in the build directory) > I think it should correspond to TImode and thus be 16 * BITS_PER_UNIT which > means that we're building an INTEGER_TYPE bigger than TImode - can you confirm > that? #define BITS_PER_UNIT (8) #define MAX_BITSIZE_MODE_ANY_INT (16*BITS_PER_UNIT) #define MAX_BITSIZE_MODE_ANY_MODE (32*BITS_PER_UNIT) However, TImode is not supported on this target. (gdb) ignor 1 325 Will ignore next 325 crossings of breakpoint 1. (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/gnat1 -quiet -nostdinc -O2 -Wext ra -Wall -dumpbase s-regpat.adb -dumpbase-ext .adb -gnatwa -fchecking=1 -g -fPIC -gnatpg -gnatO s-regpat.o s-regpat.adb -o s-regpat.s Breakpoint 1, _Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop (type=, precision=256, sgn=UNSIGNED) at ../../gcc/gcc/stor-layout.c:2851 2851 gcc_assert (precision <= WIDE_INT_MAX_PRECISION); (gdb) p precision $2 = 256 (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0xfbc244 to 0xfbc264: 0x00fbc244 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+36>: stw r7,-70(sp) 0x00fbc248 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+40>: stw r6,-6c(sp) 0x00fbc24c <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+44>: cmpib,>= 0,r25,0xfbc2d4 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+180> 0x00fbc250 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+48>: copy r26,r3 => 0x00fbc254 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+52>: ldi c0,ret0 0x00fbc258 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+56>: cmpb,< ret0,r25,0xfbc2fc <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+220> 0x00fbc25c <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+60>: copy r24,r25 0x00fbc260 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+64>: ldo -98(sp),r6 End of assembler dump. (gdb) p $ret0 $3 = 8388608 (gdb) p 0xc0 $4 = 192 (gdb) p $r25 $5 = 256 (gdb) bt #0 _Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop ( type=, precision=256, sgn=UNSIGNED) at ../../gcc/gcc/stor-layout.c:2851 #1 0x00fc0b9c in _Z18make_unsigned_typei (precision=256) at ../../gcc/gcc/stor-layout.c:2885 #2 0x000da2b4 in _Z18gnat_type_for_sizeji (precision=256, unsignedp=256) at ../../gcc/gcc/ada/gcc-interface/utils.c:3670 #3 0x00b05c2c in gimple_fold_builtin_memory_op(gimple_stmt_iterator*, tree_node*, tree_node*, built_in_function) (v=@0x79aebb68, reserve=256, exact=true) at ../../gcc/gcc/gimple-fold.c:1004 #4 0x00afffac in _ZL11fold_stmt_1P20gimple_stmt_iteratorbPFP9tree_nodeS2_E ( gsi=0x7a001018, inplace=true, valueize=0x79ae8b58) at ../../gcc/gcc/gimple-fold.c:5054 #5 0x00b13668 in _ZL10lower_stmtP20gimple_stmt_iteratorP10lower_data ( gsi=..., data=0x7a000fa4) at ../../gcc/gcc/gimple-low.c:390 #6 0x00b1405c in _ZL17lower_gimple_bindP20gimple_stmt_iteratorP10lower_data ( gsi=0x7a000f98, data=0x7a000fa4) at ../../gcc/gcc/gimple-low.c:217 #7 0x00b146a0 in _ZN12_GLOBAL__N_113pass_lower_cf7executeEP8function ( this=0x79ab92a0) at ../../gcc/gcc/gimple-low.c:110 #8 0x00e8b140 in _Z16execute_one_passP8opt_pass (pass=0x40716078) at ../../gcc/gcc/passes.c:2567 #9 0x00e8ba2c in _ZL19execute_pass_list_1P8opt_pass (pass=0x40716078) at ../../gcc/gcc/passes.c:2656 ---Type to continue, or q to quit--- #10 0x00e8bad0 in _Z17execute_pass_listP8functionP8opt_pass (fn=0x79ab92a0, pass=0x100) at ../../gcc/gcc/passes.c:2667 #11 0x00906578 in _ZN11cgraph_node7analyzeEv (this=) at ../../gcc/gcc/cgraphunit.c:680 #12 0x009098e0 in _ZL17analyze_functionsb (first_time=148) at ../../gcc/gcc/cgraphunit.c:1234 #13 0x0090a6c8 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x79c59000) at ../../gcc/gcc/cgraphunit.c:2508 #14 0x00fcd444 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:483 #15 0x00fd0d5c in _ZN6toplev4mainEiPPc (this=0x7a000a98, argc=0, argv=0x0) at ../../gcc/gcc/toplev.c:2233 #16 0x01461b40 in main (argc=20, argv=0x7a0008f4) at ../../gcc/gcc/main.c:39
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 --- Comment #5 from dave.anglin at bell dot net --- On 2021-09-17 2:46 a.m., rguenth at gcc dot gnu.org wrote: > Btw, it works with a cross from x86_64 to hppa64-hp-hpux11, but maybe I'm > doing > it wrong? It's probably caused by a bug in the TImode support that I'm working on.
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 --- Comment #2 from dave.anglin at bell dot net --- On 2021-09-16 1:38 p.m., jakub at gcc dot gnu.org wrote: > This looks wrong, comp_unit_die () should have DW_AT_producer at this point. > gen_compile_unit_die should have added it... I did change dwarf_version to 4.
[Bug target/19336] HPPA64 does not support TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19336 --- Comment #5 from dave.anglin at bell dot net --- Appears to require implementation of __lshrti3, __ashlti3, __ashrti3, __multi3, __udivti3, __umodti3, etc. Various soft float routines are needed to perform conversions to/from ti mode.
[Bug middle-end/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40505 --- Comment #10 from dave.anglin at bell dot net --- The ICE doesn't occur with g++-8, g++-9, g++-10 or g++-11, so I think this bug can be closed.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #24 from dave.anglin at bell dot net --- On 2021-09-01 8:23 p.m., pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 > > --- Comment #23 from Andrew Pinski --- > (In reply to Andrew Pinski from comment #22) >> The problem is in emit-rtl.c in set_mem_attributes_minus_bitpos: >> >> /* We can set the alignment from the type if we are making an object or if >> this is an INDIRECT_REF. */ >> if (objectp || TREE_CODE (t) == INDIRECT_REF) >> attrs.align = MAX (attrs.align, TYPE_ALIGN (type)); >> >> >> The type here is not the correct thing to do. > This has been a bug since r0-38512 (2001). Excellent work! I assume attrs.align should only be set from type when it is not set.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #21 from dave.anglin at bell dot net --- On 2021-09-01 7:21 p.m., pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 > > --- Comment #17 from Andrew Pinski --- > (In reply to dave.anglin from comment #14) >> On 2021-09-01 6:35 p.m., dave.anglin at bell dot net wrote: >>> We only get correct code at -O0. >> Maybe cpymemsi expander is problem. > It can't be as that is only used for !TARGET_64BIT and this is a TARGET_64BIT > as obvious by "LEVEL 2.0w". I changed expanders for both !TARGET_64BIT and TARGET_64BIT. Didn't help. Same error with trunk. Dave
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #14 from dave.anglin at bell dot net --- On 2021-09-01 6:35 p.m., dave.anglin at bell dot net wrote: > We only get correct code at -O0. Maybe cpymemsi expander is problem.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #13 from dave.anglin at bell dot net --- On 2021-09-01 5:52 p.m., pinskia at gcc dot gnu.org wrote: > This is doing the correct thing in splitting up the load into bytes loads. We only get correct code at -O0. STRICT_ALIGNMENT is defined to 1.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #7 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned() function. > So it will generate byte-accesses. I think it's the type rather than the alignment. If type is char, one gets byte accesses. If type is short, one gets 16-bit accesses. The alignment is being ignored.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #5 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned() function. > So it will generate byte-accesses. So, it seems the __aligned__ attribute is ignored: extern u32 output_len __attribute__((__aligned__(1)));
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #4 from dave.anglin at bell dot net --- On 2021-09-01 4:14 p.m., arnd at linaro dot org wrote: > Any idea what the difference is between the working version and your broken > one? Not really. My original test case worked as well. Helge created the broken one.
[Bug ada/101924] /usr/ccs/bin/ld: Unsatisfied symbols: U_get_unwind_entry, U_IS_STUB_OR_CALLX, U_get_shLib_text_addr, U_is_shared_pc, U_init_frame_record, U_prep_frame_rec_for_unwind, U_get_shLib_unw_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101924 --- Comment #3 from dave.anglin at bell dot net --- On 2021-08-16 5:11 a.m., charlet at gcc dot gnu.org wrote: > Can you confirm that these symbols are present in /usr/lib/libcl.a? The symbols are in libcl.a. I'll test patch in next build. Thanks, 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 #275 from dave.anglin at bell dot net --- On 2021-07-21 12:55 p.m., me at larbob dot org wrote: > Here's `disas $pc-256,$pc+256`'s output. Maybe r47 contains garbage.
[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 #271 from dave.anglin at bell dot net --- On 2021-07-21 2:32 a.m., me at larbob dot org wrote: > Reading symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD: > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol > number > 7215 references nonexistent SHT_SYMTAB_SHNDX section > Can't read symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in > wrong format This seems to be a problem with the symbol table in cc1. It's not a problem with the dwarf info. Can readelf read symbols? What does file command show? If you strip cc1, does gdb start? disasm $pc-16,$pc+16 should show faulting instruction.
[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 #259 from dave.anglin at bell dot net --- On 2021-07-19 5:00 p.m., me at larbob dot org wrote: > I've now tried 11.1.0 almost exactly as The Written Word builds it, and still > get: > > during GIMPLE pass: dce > ../../libiberty/mkstemps.c: In function 'mkstemps': > ../../libiberty/mkstemps.c:80:1: internal compiler error: Illegal instruction >80 | mkstemps (char *pattern, int suffix_len) > | ^~~~ The compiler being used to compile mkstemps.c is broken. If core dumps are enabled, you should be able to use gdb (wdb) directly to find the illegal instruction. If not, one can find the illegal instruction by adding "-save-temps -v" to the compile command. This will give the information needed to run the compilation under gdb (wdb) If I was to guess, the illegal instruction is likely to be an out of range branch. I would check HP patch for HP ld. There may be version dependent differences in weak support.
[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 #251 from dave.anglin at bell dot net --- On 2021-07-15 2:48 p.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #243 from The Written Word com> --- > (In reply to John Buddery from comment #238) >> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and >> later require a 64 bit build for 64 bit objects to work reliably. > I can build up to and including 2.32 with the HP C compiler. Starting with > 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry > with 2.32. Adding -std=gnu99 unilaterally seems like a bug.
[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 #242 from dave.anglin at bell dot net --- On 2021-07-15 11:01 a.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #241 from The Written Word com> --- > (In reply to John Buddery from comment #240) >> One question about PR66319 - it's marked as resolved, so is this committed >> as a patch in the trunk ? > It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed. Patch for PR66319 needs submission to gcc-patches list with cc to ia64 and/or hpux maintainer. Patch must be submitted by someone with copyright assignment or DOC. See: https://gcc.gnu.org/contribute.html
[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 #226 from dave.anglin at bell dot net --- John, would you please post your full patch set for ia64-hpux? This will help others.
