[Bug target/110011] -mfull-toc (-mfp-in-toc) yields incorrect _Float128 constants on power9

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011

Kewen Lin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Kewen Lin  ---
Should be fixed everywhere.

[Bug tree-optimization/95987] Another ice during GIMPLE pass: slp

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95987

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
  Component|c++ |tree-optimization
Version|unknown |11.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

--- Comment #2 from Richard Biener  ---
Can no longer reproduce, likely a dup of PR95916.

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

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> Can no longer reproduce, likely a dup of PR95916.
> 
> *** This bug has been marked as a duplicate of bug 95916 ***

Yes, I can confirm that it was fixed with r11-1710-g9a4a52e359ba16a2.

[Bug libstdc++/95990] New: Segmentation fault compiling with static libraries and using jthread::request_stop

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95990

Bug ID: 95990
   Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
   Product: gcc
   Version: 10.0
Status: RESOLVED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antal.buss at ualberta dot ca
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com
Resolution: DUPLICATE
Status: RESOLVED

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Richard Biener  ---
.

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

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053

Jiu Fu Guo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Jiu Fu Guo  ---
The generated code is a lot better on the trunk (both -O2 and -O3):
.cfi_startproc
dcmpuq 0,4,6
beq 0,.L4
blr
.p2align 4,,15
.L4:
fmr 5,7
fmr 4,6
fmr 3,7
fmr 2,6
blr


And the expanded RTL like below, and cse/fwprop/dse optimize it as expected. 
2: r119:TD=%2:TD
3: r120:TD=%4:TD
4: r121:TD=%6:TD
5: NOTE_INSN_FUNCTION_BEG
   10: r122:CCFP=cmp(r120:TD,r121:TD)
   11: pc={(r122:CCFP!=0)?L13:pc}
  REG_BR_PROB 708669604
   12: NOTE_INSN_BASIC_BLOCK 4
6: r120:TD=r121:TD
7: r119:TD=r121:TD
   13: L13:
   14: NOTE_INSN_BASIC_BLOCK 5
   15: r123:DI=r112:DI+0x10
   16: [r123:DI]=r120:TD
   17: [r112:DI]=r119:TD
   18: r124:TD=[r112:DI]
   19: r126:DI=r112:DI+0x10
   20: r125:TD=[r126:DI]
   21: r117:TD=r124:TD
   22: r118:TD=r125:TD
   26: %2:TD=r117:TD
   27: %4:TD=r118:TD
   28: use %2:TD
   29: use %4:TD

[Bug libstdc++/95991] New: Segmentation fault compiling with static libraries and using jthread::request_stop

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95991

Bug ID: 95991
   Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
   Product: gcc
   Version: 10.0
Status: RESOLVED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antal.buss at ualberta dot ca
  Target Milestone: ---
Resolution: DUPLICATE
Status: RESOLVED

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Richard Biener  ---
.

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

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638

--- Comment #12 from Jack Adrian Zappa  ---
Is it possible that 

  2. If a line comment end in an \ but the next line is a comment, then do
 the same thing as is done for a multi-line comment, ignore it as not an
 issue.

Could be done. I know I said or, but it would be nice not to have to add a
pragma if it is not necessary.

[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |12.0

--- Comment #23 from Patrick Palka  ---
Fixed since GCC 12

[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'

2024-01-14 Thread LpSolit at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637

--- Comment #6 from Maciej W. Rozycki  ---
Thanks WRT Ada clarification.

Otherwise I don't think there's anything stopping a language definition
from requiring an attempt to modify read-only data to be trapped as an
exceptional condition, leaving it up to the implementation as to whether
to use a hardware feature if available, or whether to rely purely on
software mechanisms, such as manually validating pointers to ensure they
refer to a location within the boundaries of a memory region designated
for writable data before any dereference for the purpose of a write.

For example the Linux kernel while it still supported the original 80386
processor used to manually validate kernel write accesses to user pages,
because crippled hardware would not trap on kernel writes to read-only
pages (this limitation was lifted with the CR0.WP bit from the 80486 on).
>From the Linux user ABI's point of view the solution was transparent.