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-Bielefel
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.
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
UNSUPP
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 t
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #10 from dave.anglin at bell dot net ---
Warning is fixed on hppa.
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 compili
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 target
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:
>
> W
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 chang
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: /hom
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.
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) a
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-fr
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 ---
> Th
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(). */
>
> Technical
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:
>
> W
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:
>
> W
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:
>
> W
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 b
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
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 cstdli
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 h
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 ex
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
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). Ma
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 c
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_SYMBO
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:
&
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:
>
> W
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)
> +A
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.
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 t
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.
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
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
>>
>>
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
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-str
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 kn
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,
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/s
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 registe
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/s
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, an
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
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
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 i
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 202
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 &#x
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/
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 atta
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.
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
>
&g
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
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
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.
> Do
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
--- Comment #4 from dave.anglin at bell dot net ---
I currently have 2.36.
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 ...
Ye
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.
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.
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:
>
> W
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 ju
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 ye
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)
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
' fai
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
>> -fm
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 202
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.
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
>> -fm
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:
>
> W
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 202
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890
--- Comment #2 from dave.anglin at bell dot net ---
Is that what we want?
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
> ---
> Cre
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.
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 no
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.
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
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 cau
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...
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.
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.
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
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
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.
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
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"
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"
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 a
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 ne
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.
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/
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
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> ---
&g
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> ---
&g
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.
1 - 100 of 758 matches
Mail list logo
