[Bug gas/25550] Review .arch directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25550 --- Comment #12 from H.J. Lu --- (In reply to Jan Beulich from comment #11) > (In reply to H.J. Lu from comment #10) > > We need a directive for SSE instructions without MMX registers. > > We can give it a different name, something like pure-SSE. > > But what practical use would such an option be? You said yourself that > anything that can engage MMX state in the CPU also is liable to want/need > access to EMMS (or FEMMS), which won't be accessible with just SSE insns > permitted. I want assembler to enforce assembly codes without any access to MMX state. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25550 --- Comment #11 from Jan Beulich --- (In reply to H.J. Lu from comment #10) > We need a directive for SSE instructions without MMX registers. > We can give it a different name, something like pure-SSE. But what practical use would such an option be? You said yourself that anything that can engage MMX state in the CPU also is liable to want/need access to EMMS (or FEMMS), which won't be accessible with just SSE insns permitted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #57 from Martin Liška --- > Try the latest one. I can confirm it works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25550 --- Comment #10 from H.J. Lu --- (In reply to Jan Beulich from comment #9) > (In reply to H.J. Lu from comment #8) > > We can say something like > > > > In addition to the basic instruction set, the assembler can be told > > to accept various extension mnemonics. 4 separate vector ISA > > extension families can be enabled or disabled independent of each > > other: > > > > * 'MMX' - MMX instructions. > > > > * 'SSE' - SSE instructions without MMX registers. > > This is not a useful category. The only viable options I see are > - the full set of insns valid with SSE* (including ones accessing MMX > registers), > - all insns not touching MMX _state_ (which would permit use of CVTPI2PD > with a memory operand, but not use of a similar CVTPI2PS). > We need a directive for SSE instructions without MMX registers. We can give it a different name, something like pure-SSE. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #56 from H.J. Lu --- (In reply to Martin Liška from comment #48) > Ok, I've just packaged the 2.34 release branch with the backport of this > issue. > However, I see the following Invalid free: > > $ touch a.c && gcc -c -flto a.c -o a.o > $ touch a.c && gcc -c -flto a.c -o b.o > $ ar r libconsole.a a.o b.o > ar: creating libconsole.a > bfd plugin: could not unlink output file > free(): invalid pointer > Aborted (core dumped) > Try the latest one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Attachment #12287|0 |1 is obsolete|| Attachment #12297|0 |1 is obsolete|| --- Comment #55 from H.J. Lu --- Created attachment 12299 --> https://sourceware.org/bugzilla/attachment.cgi?id=12299&action=edit An updated patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25550 --- Comment #9 from Jan Beulich --- (In reply to H.J. Lu from comment #8) > We can say something like > > In addition to the basic instruction set, the assembler can be told > to accept various extension mnemonics. 4 separate vector ISA > extension families can be enabled or disabled independent of each > other: > > * 'MMX' - MMX instructions. > > * 'SSE' - SSE instructions without MMX registers. This is not a useful category. The only viable options I see are - the full set of insns valid with SSE* (including ones accessing MMX registers), - all insns not touching MMX _state_ (which would permit use of CVTPI2PD with a memory operand, but not use of a similar CVTPI2PS). In the latter case special care should be taken to at least warn about Intel syntax uses like "CVTPI2PD xmm0, mm0", as from simply looking at such an insn one wouldn't tell it uses a memory operand named "mm0". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #54 from Martin Liška --- However, I see one another segfault: $ cat 1.i int a; $ cat 2.i [empty file] $ gcc -flto=auto -O2 -fPIC 1.i -c $ gcc -flto=auto -O2 -fPIC 2.i -c $ ar cru x.a 1.o 2.o $ ranlib x.a Segmentation fault (core dumped) $ valgrind ranlib x.a ==423== Memcheck, a memory error detector ==423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==423== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==423== Command: ranlib x.a ==423== ==423== Invalid read of size 1 ==423==at 0x498CDF1: bfd_close (opncls.c:753) ==423==by 0x4B5D76D: bfd_plugin_close_and_cleanup (plugin.c:1074) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x497C31F: archive_close_worker (archive.c:2788) ==423==by 0x4B6F38E: htab_traverse_noresize (hashtab.c:775) ==423==by 0x497F9A4: _bfd_archive_close_and_cleanup (archive.c:2835) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x10CA11: write_archive (ar.c:1247) ==423==by 0x10DBA1: ranlib_only.part.0 (ar.c:1498) ==423==by 0x10BCF1: ranlib_only (ar.c:1492) ==423==by 0x10BCF1: ranlib_main (ar.c:695) ==423==by 0x10BCF1: main (ar.c:759) ==423== Address 0x4f57644 is 68 bytes inside a block of size 280 free'd ==423==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==423==by 0x498CD4E: bfd_close_all_done (opncls.c:797) ==423==by 0x498CD4E: bfd_close_all_done (opncls.c:785) ==423==by 0x4B5D76D: bfd_plugin_close_and_cleanup (plugin.c:1074) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x497C31F: archive_close_worker (archive.c:2788) ==423==by 0x4B6F38E: htab_traverse_noresize (hashtab.c:775) ==423==by 0x497F9A4: _bfd_archive_close_and_cleanup (archive.c:2835) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x10CA11: write_archive (ar.c:1247) ==423==by 0x10DBA1: ranlib_only.part.0 (ar.c:1498) ==423==by 0x10BCF1: ranlib_only (ar.c:1492) ==423==by 0x10BCF1: ranlib_main (ar.c:695) ==423==by 0x10BCF1: main (ar.c:759) ==423== Block was alloc'd at ==423==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==423==by 0x4986A41: bfd_malloc (libbfd.c:275) ==423==by 0x4986BD9: bfd_zmalloc (libbfd.c:360) ==423==by 0x498C72B: _bfd_new_bfd (opncls.c:62) ==423==by 0x498C917: bfd_fopen (opncls.c:200) ==423==by 0x4B5D7B4: add_input_file (plugin.c:389) ==423==by 0x52E01D1: ??? ==423==by 0x4B5E3C3: try_claim (plugin.c:564) ==423==by 0x4B5E3C3: try_load_plugin (plugin.c:710) ==423==by 0x4B5E8EB: load_plugin (plugin.c:848) ==423==by 0x4B5E8EB: bfd_plugin_object_p (plugin.c:861) ==423==by 0x49857F5: bfd_check_format_matches (format.c:261) ==423==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==423==by 0x498CE09: bfd_close (opncls.c:755) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #53 from Martin Liška --- (In reply to H.J. Lu from comment #52) > Created attachment 12297 [details] > A new patch The patch works for me! Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Attachment #12296|0 |1 is obsolete|| --- Comment #52 from H.J. Lu --- Created attachment 12297 --> https://sourceware.org/bugzilla/attachment.cgi?id=12297&action=edit A new patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #51 from H.J. Lu --- (In reply to Martin Liška from comment #49) > If I revert backport of 99845b3b77ed1248b6fb94707f88868bde358ccc, then it's > fine. Please try the new patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #50 from H.J. Lu --- Created attachment 12296 --> https://sourceware.org/bugzilla/attachment.cgi?id=12296&action=edit A patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #49 from Martin Liška --- If I revert backport of 99845b3b77ed1248b6fb94707f88868bde358ccc, then it's fine. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #48 from Martin Liška --- Ok, I've just packaged the 2.34 release branch with the backport of this issue. However, I see the following Invalid free: $ touch a.c && gcc -c -flto a.c -o a.o $ touch a.c && gcc -c -flto a.c -o b.o $ ar r libconsole.a a.o b.o ar: creating libconsole.a bfd plugin: could not unlink output file free(): invalid pointer Aborted (core dumped) $ valgrind ar r libconsole.a a.o b.o ==17300== Memcheck, a memory error detector ==17300== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==17300== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==17300== Command: ar r libconsole.a a.o b.o ==17300== ==17300== Invalid free() / delete / delete[] / realloc() ==17300==at 0x4839D7B: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x4B71929: xrealloc (xmalloc.c:179) ==17300==by 0x485B1B2: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E338: try_claim (plugin.c:565) ==17300==by 0x4B5E338: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497E5FC: _bfd_compute_and_write_armap (archive.c:2283) ==17300==by 0x497EF0B: _bfd_write_archive_contents (archive.c:2147) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== Address 0x4f568b0 is 0 bytes inside a block of size 8 free'd ==17300==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x485ABC3: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E362: try_claim (plugin.c:574) ==17300==by 0x4B5E362: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== Block was alloc'd at ==17300==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x4B7193F: xrealloc (xmalloc.c:177) ==17300==by 0x485B1B2: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E338: try_claim (plugin.c:565) ==17300==by 0x4B5E338: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== ar: out of memory allocating 16 bytes after a total of 0 bytes -- You are receiving this mail because: You are on the CC list for the bug.
