[Bug testsuite/108776] new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu
   ||s390x-linux-gnu
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-05-11

--- Comment #1 from Richard Biener  ---
Also fails on s390x.

On ppc64le we only have four r<<, baz() and qux() are not handled (why
do we have 6 functions but expect 5 rotates only without checking exactly
which function we expect not to transform?).  On trunk we handle
baz() fine but still do not handle qux().

The IL into forwprop1 is the same so it's likely differences in ranger
behavior triggering here.

branch:

;; Function baz (baz, funcdef_no=2, decl_uid=3331, cgraph_uid=3,
symbol_order=2)

326  range_of_expr(y_11(D)) at stmt _2 = _1 << y_11(D);
327range_on_entry (y_11(D)) to BB 5
328  range_of_stmt (y_11(D)) at stmt GIMPLE_NOP
   GLOBAL : UPDATE cache for y_11(D) in BB 0 : successors :   : No updates!
 TRUE : (328) range_of_stmt (y_11(D)) unsigned int VARYING

y_11(D) : CACHE: BB 5 DOM query, found unsigned int VARYING at BB0
CACHE: Range for DOM returns : unsigned int VARYING
Filled from dominator! :  unsigned int VARYING
   TRUE : (327) range_on_entry (y_11(D)) unsigned int VARYING
 TRUE : (326) range_of_expr (y_11(D)) unsigned int VARYING
unsigned char baz (unsigned char x, unsigned int y)

trunk:

;; Function baz (baz, funcdef_no=2, decl_uid=3954, cgraph_uid=3,
symbol_order=2)

299  range_of_expr(y_11(D)) at stmt _2 = _1 << y_11(D);
300range_on_entry (y_11(D)) to BB 5
301  range_of_stmt (y_11(D)) at stmt GIMPLE_NOP
   GLOBAL : UPDATE cache for y_11(D) in BB 0 : successors :   : No updates!
 TRUE : (301) range_of_stmt (y_11(D)) [irange] unsigned int VARYING

y_11(D) : CACHE: BB 5 DOM query for y_11(D), found [irange] unsigned int
VARYING at BB0
302 GORI  outgoing_edge for y_11(D) on edge 2->5
303 GORIcompute op 1 (y_11(D)) at if (y_11(D) > 8)
GORI  LHS =[irange] _Bool [0, 0] NONZERO 0x0
GORI  Computes y_11(D) = [irange] unsigned int [0, 8] NONZERO 0xf
intersect Known range : [irange] unsigned int VARYING
GORITRUE : (303) produces  (y_11(D)) [irange] unsigned int [0, 8]
NONZERO 0xf
GORI  TRUE : (302) outgoing_edge (y_11(D)) [irange] unsigned int [0, 8]
NONZERO 0xf
CACHE: BB 3 DOM query for y_11(D), found [irange] unsigned int VARYING at BB2
304 GORI  outgoing_edge for y_11(D) on edge 2->3
305 GORIcompute op 1 (y_11(D)) at if (y_11(D) > 8)
GORI  LHS =[irange] _Bool [1, 1]
GORI  Computes y_11(D) = [irange] unsigned int [9, +INF] intersect
Known range : [irange] unsigned int VARYING
GORITRUE : (305) produces  (y_11(D)) [irange] unsigned int [9,
+INF]
GORI  TRUE : (304) outgoing_edge (y_11(D)) [irange] unsigned int [9,
+INF]
CACHE: Adjusted edge range for 2->3 : [irange] unsigned int [9, +INF]
CACHE: Range for DOM returns : [irange] unsigned int [9, +INF]
306 GORI  outgoing_edge for y_11(D) on edge 3->5
307 GORIcompute op 1 (y_11(D)) at if (y_11(D) != 16)
GORI  LHS =[irange] _Bool [0, 0] NONZERO 0x0
GORI  Computes y_11(D) = [irange] unsigned int [16, 16] NONZERO
0x10 intersect Known range : [irange] unsigned int VARYING
GORITRUE : (307) produces  (y_11(D)) [irange] unsigned int [16, 16]
NONZERO 0x10
GORI  TRUE : (306) outgoing_edge (y_11(D)) [irange] unsigned int [16,
16] NONZERO 0x10
CACHE: Range for DOM returns : [irange] unsigned int [0, 8][16, 16] NONZERO
0x1f
Filled from dominator! :  [irange] unsigned int [0, 8][16, 16] NONZERO 0x1f
   TRUE : (300) range_on_entry (y_11(D)) [irange] unsigned int [0,
8][16, 16] NONZERO 0x1f
 TRUE : (299) range_of_expr (y_11(D)) [irange] unsigned int [0, 8][16,
16] NONZERO 0x1f
gimple_simplified to _14 = _16;
Removing dead stmt _14 = _16;

unsigned char baz (unsigned char x, unsigned int y)


On x86_64 the IL into forwprop1 is different (logical-op-non-short-circuit):

ppc64le:
   :
  if (y_11(D) > 8)
goto ; [INV]
  else
goto ; [INV]

   :
  if (y_11(D) != 16)
goto ; [INV]
  else
goto ; [INV]

x86_64:
   :
  _1 = y_14(D) > 8;
  _2 = y_14(D) != 16;
  _3 = _1 & _2;
  if (_3 != 0)
goto ; [INV]
  else
goto ; [INV]

Setting --param logical-op-non-short-circuit=1 fixes the testcase for ppc64le
on the branch, I suspect it will be the same for s390x.

[Bug testsuite/108776] new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776

--- Comment #2 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #1)
> Setting --param logical-op-non-short-circuit=1 fixes the testcase for ppc64le
> on the branch, I suspect it will be the same for s390x.

Then let's go with that.
The PR106523/PR108440 fixes are heavily dependent on the ranger so that while
fixing the wrong-code it doesn't regress much in rotate recognition.  And the
ranger is increasingly less capable in older branches, that is why I chose not
to backport those
fixes at all to 10/11 branches.

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

--- Comment #2 from Uroš Bizjak  ---
(In reply to Haochen Jiang from comment #1)
> I further checked the reason, V2SI should never dropped into that function
> because we have no pattern under V2SI.
> 
> I suppose it is because -march=cascadelake will open SSE4.1, with the new
> pattern, it wrongly dropped into that.
> 
> -m32 will not ICE since TARGET_MMX_WITH_SSE need 64 bit and won't enable the
> new pattern.

V2SI mul was introduced in r14-493 (AKA partial fix for PR109690).

[Bug testsuite/108776] new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

[Bug target/109797] 456.hmmer compiled with -O2 -flto regressed by 15% on AMD zen3 between r14-487-g6f18f344338b37 and r14-540-gb7fe38c14e5f1b

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #4)
> No, it's indeed plain -O2 with the default architecture level, thus SSE2
> only.
> 
> For the case of "complex" expansions we might want to bite the bullet and
> fix the GIGO vectorizer cost modeling in the target.  add_stmt_cost should
> use ix86_multiplication_cost here passing down V2SImode.  There's cases
> for various integer multiplication emulations but your patch didn't amend
> this function for the new V2SImode emulation w/o SSE4.

Maybe the pattern should only be enabled for TARGET_SSE4_1, where it is
implemented with native instruction. Using PMULUDQ, shuffling arguments and the
result around looks like it will never be a win for V2SI, while it is
worthwhile for V4SI, where the approach is taken from.

The pattern was introduced as a partial fix for PR109690.

[Bug ada/109798] Gnat Bug Detected

[simon at pushface dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #1 from simon at pushface dot org ---
Can’t reproduce (Darwin 22.4.0, GCC 12.1, 12.2, 13.1).

I _do_ get the annoying warning that array aggregates using () is an
obsolescent syntax - see PR104751.

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I see the same for this C code on znver1:

typedef struct MonitorInfo MonitorInfo;
char *decode_edid_edid;
struct MonitorInfo {
  int width_mm;
  int height_mm
} decode_edid() {
  MonitorInfo info;
  MonitorInfo *__trans_tmp_3 = &info;
  {
MonitorInfo *info = __trans_tmp_3;
info->width_mm = 10 * decode_edid_edid[5];
info->height_mm = 10 * decode_edid_edid[6];
  }
  decode_headerdecode_vendor_and_product_identificationdecode_edid_version(
  info);
}

$ ~/gcc/results.20230511.asan.ubsan/bin/gcc -c -O2 -march=znver1 -w bug919.c
during GIMPLE pass: slp
bug919.c: In function ‘decode_edid’:
bug919.c:6:3: internal compiler error: in ix86_widen_mult_cost, at
config/i386/i386.cc:20442
6 | } decode_edid() {
  |   ^~~

It was ok yesterday:

$ ~/gcc/results.20230510.asan.ubsan/bin/gcc -c -O2 -march=znver1 -w bug919.c
$

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[haochen.jiang at intel dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

--- Comment #4 from Haochen Jiang  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Haochen Jiang from comment #1)
> > I further checked the reason, V2SI should never dropped into that function
> > because we have no pattern under V2SI.
> > 
> > I suppose it is because -march=cascadelake will open SSE4.1, with the new
> > pattern, it wrongly dropped into that.
> > 
> > -m32 will not ICE since TARGET_MMX_WITH_SSE need 64 bit and won't enable the
> > new pattern.
> 
> V2SI mul was introduced in r14-493 (AKA partial fix for PR109690).

I see. So we might need to add cost for that right?

[Bug libstdc++/109808] New: [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

Bug ID: 109808
   Summary: [12 regression] FAIL:
libstdc++-prettyprinters/libfundts.cc print as with
_GLIBCXX_USE_CXX11_ABI 0
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I'm seeing this subtest FAIL with the following in the log on the GCC 12 branch
when configured for the dual-ABI but defaulting to the C++11 ABI.  It works
fine when defaulting to gcc4-compat.  r12-9300-g0a6e26e7979805 removed
a #define to zero here.

$12 = Python Exception  No type named
std::experimental::fundamentals_v1::any::_Manager_internal, std::allocator >>.: ^M
got: $12 = Python Exception  No type named
std::experimental::fundamentals_v1::any::_Manager_internal, std::allocator >>.: ^M
FAIL: libstdc++-prettyprinters/libfundts.cc print as
Python Exception  No type named
std::experimental::fundamentals_v1::any::_Manager_internal, std::allocator >>.: ^M
skipping: Python Exception  No type named
std::experimental::fundamentals_v1::any::_Manager_internal, std::allocator >>.: ^M
{_M_manager = 0x40289c
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x41acf8, _M_buffer = {__data = "\370\254A\000\000\000\000", __align = {^M
skipping: {_M_manager = 0x40289c
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x41acf8, _M_buffer = {__data = "\370\254A\000\000\000\000", __align = {^M
$13 = std::experimental::any containing const char * = {[contained value] =
0x404555 "stringiest"}^M
got: $13 = std::experimental::any containing const char * = {[contained value]
= 0x404555 "stringiest"}^M

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |12.4
 CC||fdumont at gcc dot gnu.org

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

--- Comment #1 from Richard Biener  ---
correction, I see it when defaulting to the non-C++11 ABI.

[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension

[wangfeng at eswincomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592

--- Comment #5 from Feng Wang  ---
I found something interesting, these operations such as
zero_extend,sign_extend,zero_extract,sign_extract will be considered as
compound operation and will transform to the approriate shifts and AND
operations(This proc is in expand_compound_operation). So if the sign_extend op
generated earlier,it will be converted by expand_compound_operation again
during the after pass such as combine pass. 
In the combine pass, it will perform the opposite operation as above.Through
make_compound and make_extraction functions two shifts insns will combine into
sign_extend or zero_extend if the pattern exist,and then judge the cost of
it.It is profitable replacement only when the arch supports sign_extend and
costs less than two shifts insns.
So I think the first patch is enough,
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg303789.html
it handles the introduction of subregs when compiling and processing 32-bit
using a 64 bit compiler.
The first patch process the below rtl.
(set (reg:SI 137)
(ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 140)
(const_int 24 [0x18])) 0)
(const_int 24 [0x18])))
During extract_left_shift processing,it wants to get reg:DI 140,but now the
extraction is failed due to the subreg is in the front of the ashift. So I
think we just need jump the subreg is enough to ensure normal subsequent
processing.

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #3 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #2)
> Confirmed.  This is a missed optimization, we fail to optimize the loop guard
> 
>  [local count: 329643239]:
> _4 = (unsigned long) &MEM  [(void *)&str + 2B];
> _6 = (unsigned long) __i_14;
> _50 = -_6;
> _100 = _4 + 18446744073709551615;
> _40 = _100 - _6;
> _41 = _40 > 13;
> if (_41 != 0)

Do we even get a non-zero range for _4?  I'm assuming that even if we get that,
we can't see that &str+2B minus 1 is also nonzero?

> 
> with __i_14 being
> 
>  [local count: 452186132]:
> # __i_14 = PHI <&MEM  [(void *)&str + 1B](10), &MEM 
> [(void *)&str + 2B](9)>
> 
> I'll note that the strlen pass runs before VRP (but after DOM), but I'll
> also note that likely ranger isn't very good with these kind of
> "symbolic" ranges?  How would we handle this?  Using two
> relations, __i_14 >= &str + 1 && __i_14 <= &str + 2?

Yeah, we don't do much with that.  Although the pointer equivalency class
should help in VRP's case.  We do some simple pointer tracking and even call
into gimple fold to simplify statements, but it's far from perfect and as you
say, strlen is running before VRP, so it wouldn't help in this case.

> 
> DOM has
> 
> Optimizing block #16
> 
> 1>>> STMT 1 = &MEM  [(void *)&str + 2B] ge_expr __i_14
> 1>>> STMT 1 = &MEM  [(void *)&str + 2B] ne_expr __i_14
> 1>>> STMT 0 = &MEM  [(void *)&str + 2B] eq_expr __i_14
> 1>>> STMT 1 = &MEM  [(void *)&str + 2B] gt_expr __i_14
> 1>>> STMT 0 = &MEM  [(void *)&str + 2B] le_expr __i_14
> Optimizing statement _4 = (unsigned long) &MEM  [(void *)&str + 2B];
> LKUP STMT _4 = nop_expr &MEM  [(void *)&str + 2B]
> 2>>> STMT _4 = nop_expr &MEM  [(void *)&str + 2B]
> Optimizing statement _6 = (unsigned long) __i_14;
> LKUP STMT _6 = nop_expr __i_14
> 2>>> STMT _6 = nop_expr __i_14
> Optimizing statement _50 = -_6;
>  Registering value_relation (_6 pe64 __i_14) (bb16) at _6 = (unsigned long)
> __i_14;
> LKUP STMT _50 = negate_expr _6
> 2>>> STMT _50 = negate_expr _6
> Optimizing statement _100 = _4 + 18446744073709551615;
> LKUP STMT _100 = _4 plus_expr 18446744073709551615
> 2>>> STMT _100 = _4 plus_expr 18446744073709551615
> Optimizing statement _40 = _100 - _6;
>  Registering value_relation (_100 < _4) (bb16) at _100 = _4 +
> 18446744073709551615;
> LKUP STMT _40 = _100 minus_expr _6
> 2>>> STMT _40 = _100 minus_expr _6
> Optimizing statement _41 = _40 > 13;
> LKUP STMT _41 = _40 gt_expr 13
> 2>>> STMT _41 = _40 gt_expr 13
> LKUP STMT _40 le_expr 14
> Optimizing statement if (_41 != 0)
> 
> Visiting conditional with predicate: if (_41 != 0)
> 
> With known ranges
> _41: [irange] bool VARYING

Ranger won't do anything, but can DOM's scoped tables do anything here?  The
hybrid threader in DOM first asks DOM's internal mechanism before asking ranger
(which seems useless in this case):

dom_jt_simplifier::simplify (gimple *stmt, gimple *within_stmt,
 basic_block bb, jt_state *state)
{
  /* First see if the conditional is in the hash table.  */
  tree cached_lhs =  m_avails->lookup_avail_expr (stmt, false, true);
  if (cached_lhs)
return cached_lhs;

  /* Otherwise call the ranger if possible.  */
  if (state)
return hybrid_jt_simplifier::simplify (stmt, within_stmt, bb, state);

  return NULL;
}

Our long term plan for pointers was providing a prange class and separating
pointers from irange.  This class would track zero/nonzero mostly, but it would
also do some pointer equivalence tracking, thus subsuming what we do with
pointer_equiv_analyzer which is currently restricted to VRP and is an
on-the-side hack.

The prototype I had for it last release tracked the equivalence plus an offset,
so we should be able to do arithmetic on a prange of say [&str + X].  I had to
put it aside because the frange work took way longer than expected, plus legacy
got in the way.  Neither of this is an issue now, so we'll see.. but that's the
plan.  I should dust off those patches :-/.

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

--- Comment #5 from Uroš Bizjak  ---
(In reply to Haochen Jiang from comment #4)
> (In reply to Uroš Bizjak from comment #2)
> > (In reply to Haochen Jiang from comment #1)
> > > I further checked the reason, V2SI should never dropped into that function
> > > because we have no pattern under V2SI.
> > > 
> > > I suppose it is because -march=cascadelake will open SSE4.1, with the new
> > > pattern, it wrongly dropped into that.
> > > 
> > > -m32 will not ICE since TARGET_MMX_WITH_SSE need 64 bit and won't enable 
> > > the
> > > new pattern.
> > 
> > V2SI mul was introduced in r14-493 (AKA partial fix for PR109690).
> 
> I see. So we might need to add cost for that right?

Adding "case V2SImode:" above "case V4SImode:" in ix86_widen_mult_cost will fix
this issue. Probably V4HImode is also needed above V8HImode, we have had a
mulv4hi3 pattern for some time now.

[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:c49d51fa8134f6c7e6c7cf6e4e3007c4fea617c5

commit r14-677-gc49d51fa8134f6c7e6c7cf6e4e3007c4fea617c5
Author: Joseph Myers 
Date:   Thu May 11 10:07:00 2023 +0200

Implement LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [PR109128]

This is one part of the fix for PR109128, along with a corresponding
binutils's linker change.  Without this patch, what happens in the
linker, when an unused object in a .a file has offload data, is that
elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p,
which ends up calling the plugin's claim_file_handler, which then
records the object as one with offload data. That is, the linker never
decides to use the object in the first place, but use of this _p
interface (called as part of trying to decide whether to use the
object) results in the plugin deciding to use its offload data (and a
consequent mismatch in the offload data present at runtime).

The new hook allows the linker plugin to distinguish calls to
claim_file_handler that know the object is being used by the linker
(from ldmain.c:add_archive_element), from calls that don't know it's
being used by the linker (from elf_link_is_defined_archive_symbol); in
the latter case, the plugin should avoid recording the object as one
with offload data.

PR middle-end/109128

include/
* plugin-api.h (ld_plugin_claim_file_handler_v2)
(ld_plugin_register_claim_file_v2)
(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
(struct ld_plugin_tv): Add tv_register_claim_file_v2.

lto-plugin/
* lto-plugin.c (register_claim_file_v2): New.
(claim_file_handler_v2): New.
(claim_file_handler): Wrap claim_file_handler_v2.
(onload): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2.

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #4 from Aldy Hernandez  ---
BTW, another reason I had to drop the prange work was because IPA was doing
their own thing with ranges outside of the irange API, so it was harder to
separate things out.  So really, all this stuff was related to legacy, which is
mostly gone, and my upcoming work on IPA later this cycle should clean up the
rest of IPA.

[Bug target/109797] 456.hmmer compiled with -O2 -flto regressed by 15% on AMD zen3 between r14-487-g6f18f344338b37 and r14-540-gb7fe38c14e5f1b

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> Created attachment 55045 [details]
> Proposed patch
> 
> Proposed patch to fix the ix86_multiplication_cost for non-SSE4 V2SI
> emulation.

Martin, does this patch fix the runtime regression?

[Bug target/109797] 456.hmmer compiled with -O2 -flto regressed by 15% on AMD zen3 between r14-487-g6f18f344338b37 and r14-540-gb7fe38c14e5f1b

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797

--- Comment #6 from Uroš Bizjak  ---
Created attachment 55045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55045&action=edit
Proposed patch

Proposed patch to fix the ix86_multiplication_cost for non-SSE4 V2SI emulation.

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

--- Comment #2 from Jonathan Wakely  ---
Is this really a 12 regression? I think it's failed that way for some time when
using the old ABI, it's just that nobody except me tests it that way :-)

I think it was fixed on trunk by r13-4080-g2b7f0378b915a6 and backported as
r12-9301-g0970eafdc61d75

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> I think it was fixed on trunk by r13-4080-g2b7f0378b915a6 and backported as
> r12-9301-g0970eafdc61d75

At least, I don't see a failure for that test since that commit (which is why
it removed the define).

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-11
 Status|UNCONFIRMED |ASSIGNED

--- Comment #4 from Jonathan Wakely  ---
Ah I see the problem, we need to backport r13-4091-g3c54805d03ac1b too. Not
sure why I don't see a failure though.

[Bug ada/109798] Gnat Bug Detected

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #2 from Marc Poulhiès  ---
Can't reproduce on x86_64-linux trunk, 13.1, 12.3, 12.2, 11.3, see
https://ada.godbolt.org/z/Gbv9Wc93E

Can you get the exact compiler invocation?

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808

--- Comment #5 from Jonathan Wakely  ---
Backported as r12-9530-g16a76499f916b5 so I hope this is fixed now (I still
can't reproduce it even with a --with-default-libstdcxx-abi=gcc4-compatible
build).

[Bug target/109809] New: ICE in dwarf2out_frame_debug_cfa_offset, at dwarf2cfi.cc:1376

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809

Bug ID: 109809
   Summary: ICE in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: s390x-linux-gnu-gcc

With cross compiler configured as

/home/worker/buildworker/tiber-gcc-trunk-s390x/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=s390x-linux-gnu
--with-as=/usr/bin/s390x-suse-linux-as

running:

~/cross/bin/s390x-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/ldist-9.c
-fstack-clash-protection -mpreserve-args -Ofast
--param=stack-clash-protection-probe-interval=10

Results in:

during RTL pass: dwarf2
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/ldist-9.c:
In function ‘loop1’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/ldist-9.c:23:1:
internal compiler error: in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376
   23 | }
  | ^
0x606f65 dwarf2out_frame_debug_cfa_offset
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:1376
0x606f65 dwarf2out_frame_debug
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:2285
0x606f65 scan_insn_after
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:2726
0x7efb77 scan_trace
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:2893
0x7efed5 create_cfi_notes
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:2938
0x7efed5 execute_dwarf2_frame
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:3309
0x7efed5 execute
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/dwarf2cfi.cc:3799

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #5 from Richard Biener  ---
DOMs scoped tables do not help.  The crux is really the PHI:

 __i_14 = PHI <&MEM  [(void *)&str + 1B](10), &MEM 
> [(void *)&str + 2B](9)>

there's no single value that exposes &str + offset.

For

  _4 = (unsigned long) &MEM  [(void *)&str + 2B];

we might want to go and express it as

  _4' = (unsigned long) &str;
  _4  = _4' + 2;

but the issue with the PHI node remains unless we sink the &str part
(but there's many uses of __i_14).  I guess it's still the "easiest"
way to get rangers help.  Aka make

 # __i_14' = PHI <1(10), 2(9)>
 __i_14 = &str + __i_14'; // would be a POINTER_PLUS_EXPR

it's probably still not a complete fix but maybe a good start.  Of course
it increases the number of stmts - &MEM[&str + 1B] was an 'invariant'
(of course the PHI result isn't).  There's not a good place for this
transform - we never "fold" PHIs (and this would be an un-folding).

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #6 from Aldy Hernandez  ---

> but the issue with the PHI node remains unless we sink the &str part
> (but there's many uses of __i_14).  I guess it's still the "easiest"
> way to get rangers help.  Aka make
> 
>  # __i_14' = PHI <1(10), 2(9)>
>  __i_14 = &str + __i_14'; // would be a POINTER_PLUS_EXPR
> 
> it's probably still not a complete fix but maybe a good start.  Of course
> it increases the number of stmts - &MEM[&str + 1B] was an 'invariant'
> (of course the PHI result isn't).  There's not a good place for this
> transform - we never "fold" PHIs (and this would be an un-folding).

Ughh, that sucks.  Let's see if Andrew has any ideas, but on my end I won't be
able to work on prange until much later this cycle-- assuming I finish what I
have on my plate.

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806

--- Comment #3 from Amyspark  ---
Created attachment 55046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55046&action=edit
ZIP copy of the Github gist

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806

--- Comment #4 from Amyspark  ---
(In reply to Richard Biener from comment #2)
> Likely a duplicate of a bug where ranger runs out of stack on windows
> targets.

I think you mean bug 109695? If so, it affects GCC 13 as well.

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

[jskumari at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009

--- Comment #7 from Surya Kumari Jangala  ---
There are a couple of issues in IRA:

1. In improve_allocation() routine, we are not considering save/restore cost of
using a callee save register (r31 in the failing case). Due to this, r31 is
being chosen instead of r3 for allocno r118.

2. In find_costs_and_classes(), we are not computing the cost of register moves
when we have a 'set' insn that copies from one pseudo reg to another pseudo
reg. This is resulting in r118 having ALLOCNO_CLASS_COST of 0.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

--- Comment #19 from LIU Hao  ---
(In reply to jbeulich from comment #11)
> I have a rough plan on the gas side, but that will then need a gcc side
> change as well: For a couple of years we have had quoted symbol names there.
> While this doesn't currently work right in a number of cases (including the
> one needed here) the plan is to make e.g.
> 
> mov eax, "ecx"
> 
> not be treated the same as
> 
> mov eax, ecx
> 
> but considering "ecx" a symbol name due to the quotation. Obviously gcc's

I don't like double quotes here, because it looks something different, like in
C. Would it make some sense if we take the approach for MIPS and AArch64 [1],
so

  mov eax, %ecx

or

  mov eax, :ecx

denotes `ecx` is the name of a label, and otherwise a register. Also, such a
prefix should be optional, so people who write assembly can omit it if they
carefully avoid such names.


[1] https://maskray.me/blog/2023-05-08-assemblers

[Bug target/109800] [11/12/13/14 Regression] arm: ICE (segfault) loading double with -mpure-code -mbig-endian

[acoplan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/618
   ||156.html
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
   Keywords||patch
   Last reconfirmed||2023-05-11

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[jbeulich at suse dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

--- Comment #20 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #19)
> (In reply to jbeulich from comment #11)
> > I have a rough plan on the gas side, but that will then need a gcc side
> > change as well: For a couple of years we have had quoted symbol names there.
> > While this doesn't currently work right in a number of cases (including the
> > one needed here) the plan is to make e.g.
> > 
> > mov eax, "ecx"
> > 
> > not be treated the same as
> > 
> > mov eax, ecx
> > 
> > but considering "ecx" a symbol name due to the quotation. Obviously gcc's
> 
> I don't like double quotes here, because it looks something different, like
> in C.

This is assembly; I don't see how (dis)similarity with C would matter. I also
don't see how your example is any different in this regard from

mov eax, "symbol"

which gas has been supporting for quite some time.

> Would it make some sense if we take the approach for MIPS and AArch64
> [1], so
> 
>   mov eax, %ecx
> 
> or
> 
>   mov eax, :ecx
> 
> denotes `ecx` is the name of a label, and otherwise a register. Also, such a
> prefix should be optional, so people who write assembly can omit it if they
> carefully avoid such names.

I can't find any indication of such syntax being supported by gas for either of
these architectures. % on MIPS and : on Arm64 actually are involved in
relocation specifiers instead. Are you suggesting to overload them?

(Note that % is out of game here, for being the register prefix on x86.)

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 11 May 2023, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
> 
> --- Comment #6 from Aldy Hernandez  ---
> 
> > but the issue with the PHI node remains unless we sink the &str part
> > (but there's many uses of __i_14).  I guess it's still the "easiest"
> > way to get rangers help.  Aka make
> > 
> >  # __i_14' = PHI <1(10), 2(9)>
> >  __i_14 = &str + __i_14'; // would be a POINTER_PLUS_EXPR
> > 
> > it's probably still not a complete fix but maybe a good start.  Of course
> > it increases the number of stmts - &MEM[&str + 1B] was an 'invariant'
> > (of course the PHI result isn't).  There's not a good place for this
> > transform - we never "fold" PHIs (and this would be an un-folding).
> 
> Ughh, that sucks.  Let's see if Andrew has any ideas, but on my end I won't be
> able to work on prange until much later this cycle-- assuming I finish what I
> have on my plate.

So the idea with the above is of course that via regular folding
and value-numbering we can simplify the compare to a compare of
just the offsets and for those ranger already works.  The expression
is quite obfuscated of course and as said the strlen pass placement
doesn't help (it's before forwprop and VRP).

That said, the place to transform the PHI node is probably the same
where degenerate PHIs are removed.

For the testcase the PHI is created quite early by cunrolli.

I have a patch splitting the PHI.  We then still have

  # _69 = PHI <1(9), 2(8)>
  __i_44 = &str + _69;
...
   [local count: 402445658]:
  _51 = (unsigned long) &MEM  [(void *)&str + 2B];
  _4 = (unsigned long) __i_44;
  _12 = -_4;
  _119 = _51 + 18446744073709551615;
  _48 = _119 - _4;
  _46 = _48 > 13;
  if (_46 != 0)
goto ; [64.00%]

and also

  _31 = &MEM  [(void *)&str + 3B] <= __i_44;

so at least for the latter we are missing a simplification
pattern - it should simplify the compare to

  _31 = 3 <= _69

possibly (unsigned)(p p+ offset) should be changed to
(unsigned)p + offset and thus likewise (unsigned) &MEM[&str + 4B] into
(unsigned)&str + 4.

[Bug target/109661] [13 Regression] ICE in aarch64_function_arg_alignment when building erlang

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661

--- Comment #11 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:891cdd3b935e3ee9f1b2ecf7390801c534d39a90

commit r13-7318-g891cdd3b935e3ee9f1b2ecf7390801c534d39a90
Author: Richard Sandiford 
Date:   Thu May 11 12:36:26 2023 +0100

aarch64: Remove alignment assertions [PR109661]

The trunk patch for this PR corrected the ABI for enums that have
a defined underlying type.  We shouldn't change the ABI on the branches
though, so this patch just removes the assertions that highlighed
the problem.

I think the same approach makes sense longer-term: keep the assertions
at maximum strength in trunk, and in any new branches that get cut.
Then, if the assertions trip an ABI problem, fix the problem in trunk
and remove the assertions from active branches.

The tests are the same as for the trunk version, but with all Wpsabi
message and expected output checks removed.

gcc/
PR target/109661
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment):
Remove
assertion.
(aarch64_layout_arg): Likewise.

gcc/testsuite/
PR target/109661
* g++.target/aarch64/pr109661-1.C: New test.
* g++.target/aarch64/pr109661-2.C: Likewise.
* g++.target/aarch64/pr109661-3.C: Likewise.
* g++.target/aarch64/pr109661-4.C: Likewise.
* gcc.target/aarch64/pr109661-1.c: Likewise.

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #8 from Richard Biener  ---
Created attachment 55047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55047&action=edit
patch unfolding such PHIs

[Bug modula2/109810] New: String literal exceeding array causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810

Bug ID: 109810
   Summary: String literal exceeding array causes ICE
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gm2 mailing list.  If a string literal exceeding the array
size is assigned then an ICE occurs.  For example:

MODULE highice ;

VAR
   a: ARRAY [0..0] OF CHAR ;
BEGIN
   a := '12'
END highice.

[Bug modula2/109810] String literal exceeding array causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-05-11

--- Comment #1 from Gaius Mulley  ---
Confirmed with the test code on gcc-14.

[Bug modula2/109810] String literal exceeding array causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810

--- Comment #2 from Gaius Mulley  ---
gm2 -g highice.mod 
highice.mod:6:6: warning: string constant is too large to be assigned to the
array
6 |a := '12'
  |  ^~
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
during GIMPLE pass: lower
In function ‘_M2_highice_init’:
cc1gm2: internal compiler error: in constant_byte_string, at expr.cc:12378
0x725205 constant_byte_string
../../gcc-13.1.0-RC-20230419/gcc/expr.cc:12378
0x9dde49 c_strlen(tree_node*, int, c_strlen_data*, unsigned int)
../../gcc-13.1.0-RC-20230419/gcc/builtins.cc:609
0xbc4f43 gimple_fold_builtin_memory_op
../../gcc-13.1.0-RC-20230419/gcc/gimple-fold.cc:976
0xbc6b8c gimple_fold_builtin
../../gcc-13.1.0-RC-20230419/gcc/gimple-fold.cc:5018
0xbc6b8c gimple_fold_call
../../gcc-13.1.0-RC-20230419/gcc/gimple-fold.cc:5576
0xbc8a3b fold_stmt_1
../../gcc-13.1.0-RC-20230419/gcc/gimple-fold.cc:6328
0x1c11ae7 lower_stmt
../../gcc-13.1.0-RC-20230419/gcc/gimple-low.cc:793
0x1c12752 lower_sequence
../../gcc-13.1.0-RC-20230419/gcc/gimple-low.cc:229
0x1c12752 lower_gimple_bind
../../gcc-13.1.0-RC-20230419/gcc/gimple-low.cc:882
0x1c128fb lower_function_body
../../gcc-13.1.0-RC-20230419/gcc/gimple-low.cc:119
0x1c128fb execute
../../gcc-13.1.0-RC-20230419/gcc/gimple-low.cc:206
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

[Bug libstdc++/109758] std::abs(__float128) doesn't support NaN

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:af595613acbd9863198ae69c7b1c9e856bca9e4f

commit r14-700-gaf595613acbd9863198ae69c7b1c9e856bca9e4f
Author: Jonathan Wakely 
Date:   Wed May 10 12:20:58 2023 +0100

libstdc++: Fix std::abs(__float128) for -NaN and -0.0 [PR109758]

The current implementation of this non-standard overload of std::abs
incorrectly returns a negative value for negative NaNs and negative
zero, because x < 0 is false in both cases.

Use fabsl(long double) or fabsf128(_Float128) if those do the right
thing.  Otherwise, use __builtin_signbit(x) instead of x < 0 to detect
negative inputs. This assumes that __builtin_signbit handles __float128
correctly, but that seems to be true for all of GCC, clang and icc.

libstdc++-v3/ChangeLog:

PR libstdc++/109758
* include/bits/std_abs.h (abs(__float128)): Handle negative NaN
and negative zero correctly.
* testsuite/26_numerics/headers/cmath/109758.cc: New test.

[Bug libstdc++/109758] std::abs(__float128) doesn't support NaN

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Jonathan Wakely  ---
Fixed for 13.2 (but could be backported later).

[Bug libstdc++/109758] std::abs(__float128) doesn't support NaN

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.2|14.0

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> Fixed for 13.2 (but could be backported later).

Oops, I meant 14, it's not backported to gcc-13.

[Bug ada/109798] Gnat Bug Detected

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-11
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Eric Botcazou  ---
Yep, the command line passed to the compiler, please.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

--- Comment #21 from LIU Hao  ---
(In reply to jbeulich from comment #20)
> This is assembly; I don't see how (dis)similarity with C would matter. I
> also don't see how your example is any different in this regard from
> 
> mov eax, "symbol"
> 
> which gas has been supporting for quite some time.

oh really? I thought it would have to be implemented. If it's readily
available, we can start making use of it right now.

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #9 from Richard Biener  ---
So the first pass that makes things difficult is reassoc which transforms

  _51 = (unsigned long) &MEM  [(void *)&str + 2B];
  _4 = (unsigned long) __i_44;
  _65 = _51 - _4;
  _48 = _65 + 18446744073709551615;
  _46 = _48 > 13;
  if (_46 != 0)

to

  _51 = (unsigned long) &MEM  [(void *)&str + 2B];
  _4 = (unsigned long) __i_44;
  _12 = -_4;
  _119 = _51 + 18446744073709551615;
  _48 = _119 - _4;
  _46 = _48 > 13;
  if (_46 != 0)

(also leaving garbage around).  That's probably because of the PHI biasing
and __i_44 being defined by a PHI.  niter analysis produces

# of iterations (((unsigned long) &MEM  [(void *)&str + 2B] -
(unsigned long) __i_44) + 18446744073709551615) / 2, bounded by
9223372036854775807

but doesn't expand __i_44 (not sure if we'd fold the thing then).  The
gimplifier folds stmts w/o following SSA edges when we eventually
re-gimplify those expressions for insertion.  If we expand offsetting of
invariant bases we get instead

# of iterations ((unsigned long) &MEM  [(void *)&str + 2B] - (unsigned
long) (&str + (_69 + 1))) / 2, bounded by 9223372036854775807

but that's still not simplified.  I think ptr_difference_const should
handle this - of course the difference here isn't const...

/* Try folding difference of addresses.  */ 
(simplify
 (minus (convert ADDR_EXPR@0) (convert @1))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with { poly_int64 diff; } 
   (if (ptr_difference_const (@0, @1, &diff))
{ build_int_cst_type (type, diff); }
(simplify 
 (minus (convert @0) (convert ADDR_EXPR@1))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @1, &diff))
{ build_int_cst_type (type, diff); } 

it works fine when adding

(simplify
 (minus (convert ADDR_EXPR@0) (convert (pointer_plus @1 @2)))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @1, &diff))
(minus { build_int_cst_type (type, diff); } (convert @2))

then we get

# of iterations (1 - (unsigned long) _69) / 2, bounded by
9223372036854775807

and the diagnostic is gone.

[Bug ada/108157] [12/13/14 regression] object subtype doesn't statically match designated subtype

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108157

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
--  Ada 2005 (AI-363): Require static matching when designated
--  type has discriminants and a constrained partial view, since
--  in general objects of such types are mutable, so we can't
--  allow the access value to designate a constrained object
--  (because access values must be assumed to designate mutable
--  objects when designated type does not impose a constraint).

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #10 from Richard Biener  ---
Created attachment 55048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55048&action=edit
patch for niter expression expansion

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

--- Comment #11 from Richard Biener  ---
Created attachment 55049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55049&action=edit
patch for extra pointer difference patterns

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #12 from Richard Biener  ---
So let me see if this all works out reasonably.

[Bug ada/109798] Gnat Bug Detected

[aj at ianozi dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

aj at ianozi dot com changed:

   What|Removed |Added

 CC||aj at ianozi dot com

--- Comment #4 from aj at ianozi dot com ---
Created attachment 55050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55050&action=edit
my alire project with the same code, but failing when I run "alr build"

Oh, huh.  When I build it using gnatmake there's no issues, e.g.
`gnatmake testing.adb`

But when I build it using alire it fails (which is how I was managing my
project).  Let me reach out to the alire team and see if it's happening for
others using Alire.

[Bug c/109393] Very trivial address calculation does not fold

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393

--- Comment #5 from Richard Biener  ---
(In reply to manolis.tsamis from comment #4)
> Given the original transform it should be valid to propagate the constant
> addition through the cast?

Yes.  Note doing so loses information, we know i + 1 doesn't overflow
(undefined behavior).  Widening preserves this knowledge I think, but if
just an unsigned conversion would be propagated it would be lost.

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

[amonakov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
I'm giving this a shot, and with -flto-partition=1to1 there's a ranger ICE
(below).

What's the current best practice for LTO debugging? I don't imagine there's an
easy way to identify which of 2000 lto1 invocation crashes, or attach gdb to
it? Or at least generate a corefile?

0x10308fd internal_error(char const*, ...)
???:0
0x13dcf8c operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&, tree_code) const
???:0
0x136882a fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
???:0
0x1323eb5 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
???:0
0x134a417 path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
???:0
0x13499b4 path_range_query::range_defined_in_block(irange&, tree_node*,
basic_block_def*)
???:0
0x135503a path_range_query::internal_range_of_expr(irange&, tree_node*,
gimple*)
???:0
0x1368424 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
???:0
0x1323eb5 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
???:0
0x134a417 path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
???:0
0x13499b4 path_range_query::range_defined_in_block(irange&, tree_node*,
basic_block_def*)
???:0
0x135503a path_range_query::internal_range_of_expr(irange&, tree_node*,
gimple*)
???:0
0x1368424 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
???:0
0x1323eb5 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
???:0
0x134a417 path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
???:0
0x13499b4 path_range_query::range_defined_in_block(irange&, tree_node*,
basic_block_def*)
???:0
0x135503a path_range_query::internal_range_of_expr(irange&, tree_node*,
gimple*)
???:0
0x1368424 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
???:0
0x1323eb5 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
???:0
0x134a417 path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
???:0

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806

--- Comment #5 from Richard Biener  ---
(In reply to Amyspark from comment #4)
> (In reply to Richard Biener from comment #2)
> > Likely a duplicate of a bug where ranger runs out of stack on windows
> > targets.
> 
> I think you mean bug 109695? If so, it affects GCC 13 as well.

Yeah, the rev in that bug increases stack requirement even more though, but
yes, I think the problem is the same in principle.

[Bug ada/109798] Gnat Bug Detected

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #5 from Eric Botcazou  ---
> Oh, huh.  When I build it using gnatmake there's no issues, e.g.
> `gnatmake testing.adb`

Interesting.  Can you pass -v to GPRbuild to display the command line?

[Bug c/109393] Very trivial address calculation does not fold

[manolis.tsamis at vrull dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393

--- Comment #6 from manolis.tsamis at vrull dot eu ---
(In reply to Richard Biener from comment #5)
> (In reply to manolis.tsamis from comment #4)
> > Given the original transform it should be valid to propagate the constant
> > addition through the cast?
> 
> Yes.  Note doing so loses information, we know i + 1 doesn't overflow
> (undefined behavior).  Widening preserves this knowledge I think, but if
> just an unsigned conversion would be propagated it would be lost.

So, is that the reason that this transform isn't already implemented as an
optimisation?

But then again isn't this information also lost in the code currently produced
by GCC, where the constant is already propagated? Although I can see how it is
different to do the propagation of constants in the front-end only vs doing it
anywhere while transforming the code; maybe that's the difference that matters.
But hopefully doing better canonicalization/constant folding on address
calculations and constants should also result in better optimisation
opportunities overall.

[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757

Jiu Fu Guo  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

--- Comment #20 from Jiu Fu Guo  ---
(In reply to Andrew Pinski from comment #19)
> Note in the loop case we know it does not wrap because there is a check
> already:
>[local count: 118111600]:
>   if (rows_8(D) > 3)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 105119324]:
>   _13 = rows_8(D) + 18446744073709551612;
>   _15 = _13 / 4;
>   doloop.6_5 = _15 + 1;

Checking why below code does not work:
/* Simplify ((t + -N*M) / N + M) -> t / N: (t + -C) >> N + (C>>N) ==> t >> N */
(for div (trunc_div round_div)
 (simplify
  (plus (rshift (plus @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
  (if (ANY_INTEGRAL_TYPE_P (type) &&
   (wi::to_wide (@3) << wi::to_wide (@2)) == -wi::to_wide (@1))
   (if (TYPE_OVERFLOW_UNDEFINED (type))
(div @0 @2)
#if GIMPLE
(with
 {
   bool overflowed = true;
   value_range vr0;
   if (INTEGRAL_TYPE_P (type)
   && get_global_range_query ()->range_of_expr (vr0, @0)
   && !vr0.varying_p () && !vr0.undefined_p ())
 {
   wide_int wmin0 = vr0.lower_bound ();
   wide_int wmax0 = vr0.upper_bound ();
   wide_int w1 = -wi::to_wide (@1);
   wi::overflow_type min_ovf, max_ovf;
   wi::add (wmin0, w1, TYPE_SIGN (type), &min_ovf);
   wi::add (wmax0, w1, TYPE_SIGN (type), &max_ovf);
   if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE)
 overflowed = false;
 }
 }
(if (!overflowed)
 (div @0 @2)))
#endif
   


Interesting thing:
the VR is always VR_VARYING, even for the below simple case:

typedef unsigned long INT;
INT __attribute__ ((noinline)) foo (INT x)
{
  if (x < 4)
return 0;
  INT a = x + 18446744073709551612ULL;
  INT b = a >> 2;
  return b + 1;
}

[Bug middle-end/104151] [10/11/12/13/14 Regression] x86: excessive code generated for 128-bit byteswap

[chfast at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104151

Paweł Bylica  changed:

   What|Removed |Added

 CC||chfast at gmail dot com

--- Comment #18 from Paweł Bylica  ---
Not sure if this helps in any way, but this is a 256-bit variant:
https://godbolt.org/z/84fMTs1YP.

[Bug target/105354] __builtin_shuffle for alignr generates suboptimal code unless SSSE3 is enabled

[chfast at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105354

Paweł Bylica  changed:

   What|Removed |Added

 CC||chfast at gmail dot com

--- Comment #6 from Paweł Bylica  ---
Confirmed fixed. https://godbolt.org/z/rEqcMqKaz

[Bug ada/109798] Gnat Bug Detected

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #6 from Marc Poulhiès  ---
`alr -v build -- --keep-temp-files` should provide the expected commands.

You should have all the gcc invocations + be able to see the TMP files used
with `-gnatem` and `-gnatec`.

[Bug c++/80488] Erroneous error "lambda-expression in template argument"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80488

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:c3afdb8ba8f1839544c414f57e41a58c8fda5349

commit r14-708-gc3afdb8ba8f1839544c414f57e41a58c8fda5349
Author: Patrick Palka 
Date:   Thu May 11 10:04:25 2023 -0400

c++: converted lambda as template argument [PR83258, ...]

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17 (which r9-3836-g4be5c72cf3ea3e later
factored out into invalid_tparm_referent_p), but we need to also remove
the one in convert_nontype_argument_function for benefit of the first and
third testcase which we currently reject even in C++17/20 mode.

And in invalid_tparm_referent_p we're inadvertendly returning false for
the address of a lambda's static op() since it's DECL_ARTIFICIAL, which
currently causes us to reject the second (C++20) testcase.  But this
DECL_ARTIFICIAL check seems to be relevant only for VAR_DECL, and in fact
this code path was originally reachable only for VAR_DECL until recently
(r13-6970-gb5e38b1c166357).  So this patch restricts the check to VAR_DECL.

Co-authored-by: Jonathan Wakely 

PR c++/83258
PR c++/80488
PR c++/97700

gcc/cp/ChangeLog:

* pt.cc (convert_nontype_argument_function): Remove linkage
requirement for C++17 and later.
(invalid_tparm_referent_p) : Restrict
DECL_ARTIFICIAL rejection test to VAR_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
error for the template argument &B2:fn in C++17 mode.
* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
* g++.dg/cpp2a/nontype-class56.C: New test.
* g++.dg/template/function2.C: New test.

[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:c3afdb8ba8f1839544c414f57e41a58c8fda5349

commit r14-708-gc3afdb8ba8f1839544c414f57e41a58c8fda5349
Author: Patrick Palka 
Date:   Thu May 11 10:04:25 2023 -0400

c++: converted lambda as template argument [PR83258, ...]

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17 (which r9-3836-g4be5c72cf3ea3e later
factored out into invalid_tparm_referent_p), but we need to also remove
the one in convert_nontype_argument_function for benefit of the first and
third testcase which we currently reject even in C++17/20 mode.

And in invalid_tparm_referent_p we're inadvertendly returning false for
the address of a lambda's static op() since it's DECL_ARTIFICIAL, which
currently causes us to reject the second (C++20) testcase.  But this
DECL_ARTIFICIAL check seems to be relevant only for VAR_DECL, and in fact
this code path was originally reachable only for VAR_DECL until recently
(r13-6970-gb5e38b1c166357).  So this patch restricts the check to VAR_DECL.

Co-authored-by: Jonathan Wakely 

PR c++/83258
PR c++/80488
PR c++/97700

gcc/cp/ChangeLog:

* pt.cc (convert_nontype_argument_function): Remove linkage
requirement for C++17 and later.
(invalid_tparm_referent_p) : Restrict
DECL_ARTIFICIAL rejection test to VAR_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
error for the template argument &B2:fn in C++17 mode.
* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
* g++.dg/cpp2a/nontype-class56.C: New test.
* g++.dg/template/function2.C: New test.

[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:c3afdb8ba8f1839544c414f57e41a58c8fda5349

commit r14-708-gc3afdb8ba8f1839544c414f57e41a58c8fda5349
Author: Patrick Palka 
Date:   Thu May 11 10:04:25 2023 -0400

c++: converted lambda as template argument [PR83258, ...]

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17 (which r9-3836-g4be5c72cf3ea3e later
factored out into invalid_tparm_referent_p), but we need to also remove
the one in convert_nontype_argument_function for benefit of the first and
third testcase which we currently reject even in C++17/20 mode.

And in invalid_tparm_referent_p we're inadvertendly returning false for
the address of a lambda's static op() since it's DECL_ARTIFICIAL, which
currently causes us to reject the second (C++20) testcase.  But this
DECL_ARTIFICIAL check seems to be relevant only for VAR_DECL, and in fact
this code path was originally reachable only for VAR_DECL until recently
(r13-6970-gb5e38b1c166357).  So this patch restricts the check to VAR_DECL.

Co-authored-by: Jonathan Wakely 

PR c++/83258
PR c++/80488
PR c++/97700

gcc/cp/ChangeLog:

* pt.cc (convert_nontype_argument_function): Remove linkage
requirement for C++17 and later.
(invalid_tparm_referent_p) : Restrict
DECL_ARTIFICIAL rejection test to VAR_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
error for the template argument &B2:fn in C++17 mode.
* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
* g++.dg/cpp2a/nontype-class56.C: New test.
* g++.dg/template/function2.C: New test.

[Bug target/106887] ICE in extract_insn, at recog.cc:2791 since r13-2111-g6910cad55ffc330d

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887

--- Comment #4 from Martin Jambor  ---
I believe this has been fixed?

[Bug tree-optimization/109811] New: libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16

[aros at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811

Bug ID: 109811
   Summary: libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
  Target Milestone: ---

Created attachment 55051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55051&action=edit
Graphs

Check this:

https://www.phoronix.com/review/gcc13-clang16-raptorlake/3

[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #14 from Patrick Palka  ---
Fixed on trunk so far.

[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |13.2

--- Comment #8 from Patrick Palka  ---
Fixed on trunk so far.

[Bug tree-optimization/109812] New: GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

[aros at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

Bug ID: 109812
   Summary: GraphicsMagick resize is a lot slower in GCC 13.1 vs
Clang 16
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
  Target Milestone: ---

Check this:

https://www.phoronix.com/review/gcc13-clang16-raptorlake/3

[Bug tree-optimization/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

[aros at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

--- Comment #1 from Artem S. Tashkinov  ---
Created attachment 55052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55052&action=edit
Graphs

[Bug c++/80488] Erroneous error "lambda-expression in template argument"

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80488

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |13.2

--- Comment #4 from Patrick Palka  ---
Fixed on trunk so far.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[jbeulich at suse dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

--- Comment #22 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #21)
> oh really? I thought it would have to be implemented. If it's readily
> available, we can start making use of it right now.

Well, the general symbol part of it is there (with a few quirks, which I don't
think would matter here). This missing part for quoted symbols matching
register names was posted, see e.g.
https://sourceware.org/pipermail/binutils/2023-May/127318.html.

[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension

[law at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592

--- Comment #6 from Jeffrey A. Law  ---
I would still rather not introduce special cases for SUBREGs if we can avoid
it.  I think the question remains whether or not patching simplify-rtx's
canonicalize_shift is sufficient to fix this problem (perhaps with the
adjustment to fwprop as well).  If they are, then they would be much preferred
over the original patch which special cased SUBREGs.

[Bug target/109813] New: ICE in in extract_insn, at recog.cc:2791 on ARM with -mflip-thumb

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109813

Bug ID: 109813
   Summary: ICE in in extract_insn, at recog.cc:2791 on ARM with
-mflip-thumb
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

With a cross compiler (revision 475904f710c) configured with

/home/worker/buildworker/tiber-gcc-trunk-arm/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=arm-linux-gnueabi
--with-as=/usr/bin/arm-suse-linux-gnueabi-as

And the following testcase:


struct bfloat1 {
  __bf16 a;
};

struct bfloat1 h1(__bf16 a) {
  struct bfloat1 x;
  x.a = a;
  return x;
}

struct bfloat2 {
  __bf16 a;
  __bf16 b;
};

struct bfloat2 h2(__bf16 a, __bf16 b) {
  struct bfloat2 x;
  x.a = a;
  x.b = b;
  return x;
}


Running it as:

~/cross/bin/arm-linux-gnueabi-gcc /tmp/t.c -mflip-thumb -S

Results in:

/tmp/t.c: In function ‘h2’:
/tmp/t.c:22:1: error: unrecognizable insn:
   22 | }
  | ^
(insn 3 2 4 2 (set (mem/c:BF (reg/f:SI 115) [2 a+0 S2 A16])
(reg:BF 0 r0 [ a ])) "/tmp/t.c":17:39 -1
 (nil))
during RTL pass: vregs
/tmp/t.c:22:1: internal compiler error: in extract_insn, at recog.cc:2791
0x6673dd _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/rtl-error.cc:108
0x6673f9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/rtl-error.cc:116
0x666870 extract_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/recog.cc:2791
0x9164d0 instantiate_virtual_regs_in_insn
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/function.cc:1611
0x9164d0 instantiate_virtual_regs
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/function.cc:1984
0x9164d0 execute
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/function.cc:2033

[Bug debug/109805] LTO affecting -fdebug-prefix-map

[sergiodj at sergiodj dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

--- Comment #5 from Sergio Durigan Junior  ---
(In reply to Richard Biener from comment #4)
> It works for the actual source file translation units for me, it's just the
> LTRANS units that have a DW_AT_comp_dir that's not remapped.  It's actually
> difficult to do the right thing here and I think the correct thing to do if
> you don't like the "bogus" DW_AT_comp_dir is to actually specify
> -fdebug-prefix-map at link time.
>
> The issue it's difficult to do the right thing is because you have to
> consider
>
> gcc -c t1.c -flto -fdebug-prefix-map=`pwd`=/
> gcc -c t2.c -flto -fdebug-prefix-map=`pwd`=/
> gcc t1.o t2.o
>
> now, what DW_AT_comp_dir should the possibly single LTRANS CU use?

Thanks for the reply.

I understand the problem here.  But taking the vim package as an example, the
remapping was done to a specific directory, for all object files.

> One "fix" might be to emit multiple DWARF CUs for each LTRANS unit and thus
> keep the association to the original CUs 1:1 (I have some patches for this
> lying around for a few years).  But then we're still mixing CUs by means
> of inlining and cloning.
>
> Note the DW_AT_name of the LTRANS CUs is  (DWARF doesn't allow
> to omit it).  What's more "problematic" is that somehow the file list of
> the CU contains t.c - it might be worth figuring out how this gets there.
>
> A pragmatic fix could be to detect the case where all LTO inputs had the
> same -fdebug-prefix-map specified and carry that over to link time
> automatically in lto-wrapper (we are currently not streaming the various
> remapping flags).

That'd solve the problem I'm seeing, I believe.

> Can you clarify what the actual problem with the generated dwarf is?

If we take the vim package as an example (again), the problem I'm seeing is
that -fdebug-prefix-map is being used when compiling all .o files, but the
generated binary ends up with the old path in its directory table.  This
confuses debuginfod, which uses this information to determine where the source
files are located.  It's interesting to note that I also see the new path
listed in the DWARF, but for some reason debuginfod/GDB get confused about it.

I found yet another package that seems to be affected by this problem: samba. 
Curiously enough, there are other packages that don't seem to be affected, even
though they're also being compiled using LTO.

[Bug debug/109805] LTO affecting -fdebug-prefix-map

[sergiodj at sergiodj dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

--- Comment #6 from Sergio Durigan Junior  ---
As I mentioned in the description, a workaround for this would be to use
-fdebug-prefix-map in LDFLAGS as well.  I'm leaning towards implementing this
in Ubuntu until we figure out how to properly solve the issue.

[Bug c++/103807] Unable to make template class instance with default parameter of lambda::function

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103807

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0d0c467d216bf538faa7ceb75875e4efa73ae23f

commit r14-710-g0d0c467d216bf538faa7ceb75875e4efa73ae23f
Author: Patrick Palka 
Date:   Thu May 11 10:38:02 2023 -0400

c++: Add testcase for already fixed PR [PR103807]

We accept this testcase since r13-806-g221acd67ca50f8.

PR c++/103807

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ1.C: New test.

[Bug c++/103807] Unable to make template class instance with default parameter of lambda::function

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103807

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105652
   Target Milestone|--- |12.2
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
This is incidentally fixed for GCC 12.2+ by the fix for PR105652

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

--- Comment #23 from LIU Hao  ---
Changes to GCC should look like this I suspect (I didn't test this):

```
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index fbd33a6bfd1..de80c7a805f 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -14080,7 +14080,11 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
  if (flag_pic)
output_pic_addr_const (file, disp, 0);
  else if (GET_CODE (disp) == LABEL_REF)
-   output_asm_label (disp);
+   {
+ putc ('\"', file);
+ output_asm_label (disp);
+ putc ('\"', file);
+   }
  else if (CONST_INT_P (disp))
offset = disp;
  else
```

It's a bit strange that `output_asm_label` writes output via a global `FILE*`.

[Bug ada/109798] Gnat Bug Detected

[simon at pushface dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #7 from simon at pushface dot org ---
I *can* reproduce with

/opt/gcc-13.1.0-aarch64/bin/gcc -c -x ada -gnatA -Og -ffunction-sections
-fdata-sections -g -gnatwa -gnatw.X -gnatVa -gnaty3 -gnatya -gnatyA -gnatyB
-gnatyb -gnatyc -gnaty-d -gnatye -gnatyf -gnatyh -gnatyi -gnatyI -gnatyk
-gnatyl -gnatym -gnatyn -gnatyO -gnatyp -gnatyr -gnatyS -gnatyt -gnatyu -gnatyx
-gnatW8
-gnatec=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T/GNAT-TEMP-03.TMP
-gnatem=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T/GNAT-TEMP-04.TMP
/Users/simon/Developer/bugs/gcc/109798/alire/testing/src/testing.adb

where the -gnatec file contains

pragma Source_File_Name_Project   (Spec_File_Name  => "*.ads",   Casing
 => lowercase,   Dot_Replacement => "-");
pragma Source_File_Name_Project   (Body_File_Name  => "*.adb",   Casing
 => lowercase,   Dot_Replacement => "-");

and the -gnatem file contains

testing_config%s
testing_config.ads
/Users/simon/Developer/bugs/gcc/109798/alire/testing/config/testing_config.ads
testing%b
testing.adb
/Users/simon/Developer/bugs/gcc/109798/alire/testing/src/testing.adb


I think it’s the -gnatVa (I took out the -f*sections and all the style options
except a simple -gnaty).

[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
Close as FIXED.

The solution was to extend the linker plugin API to be able to tell GCC's
linker plugin whether a file is actually needed or is only passed to see
whether it contains by chance LTO symbols.

For the GCC patch that was applied to GCC mainline (GCC 14), see previous
comment (comment 8).

For the Binutils' patch, applied to mainline = Binutils 2.40.50,  see

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b21318bd2c29fcca8f99c1de7facdaa5cb2e66e2

[Bug ada/109798] Gnat Bug Detected

[aj at ianozi dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

--- Comment #8 from aj at ianozi dot com ---
(In reply to simon from comment #7)
> I think it’s the -gnatVa (I took out the -f*sections and all the style
> options except a simple -gnaty).

simon, you are correct; I independently went through compiling manually taking
out each flag one at a time.  This succeeds:
gcc -c -x ada testing.adb

But this fails:
gcc -c -x ada -gnatVa testing.adb

[Bug c++/109745] [13/14 Regression] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug ada/109798] Gnat Bug Detected

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Eric Botcazou  ---
> I think it’s the -gnatVa (I took out the -f*sections and all the style
> options except a simple -gnaty).

Indeed, the check generated by -gnatVa for the filter is out of context.

[Bug ada/109798] internal error on iterator filter with -gnatVa

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #10 from Eric Botcazou  ---
I'll have a look.

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-11
 Status|UNCONFIRMED |WAITING
 Target||x86_64-linux-gnu
 Ever confirmed|0   |1
  Component|tree-optimization   |target

--- Comment #2 from Andrew Pinski  ---
This bug report and the other ones are useless really. Please read
https://gcc.gnu.org/bugs/ and report a decent bug report.

[Bug libstdc++/109814] New: freestanding using cmath does not compile anymore

[lestofante88 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814

Bug ID: 109814
   Summary: freestanding using cmath does not compile anymore
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lestofante88 at gmail dot com
  Target Milestone: ---

My code stop compiling after updating from
arm-none-eabi-gcc (Arch Repository) 12.2.0
to
arm-none-eabi-gcc (Arch Repository) 13.1.0
(cant easily test any version in-between)

My understanding is that I am incorrectly using non-freestand library in
freestand mode (cmath in this case).
The problem with this is i am quite sure in embedded a lot of project does. 
This breakage, even if technically correct, may create a lot of issue in
embedded projects and may deserve a special handling, would that be good
communication of the breaking changes, or revert.

REPRODUCE:
- create a file test.cpp containing

#include 

- compile with 
arm-none-eabi-g++ --freestanding -c test.cpp

RESULT
On gcc 12.2.0: compilation successful
On gcc 13.1.0:

In file included from /usr/arm-none-eabi/include/c++/13.1.0/cmath:41,
 from test.cpp:1:
/usr/arm-none-eabi/include/c++/13.1.0/bits/requires_hosted.h:34:4: error:
#error "This header is not available in freestanding mode."
   34 | #  error "This header is not available in freestanding mode."
  |^
In file included from /usr/arm-none-eabi/include/c++/13.1.0/bits/specfun.h:47,
 from /usr/arm-none-eabi/include/c++/13.1.0/cmath:3716:
/usr/arm-none-eabi/include/c++/13.1.0/tr1/gamma.tcc: In function '_Tp
std::__detail::__log_gamma(_Tp)':
/usr/arm-none-eabi/include/c++/13.1.0/tr1/gamma.tcc:236:18: error:
'__throw_domain_error' is not a member of 'std'; did you mean
'__throw_runtime_error'?
  236 | std::__throw_domain_error(__N("Argument is nonpositive
integer "
  |  ^~~~
  |  __throw_runtime_error

[...] the error repeat for multiple functions.

[Bug target/109811] libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
A URL of an external site nor a plot is not a valid bug report.  We need
precisely how to reproduce the issue.  And you cannot assume the GCC developers
always have a Raptor Lake or they want to run the full Phoronix bench suite.

See https://gcc.gnu.org/bugs/.

That being said, maybe we can try `-fno-semantic-interposition` first?  It's
the default of clang, but not GCC.  And if a library is compiled with -fPIC
sometimes semantic interposition can cause a large performance loss.

[Bug c++/109815] New: AIX: Combining -static-libstdc++ and -pthread causes a TLS-related link error

[cameron.heide at betasystems dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109815

Bug ID: 109815
   Summary: AIX: Combining -static-libstdc++ and -pthread causes a
TLS-related link error
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cameron.heide at betasystems dot com
  Target Milestone: ---

With GCC 12.3 on AIX 7.1, trying to link even a trivial program with both the
'-static-libstdc++' and '-pthread' flags causes a link error:

test.cpp:
int main() { return 0; }

-bash-5.1$ g++12 -static-libstdc++ -pthread -o test test.cpp
ld: 0711-550 SEVERE ERROR: Object
/IMPORT/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc12.3/bin/../lib/gcc/powerpc-ibm-aix7.1.5.0/12.3.0/../../../pthread/libstdc++.a[libstdc++.so.6]
cannot be processed.
RLD at address 0x2b093 for section 7 (.dwinfo) references a
thread-local
variable, but a TLS-related reference type was not used.
collect2: error: ld returned 12 exit status

Either flag by itself works; it is just the combination of the two that fails.
This combination also worked with GCC 11.3 and only started failing with GCC
12, with the same GCC configuration flags. (I haven't had a chance to try GCC
13 yet.)

The GCC configuration flags are pretty basic:

-bash-5.1$ gcc12 -v
Using built-in specs.
COLLECT_GCC=gcc12
COLLECT_LTO_WRAPPER=/IMPORT/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc12.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.5.0/12.3.0/lto-wrapper
Target: powerpc-ibm-aix7.1.5.0
Configured with: ../gcc-12.3.0/configure
--prefix=/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc12.3
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=c,c++
--disable-nls --enable-threads --enable-bootstrap
--with-gmp=/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc-libs
--with-mpfr=/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc-libs
--with-mpc=/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc-libs
--with-isl=/home/zNTMAKE/betadev/arch/powerpc-aix7.1/gcc-libs
Thread model: aix
Supported LTO compression algorithms: zlib
gcc version 12.3.0 (GCC)

[Bug libstdc++/109814] freestanding using cmath does not compile anymore

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814

--- Comment #1 from Xi Ruoyao  ---
It seems a deliberate change.  See PR103626.

[Bug target/109815] AIX: Combining -static-libstdc++ and -pthread causes a TLS-related link error

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109815

--- Comment #1 from Andrew Pinski  ---
Seems like the debug information for TLS variables are not being written out
correctly and that is causing the link to fail.
I think GCC 12 moved to dwarf2 debug information for AIX which is why it shows
up in GCC 12+ only.

[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807

Uroš Bizjak  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #6 from Uroš Bizjak  ---
Created attachment 55053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55053&action=edit
Proposed patch.

Patch in testing.

[Bug ada/108125] Suggestion for improving bug-box / reporting on ICE

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108125

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Botcazou  ---
> The ice for Ada front end already provides this information. Even saying
> what to attachments are required.

Right, including the chain of instances for the source location.

> What more improvements are needed to compared to what clang does?
> Outputting internal state is hard to do really and confuse everyone.

I agree, and neither a backtrace nor a snapshot of data structures are
sufficient to diagnose the problem in most cases, the compiler is much too
complex for this.

[Bug ada/107536] [12/13/14 regression] Wrong 'not referenced' warning on renamed variable

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107536

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-11
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
The variable is macro-substituted and indeed fools the warning.

[Bug target/109811] libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16

[aros at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811

Artem S. Tashkinov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Artem S. Tashkinov  ---
According to the latest Phoronix test which can be easily downloaded, run and
reproduced, GCC 13.1 loses to Clang by a wide margin, in certain workloads it's
~30% (!) slower and I just wanted to alert its developers to a widening gap in
performance v Clang. I'm not a developer either, I'm simply no one.

My previous bug reports for performance regressions and deficiencies weren't
met with such ... words, so, I'm sorry I'm not in a mood of proving anything,
so I'll just go ahead and close it as useless, annoying and maybe even outright
invalid.

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

[aros at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

Artem S. Tashkinov  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Artem S. Tashkinov  ---
According to the latest Phoronix test which can be easily downloaded, run and
reproduced, GCC 13.1 loses to Clang by a wide margin, in certain workloads it's
~30% (!) slower and I just wanted to alert its developers to a widening gap in
performance v Clang. I'm not a developer either, I'm simply no one.

My previous bug reports for performance regressions and deficiencies weren't
met with such ... words, so, I'm sorry I'm not in a mood of proving anything,
so I'll just go ahead and close it as useless, annoying and maybe even outright
invalid.

[Bug libstdc++/109814] freestanding using cmath does not compile anymore

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814

--- Comment #2 from Jonathan Wakely  ---
It is a deliberate change, what we didn't consider is that people are using
hosted libstdc++ with -ffreestanding this way (because ... well, it doesn't
really make sense, but apparently it does).

[Bug libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-11
  Known to work||12.3.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|freestanding using cmath|[13/14 Regression]
   |does not compile anymore|freestanding using cmath
   ||does not compile anymore
  Known to fail||13.1.0, 14.0

--- Comment #3 from Jonathan Wakely  ---
The new behaviour is documented at
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++/manual/manual/using.html
and
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++/manual/manual/using_dynamic_or_shared.html
and I've just added something to the release notes about it:
https://gcc.gnu.org/gcc-13/changes.html#libstdcxx

But that doesn't help anybody affected by this.

Is it just  that you're using? We could pretty easily remove the
 include from that file, and then you could include
 with -ffreestanding. But if you have a truly freestanding environment
(i.e. no libm present) then nothing in  is actually going to work.

If people are using more than just  with -ffreestanding then things get
harder. Where do we draw the line of what is part of the freestanding subset of
libstdc++? Do we just let people include everything, and it's their fault if
they create dependencies on malloc, __cxa_throw, RTTI etc.? That doesn't seem
nice.

[Bug libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814

--- Comment #4 from Jonathan Wakely  ---
(In reply to lesto fante from comment #0)
> My code stop compiling after updating from
> arm-none-eabi-gcc (Arch Repository) 12.2.0
> to
> arm-none-eabi-gcc (Arch Repository) 13.1.0
> (cant easily test any version in-between)

Please add the output of 'gcc -v' (as requested by the bug reporting docs), the
info above doesn't tell us much.

Presumably you're using newlib to provide the libm functions that 
declares?

[Bug ada/108610] pure library procedures with limited parameters miscategorized

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108610

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-05-11
 CC||ebotcazou at gcc dot gnu.org
Summary|Pure library procedures |pure library procedures
   |with limited parameters |with limited parameters
   |miscategorized  |miscategorized
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Your analysis is correct, see Sem_Util.Check_Function_With_Address_Parameter.

[Bug ada/107392] excessive compilation time for decimal_literal - that should be rejected as type-error

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107392

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2023-05-11
   Severity|normal  |minor

--- Comment #1 from Eric Botcazou  ---
A guard against ludicrous inputs is indeed missing here.

[Bug ada/106673] compilation bug on abstract primitive pre'class aspect using for all construct on a string parameter

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-11

--- Comment #2 from Eric Botcazou  ---
reproducer-main.adb:3:06: error: file "helpers.ads" not found