[Bug sanitizer/115225] signed integer overflow check missing with optimization

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |sanitizer
Summary|[11/12/13/14 Regression]|signed integer overflow
   |signed integer overflow |check missing with
   |check missing with  |optimization
   |optimization|
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Yes, I think this is fully expected.

[Bug c++/115223] [15 regression] ICE when building KDE kontrast with LTO (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’) since r15-779-g3c98d06a9016a0

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Keywords||ice-on-valid-code
   Target Milestone|--- |15.0

--- Comment #3 from Richard Biener  ---
Note -flto is only required because that triggers type verification.

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368) since r15-80-g0ade358cd72ffa

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Priority|P3  |P1

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa (since r15-815-g5b9b3bae33cae7?)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Mine.  Looks similar to the libgo issue I actually fixed...

[Bug tree-optimization/115214] tree-ssa-pre.c(ICE in find_or_generate_expression, at tree-ssa-pre.c:2780)

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-27

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

[Bug c++/115240] [alias] Does we assume the math function have pure attribute ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
DEF_C99_C90RES_BUILTIN (BUILT_IN_EXPF, "expf", BT_FN_FLOAT_FLOAT,
ATTR_MATHFN_FPROUNDING_ERRNO)


/* Define an attribute list for math functions that are normally
   "impure" because some of them may write into global memory for
   `errno'.  If !flag_errno_math, we can possibly use "pure" or
   "const" depending on whether we care about FP rounding.  */
#undef ATTR_MATHFN_FPROUNDING_ERRNO
#define ATTR_MATHFN_FPROUNDING_ERRNO (flag_errno_math ? \
(flag_rounding_math ? ATTR_ERRNOPURE_NOTHROW_LEAF_LIST \
 : ATTR_ERRNOCONST_NOTHROW_LEAF_LIST) : ATTR_MATHFN_FPROUNDING)


//   DEF_ATTR_TREE_LIST (ENUM, PURPOSE, VALUE, CHAIN)

DEF_ATTR_TREE_LIST (ATTR_ERRNOCONST_NOTHROW_LEAF_LIST, ATTR_FNSPEC,\
ATTR_LIST_STRERRNOC, ATTR_NOTHROW_LEAF_LIST)
// [[gnu::fn spec(".C")]
DEF_ATTR_TREE_LIST (ATTR_ERRNOPURE_NOTHROW_LEAF_LIST, ATTR_FNSPEC,\
ATTR_LIST_STRERRNOP, ATTR_NOTHROW_LEAF_LIST)


DEF_ATTR_TREE_LIST (ATTR_NOTHROW_LEAF_LIST, ATTR_LEAF, ATTR_NULL,
ATTR_NOTHROW_LIST) // [[gnu::leaf,gnu::nothrow]]

DEF_ATTR_FOR_STRING (STRERRNOC, ".C")
DEF_ATTR_IDENT (ATTR_FNSPEC, "fn spec")


by default it selects: ATTR_ERRNOCONST_NOTHROW_LEAF_LIST

Note the "fn spec" here is a special internal definition which is defined as:
   character 0  specifies properties of return values as follows:
...
 '.'specifies that nothing is known.
   character 1  specifies additional function properties
...
 'c' or 'C' specifies that function is const except for described side
effects.
...
   The uppercase letter in addition specifies that function clobbers errno.

GCC knows that exp only can clobbers errno here and num can't be errno so it
treats it as a const function in this case.

[Bug c/115241] New: header-tools scripts not compatible to python3

[sadineniharish8446 at gmail dot com via Gcc-bugs]

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

Bug ID: 115241
   Summary: header-tools scripts not compatible to python3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sadineniharish8446 at gmail dot com
  Target Milestone: ---

The scripts in contrib/header-tools/ are breaks with python3.
These scripts were for python2 and we did update it for python3 and sent the
patches to gcc upstream.
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg337175.html

We did not get any response over there about the patch.

Can you let us know that our patches are ok OR gcc has any plan to upgrade
these scripts for python3 compatibility?

[Bug c++/115240] New: [alias] Does we assume the math function have pure attribute ?

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 115240
   Summary: [alias] Does we assume the math function have pure
attribute ?
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* test: https://gcc.godbolt.org/z/5YbezdW89
```
float foo (float num[], float r2inv, int n) {
   float sum = 0.0;
   for (int i=0; i < 1000; i++) {
   float a = num[i];
   // const float r = a / std::sqrt (r2inv);
   const float expm2 = std::exp (a);

   float tmp = expm2 * num[i];
   sum += tmp * tmp;
   }

return sum;
}
```

* gcc's assemble reuse the num[i], so it assume the function math function expf
doesn't clobber the num[i], does we assume the function expf have the pure
atrribute ?
```
.L2:
ldr s15, [x19], 4
fmovs0, s15  ; backup the num[i], and reuse it after the call expf
bl  expf
fmuls15, s15, s0
fmadd   s14, s15, s15, s14
cmp x19, x20
bne .L2
```

[Bug c++/115239] [14/15 Regression] ICE: Segmentation fault with ambiguous function call in some cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58294|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 58295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58295&action=edit
Reduced further, removed one argument

[Bug c++/115239] [14/15 Regression] ICE: Segmentation fault with ambiguous function call from static_assert in some cases

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 58294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58294&action=edit
Reduced further

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[macro at orcam dot me.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 79646, which changed state.

Bug 79646 Summary: Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/79646] Typos in vax.opt

[macro at orcam dot me.uk via Gcc-bugs]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||macro at orcam dot me.uk
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Maciej W. Rozycki  ---
Fixed as per the commit message.  Closing bug.

[Bug c++/115239] [14/15 Regression] ICE: Segmentation fault with ambiguous function call from static_assert in some cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: internal compiler  |[14/15 Regression] ICE:
   |error: Segmentation fault   |Segmentation fault with
   ||ambiguous function call
   ||from static_assert in some
   ||cases
   Target Milestone|--- |14.2

[Bug c++/115239] ICE: internal compiler error: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-27
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
[apinski@xeond2 gcc]$ ./cc1plus t.cc
 constexpr bool foo(const char*, char*, long int) constexpr bool foo(const
char*, char*, unsigned int) constexpr bool foo(char, char, long int) constexpr
bool foo(char, char, unsigned int)
t.cc: At global scope:
t.cc:7:18: internal compiler error: Segmentation fault
7 | static_assert(foo((char *)nullptr, nullptr, 0));
  |   ~~~^
0x134bdbf crash_signal
/home/apinski/src/upstream-gcc-match/gcc/gcc/toplev.cc:319
0xa49a4e compare_ics
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/call.cc:12124
0xa5736a joust
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/call.cc:12958
0xa58ee8 tourney
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/call.cc:13476
0xa59068 perform_overload_resolution
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/call.cc:5006
0xa5db12 build_new_function_call(tree_node*, vec**, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/call.cc:5098
0xcadf7d finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/semantics.cc:3136
0xc0c2bb cp_parser_postfix_expression
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:8191
0xbe74f0 cp_parser_binary_expression
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:10411
0xbe82b4 cp_parser_assignment_expression
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:10755
0xbe93fd cp_parser_constant_expression
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:11045
0xbeb84b cp_parser_static_assert
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:17096
0xc32672 cp_parser_declaration
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:15706
0xc336fa cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:15727
0xc336fa cp_parser_translation_unit
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:5297
0xc336fa c_parse_file()
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:51518
0xd81961 c_common_parse_file()
/home/apinski/src/upstream-gcc-match/gcc/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/115239] New: ICE: internal compiler error: Segmentation fault

[markus at oberhumer dot com via Gcc-bugs]

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

Bug ID: 115239
   Summary: ICE: internal compiler error: Segmentation fault
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at oberhumer dot com
  Target Milestone: ---

Link at Compiler Explorer:

  https://godbolt.org/z/b1oW566E5

I stumbled on this while compiling some invalid code during refactoring.

Test case has been reduced by cvise.

Discovered using gcc-14.1.1-4.fc40.x86_64. Might be a regression - gcc-13 does
not crash.

Acutal code: ```
constexpr bool foo(const char *, char *, long) { return true; }
constexpr bool foo(const char *, char *, unsigned) { return true; }
constexpr bool foo(char, char, long) { return true; }
constexpr bool foo(char, char, unsigned) { return true; }

static_assert(foo((char *)nullptr, nullptr, 0));
```

[Bug tree-optimization/115238] bitwise_inverted_equal_p should handle uniform_integer_cst_p

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/652
   ||768.html
   Keywords||patch

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652768.html

[Bug target/79646] Typos in vax.opt

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Maciej W. Rozycki :

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

commit r15-843-ga7f6543f21303583356fd2d2d1805bffbecc1bc5
Author: Abe Skolnik 
Date:   Mon May 27 05:07:32 2024 +0100

vax: Fix descriptions of the FP format options [PR79646]

Replace "Target" with "Generate" consistently and place a hyphen in
"double-precision" as this is used as an adjective here.

gcc/ChangeLog:

PR target/79646
* config/vax/vax.opt (md, md-float, mg, mg-float): Correct
descriptions.

[Bug c++/110137] implement clang -fassume-sane-operator-new

[user202729 at protonmail dot com via Gcc-bugs]

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

user202729  changed:

   What|Removed |Added

 CC||user202729 at protonmail dot 
com

--- Comment #6 from user202729  ---
Created attachment 58293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58293&action=edit
Proposed implementation.

I've implement it. (Attached patch) It would be helpful if someone can review
it.

Some notes:

1. Clang's documentation says the effect of `-fassume-sane-operator-new` is to
assume no-alias, but it is pointed out that Clang also assumes no-side-effect.
So I explicitly state that in the documentation.
2. The original intent is to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035 .

While this patch alone is insufficient to fix that (as explained in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035#c17 ), it would be
sufficient to improve the performance of the following (to only load from
global memory once):

```
int a;

// Prevent optimization
void sink(void *m) {
asm volatile("" : : "g"(m) : "memory");
}

int f(){
int x=a;
float* z=new float;
int y=a;
int result=x+y;
sink(z);
return result;
}
```

3. I'm not sure which additional optimizations can be done if we know something
is pure, but this would improve that one case. Other cases can be added later
on.

[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #13 from Hongtao Liu  ---
Fixed.

[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Levy Hsu :

https://gcc.gnu.org/g:0022064649d0ec40e97df24279c48842e278fedc

commit r15-841-g0022064649d0ec40e97df24279c48842e278fedc
Author: Levy Hsu 
Date:   Tue May 21 12:47:21 2024 +0930

x86: Fix Logical Shift Issue in expand_vec_perm_psrlw_psllw_por [PR115146]

Replaced arithmetic shifts with logical shifts in
expand_vec_perm_psrlw_psllw_por to avoid sign bit extension issues. Also
corrected gen_vlshrv8hi3 to gen_lshrv8hi3 and gen_vashlv8hi3 to gen_ashlv8hi3.

Co-authored-by: H.J. Lu 

gcc/ChangeLog:

PR target/115146
* config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por):
Replace arithmatic shift
gen_ashrv4hi3 with logic shift gen_lshrv4hi3.
Replace gen_vlshrv8hi3 with gen_lshrv8hi3 and gen_vashlv8hi3 with
gen_ashlv8hi3.

gcc/testsuite/ChangeLog:

PR target/115146
* g++.target/i386/pr107563-a.C: Append '-mno-sse3' to compile
option
to avoid test failure on hosts with SSE3 support.
* g++.target/i386/pr107563-b.C: Append '-mno-sse3' to compile
option
to avoid test failure on hosts with SSE3 support.
* gcc.target/i386/pr115146.c: New test.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #12 from YunQiang Su  ---
You are right: the decision to use $6 is too late.
So let's force to use it in expand pass.

```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..84ff29cd62b 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -3318,7 +3318,11 @@ mips16_gp_pseudo_reg (void)
 {
   rtx_insn *scan;

-  cfun->machine->mips16_gp_pseudo_rtx = gen_reg_rtx (Pmode);
+  if (TARGET_USE_GOT)
+   cfun->machine->mips16_gp_pseudo_rtx
+   = gen_rtx_REG (Pmode, POST_CALL_TMP_REG);
+  else
+   cfun->machine->mips16_gp_pseudo_rtx = gen_reg_rtx (Pmode);

   push_topmost_sequence ();


```

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #11 from YunQiang Su  ---
(In reply to YunQiang Su from comment #8)
> Ohh, In fact we should use $28 if TARGET_USE_GOT.
> 
> Can you help to test this patch?
> 
> ```
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> index b63d40a357b..fe8641d3916 100644
> --- a/gcc/config/mips/mips.cc
> +++ b/gcc/config/mips/mips.cc
> @@ -3342,7 +3342,7 @@ mips16_gp_pseudo_reg (void)
>  rtx
>  mips_pic_base_register (rtx temp)
>  {
> -  if (MIPS16_GP_LOADS ||!TARGET_MIPS16)
> +  if (MIPS16_GP_LOADS || TARGET_USE_GOT ||!TARGET_MIPS16)
>  return pic_offset_table_rtx;
>  
>if (currently_expanding_to_rtl)
> ```

This patch can trigger some ICE

[Bug tree-optimization/115224] (a ^ 1) & (a ^ ~1) is not optimized to 0 at the gimplelevel

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/652
   ||752.html
   Keywords||patch

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652752.html

[Bug target/115161] highway-1.0.7 miscompilation of _mm_cvttps_epi32(): invalid result assumed

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

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

--- Comment #25 from Hongtao Liu  ---
(In reply to Jakub Jelinek from comment #17)
> I don't think the cost of using UNSPEC would be significant if the backend
> tried to constant fold more target builtins.  Anyway, with the proposed
> changes perhaps you could keep using FIX/UNSIGNED_FIX for flag_trapping_math
> case even for the intrinsics and use UNSPECs only for !flag_trapping_math.

Ok, we'll refactor all {V,}CVTT* instructions with UNSPEC instead of
FIX/UNSIGNED_FIX.

[Bug tree-optimization/115238] bitwise_inverted_equal_p should handle uniform_integer_cst_p

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-26
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
.

[Bug tree-optimization/115238] New: bitwise_inverted_equal_p should handle uniform_integer_cst_p

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

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

Bug ID: 115238
   Summary: bitwise_inverted_equal_p should handle
uniform_integer_cst_p
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#define vector8 __attribute__((vector_size(8)))

vector8 int f(int a, vector8 int b)
{
a = 1;
return a | ((~a) ^ b);
}

vector8 int f1(int a, vector8 int b)
{
a = 1;
return a | (~b);
}
```

These 2 should produce the same code but don't currently on some targets.
bitwise_inverted_equal_p needs to be improved to use uniform_integer_cst_p
instead of INTEGER_CST directly.

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre and volatile pointers since r15-579-ga9251ab3c91c8c

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-26
 Ever confirmed|0   |1

[Bug c/115237] New: -Wsuggest-attribute=pure false positive for obviously non-pure function

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 115237
   Summary: -Wsuggest-attribute=pure false positive for obviously
non-pure function
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

This is gcc (GCC) 14.1.1 20240507 (Red Hat 14.1.1-1) on x86-64. I ran into this
problem when compiling tzcode; this is a stripped-down version of the problem.
Compile the following with 'gcc -O2 -Wsuggest-attribute=pure -S t.i':

  _Noreturn void error ();

  int
  unite (int a, int b)
  {
int sum;
if (a & b)
  error ();
return a | b;
  }

GCC complains:

  t.i: In function ‘unite’:
  t.i:4:3: warning: function might be candidate for attribute ‘pure’ if it is
known to return normally [-Wsuggest-attribute=pure]
  4 |   unite (int a, int b)
|   ^

However, an important goal of the function is to report an error and exit if
a&b is nonzero. The function must not be pure, because pure functions must
return; they cannot exit or longjmp out or whatever. So this warning is clearly
incorrect.

I suggest suppressing the warning if the function that might call a noreturn
function.

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre and volatile pointers since r15-579-ga9251ab3c91c8c

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[15 regression] Wrong code  |[15 regression] Wrong code
   |at -O1 and above with   |at -O1 and above with
   |-fno-tree-fre and volatile  |-fno-tree-fre and volatile
   |pointers|pointers since
   ||r15-579-ga9251ab3c91c8c

--- Comment #2 from Sam James  ---
r15-579-ga9251ab3c91c8c

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre and volatile pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 regression] Wrong code  |[15 regression] Wrong code
   |at -O1 and above with   |at -O1 and above with
   |-fno-tree-fre on|-fno-tree-fre and volatile
   |x86_64-linux-gnu|pointers
Version|unknown |15.0
   Target Milestone|--- |15.0

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

Summary|wrong code at -O1 and above |[15 regression] Wrong code
   |with -fno-tree-fre on   |at -O1 and above with
   |x86_64-linux-gnu|-fno-tree-fre on
   ||x86_64-linux-gnu
 CC||sjames at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #1 from Sam James  ---
--- a/foo.c.051t.sccopy1
+++ b/foo.c.051t.sccopy1
@@ -1,6 +1,8 @@

;; Function main (main, funcdef_no=0, decl_uid=2770, cgraph_uid=1,
symbol_order=2)

{+Removing basic block 4+}
{+Merging blocks 2 and 3+}
int main ()
{
  int * volatile * d;
@@ -16,20 +18,9 @@ int main ()
  MEM[(int * volatile *)&c] ={v} b.0_1;
  # DEBUG BEGIN_STMT
  c.1_2 = c;
[-  if (c.1_2 != &a)-]
[-goto ; [INV]-]
[-  else-]
[-goto ; [INV]-]

[-   :-]
  # DEBUG BEGIN_STMT
  __builtin_abort ();

[-   :-]
[-  # DEBUG BEGIN_STMT-]
[-  c ={v} {CLOBBER(eos)};-]
[-  return 0;-]

}

[Bug tree-optimization/115236] New: wrong code at -O1 and above with -fno-tree-fre on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 115236
   Summary: wrong code at -O1 and above with -fno-tree-fre on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier. 

Compiler Explorer: https://godbolt.org/z/xhY65cevr

[533] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240526 (experimental) (GCC) 
[534] % 
[534] % gcctk -O1 small.c; ./a.out
[535] % 
[535] % gcctk -O1 -fno-tree-fre small.c
[536] % ./a.out
Aborted
[537] % cat small.c
int a, *b = &a;
int main() {
  int *c, *volatile *d = &c;
  *d = b;
  if (c != &a)
__builtin_abort();
  return 0;
}

[Bug middle-end/93487] Missed tail-call optimizations

[pskocik at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Petr Skocik  ---
Another case of a missed tailcall which might warrant a separate mention:

struct big{ long _[10]; };
void takePtr(void *);
void takeBigAndPassItsAddress(struct big X){ takePtr(&X); }

This should ideally compile to just `lea 8(%rsp), %rdi; jmp takePtr;`.

The compiler might be tempted here to use the taking of an address of a local
here
as a reason not to tail call, and clang misses this optimization too, probably
for this reason,
but tailcalling here is fine as the particular local here isn't
allocated by the function but rather the callee during the call.

Icc does do this optimization: https://godbolt.org/z/a6coTzPjz

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #15)
> Quick update: 
> 
> Software stack and model build with gnu/13.3.0 was clear from all previous
> issues! So issue with the gnu/13.x.0 compiler could be considered as fixed,
> thank you so much for the help here. 

Good!

> Build with gnu/14.1.0 generated more ICEs, however. 
> FYI, the compiler errors looked as following:
> 
> -
> ...register_variable_attribute.inc:56:60:
> 
> internal compiler error: in gfc_walk_array_ref, at
> fortran/trans-array.cc:11870
> 0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
> ../../gcc/fortran/trans-array.cc:11870
> 0x8d5f90 gfc_walk_expr(gfc_expr*)
> ../../gcc/fortran/trans-array.cc:12232
> 0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
> ../../gcc/fortran/trans-array.cc:11870
> 0x8d5f90 gfc_walk_expr(gfc_expr*)
> ../../gcc/fortran/trans-array.cc:12232
> 0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
> gfc_expr*, vec*)
> ../../gcc/fortran/trans-expr.cc:6578
> 0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
> gfc_expr*, vec*)
> ../../gcc/fortran/trans-expr.cc:6578
> 0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
> ../../gcc/fortran/trans-expr.cc:9979
> 0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
> gfc_expr*, vec*)
> ../../gcc/fortran/trans-expr.cc:6756
> 0x90f4b8 gfc_trans_assignment_1
> ../../gcc/fortran/trans-expr.cc:12287
> 0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
> ../../gcc/fortran/trans-expr.cc:9979
> 0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
> gfc_expr*, vec*)
> ../../gcc/fortran/trans-expr.cc:6756
> 0x90f4b8 gfc_trans_assignment_1
> ../../gcc/fortran/trans-expr.cc:12287
> 0x8c3897 trans_code
> ...
> ... (more diagnostic prints)
> ...
> 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.
> 0x8657ad translate_all_program_units
> ../../gcc/fortran/parse.cc:7086
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> 

Well, that is a different traceback and likely a different error.

Can you provide a reduced reproducer?

As you write, the ICE does not occur in 13.3 but is new at 14.1, so having
the new bug in a different PR might make it easier to track than keeping
it here.

[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #6 from Paul Eggert  ---
(In reply to Jan Hubicka from comment #5)
> yes, however both const and pure attributes allows compiler to also
> remove the call if return value is unused.  So here finiteness matters.
Thanks for mentioning that. I now see that there are other differences between
const/pure and unsequenced/reproducible: see N2956
, which says
that the GCC notions are stricter than the corresponding C23 notions. N2956
doesn't mention finiteness as one of the strictness differences, though, I
guess because the C23 standardizers didn't notice that part of the GCC
documentation.

So my idea that "[[reproducible]] and __attribute__((pure)) are supposed to be
the same thing" is incorrect. Similarly, [[unsequenced]] and
__attribute__((const) are not the same thing. Oh well. We may need to change
Gnulib because of these discrepancies.

>> I agree with Bruno's main point that none of this stuff should matter for
>> static functions. --suggest-attribute=* warnings are useless chatter for
>> static functions.
> It helps the compiler to solve the halting problem.
This isn't a halting-problem situation. If GCC cannot deduce that a static
function halts, and if no calls to that function discard the return value (so
the optimization you mentioned can't apply), then suggesting to the developer
to add __attribute__((pure)) merely wastes developers' time, and developers
either disable the warning or ignore it, neither of which is good. So Bruno's
suggestion of suppressing the false positive for his test case still seems to
be a good one.

[Bug debug/115235] Non-standard .debug_addr section

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
The implementation of -gsplit-dwarf deals specifically with DWARF 5 and later.

[Bug debug/115235] Non-standard .debug_addr section

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
Ope, my bad, it appears the section is generated properly with -gsplit-dwarf
-gdwarf-5.

[Bug debug/115235] New: Non-standard .debug_addr section

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 115235
   Summary: Non-standard .debug_addr section
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

I'm trying to use -gsplit-dwarf however I'm running into a lot of tooling
problems because as far as I can tell the .debug_addr is being generated in a
different format than specified by the dwarf 5 standard. It seems the format
described in https://gcc.gnu.org/wiki/DebugFission is being used. This is
causing problems with tooling expecting the dwarf 5 format for the section.

Even with -gsplit-dwarf -gdwarf-5 a non-standard .debug_addr section is
generated.

An example hexdump:

Hex dump of section '.debug_addr':
  0x 8213  aa13  
  0x0010 c116  2912  )...
  0x0020 9015  eb12  
  0x0030 3313  5913  3...Y...
  0x0040 ba15  1915  
  0x0050 0416  4116  A...
  0x0060 bf12  9a13  
  0x0070 0717  5d14  ]...
  0x0080 d416  ca13  
  0x0090 2617  2614  &...&...
  0x00a0 8014  6217  b...
  0x00b0 e214  3415  4...
  0x00c0 d214  4615  F...
  0x00d0 9417  7e16  ~...
  0x00e0 c117  e817  

Is there any way to get gcc to emit the section as described by the standard?
Is there any way to tell from other debug information that a non-standard
encoding should be expected here?

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #5 from huangqinjin at gmail dot com ---
It is currently impossible to use `export using` style like libc++ to implement
`import std`, for example
https://en.cppreference.com/w/cpp/utility/expected/unexpected.

[Bug lto/115234] New: Wnull-dereference false-positive on address of local variable

[cgzones at googlemail dot com via Gcc-bugs]

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

Bug ID: 115234
   Summary: Wnull-dereference false-positive on address of local
variable
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cgzones at googlemail dot com
  Target Milestone: ---

$ gcc-14 --version
gcc-14 (Debian 14.1.0-1) 14.1.0

Reproducer:

git clone --depth 1 --branch 3.7-rc1
https://github.com/seLinuxProject/selinux.git

cd selinux/

make CC='gcc-14 -flto=auto' DESTDIR=/tmp/selinux_destdir SUBDIRS='libsepol
checkpolicy' -j"$(nproc)" install

```
In function ‘sepol_context_from_string’,
inlined from ‘context_from_string’ at ../libsepol/src/context.c:315:6,
inlined from ‘sepol_context_to_sid’ at ../libsepol/src/services.c:1300:6:
../libsepol/src/context_record.c:206:22: error: potential null pointer
dereference [-Werror=null-dereference]
  206 | *con = NULL;
  |  ^
```

context_from_string():

298: sepol_context_t *ctx_record = NULL;
315: if (sepol_context_from_string(handle, con_cpy, &ctx_record) < 0)

sepol_context_from_string():

198: int sepol_context_from_string(sepol_handle_t * handle,
199:   const char *str, sepol_context_t ** con)
206: *con = NULL;

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

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

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

Haochen Jiang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Haochen Jiang  ---
It also solved the issue for me. Thx!

[Bug other/115189] libiberty introduces UNC paths waking up binutils bug

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

--- Comment #4 from Bill Zissimopoulos  ---
The lrealpath function on Windows uses the GetFinalPathNameByHandleW function
with the VOLUME_NAME_DOS flag.

I do not currently have access to a Windows system with dev tools, but my
recollection is that the VOLUME_NAME_DOS flag should be sufficient to correctly
find the DOS drive in most cases including network drives. Unfortunately
GetFinalPathNameByHandleW does not work with drives created with the
DefineDosDeviceW API (e.g. drives created using the SUBST utility).

How are people who stumble on this bug create their drives?

A more robust alternative to GetFinalPathNameByHandleW/VOLUME_NAME_DOS may be
the following:

- Use GetFinalPathNameByHandleW with VOLUME_NAME_NORMALIZED|VOLUME_NAME_NT.

- Enumerate all available drives for the current process using
GetLogicalDrives.

- For each logical drive use QueryDosDeviceW to see if the returned prefix
matches the NT namespace prefix returned by the earlier call to
GetFinalPathNameByHandleW.

For an example of this approach see the chromium code here:

https://chromium.googlesource.com/chromium/src/base/+/master/files/file_util_win.cc#828

(See functions NormalizeFilePath and DevicePathToDriveLetterPath.)

[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #5 from Jan Hubicka  ---
> (In reply to Jan Hubicka from comment #2)
> > The reason why gcc warns is that it is unable to prove that the function is
> > always finite.
> 
> I don't see why finiteness matters. If a pure function returns the first time
> it's called, and if there's no change to visible state after that, it should
> return the second time with the same value. And if the pure function didn't
> return the first time evaluation won't even get to the second time. So common
> subexpression elimination (which is the point of 'pure') will work even if a
> pure function does not return.

yes, however both const and pure attributes allows compiler to also
remove the call if return value is unused.  So here finiteness matters.
> 
> C23 has standardized this stuff with the [[reproducible]] attribute, and as 
> far
> as I can see (the wording is admittedly murky) C23 does not impose a 
> finiteness
> constraint on reproducible functions. If my reading of C23 is correct, GCC
> should not impose finiteness constraints on reproducible functions when it 
> gets
> around to implementing [[reproducible]], and if [[reproducible]] and
> __attribute__((pure)) are supposed to be the same thing then GCC should drop
> the  finiteness constraint on pure functions as well.

Interesting, I did not notice that. These notions are not the same.

However ipa-mod-ref internally knows if function has side effects (i.e.
can be infinite) and if it is reproducible (i.e. will do same thing when
called again) and we could use this for redundancy elimination if that
pass is extended to remove redundant calls.

So I guess adding reproducible attribute in addition to pure and const
makes sense.
> 
> 
> I agree with Bruno's main point that none of this stuff should matter for
> static functions. --suggest-attribute=* warnings are useless chatter for 
> static
> functions.
It helps the compiler to solve the halting problem.

[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652669.html

[Bug c++/115233] constexpr RVO result is not determined as constant epression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/115233] constexpr RVO result is not determined as constant epression

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

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

--- Comment #1 from Andrew Pinski  ---
It also compiles fine with MSVC.

[Bug c/111654] Introduce clang's invalid-noreturn warning

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Julian Waters  ---
I recently stumbled upon -Wno-attributes, which can apparently take a parameter
like -Wno-attributes=vendor:: and I think that's appropriate for this
particular situation. How does -Wno-invalid-noreturn,
-Wno-invalid-noreturn=explicit and -Wno-invalid-noreturn=implicit sound? But I
have no idea how to implement this type of option within gcc, any advice?

[Bug c++/115233] New: constexpr RVO result is not determined as constant epression

[konstantin.vladimirov at gmail dot com via Gcc-bugs]

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

Bug ID: 115233
   Summary: constexpr RVO result is not determined as constant
epression
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

Consider I have this type:

---

struct Type {
  int a;
  const int& b;
  constexpr Type() : a(1), b(a) {}
};

constexpr Type t1;
constexpr int c11 = t1.a;
constexpr int c12 = t1.b;

---

c11 and c12 are fine for both gcc and clang

Now lets introduce constexpr function which is subject to RVO:

constexpr auto get() {
  return Type();
}

Now try this:

constexpr Type t2 = get();
constexpr int c2 = t2.a;

This code compiles fine with clang but not with gcc.

Live example on godbolt: https://godbolt.org/z/zf3YvebbG

According to [expr.const] and [class.copy.elision] result of constexpr function
is necessary RVO and is contant expression, so t2 construction is fine and t2.a
is constant expression as well.

[Bug tree-optimization/115232] [14/15 regression] ICE during GIMPLE pass during waccess

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-26
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/115232] [14/15 regression] ICE during GIMPLE pass during waccess

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
   Keywords||ice-on-valid-code
Summary|[14 regression] ICE during  |[14/15 regression] ICE
   |GIMPLE pass |during GIMPLE pass during
   ||waccess
  Component|c++ |tree-optimization

[Bug c++/115232] [14 regression] ICE during GIMPLE pass

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 58292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58292&action=edit
Slightly reduced

[Bug c++/115232] New: [14 regression] ICE during GIMPLE pass

[vopl at bk dot ru via Gcc-bugs]

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

Bug ID: 115232
   Summary: [14 regression] ICE during GIMPLE pass
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vopl at bk dot ru
  Target Milestone: ---

$ cat ./ice-14.cpp && echo EOF
// g++-14 -std=c++20 -v -c ./ice-14.cpp

/0/1/2/3/4/5/6/7
template
struct Outer
{
Outer();

template 
static constexpr bool staticTemplatedConstant = true;

template  void method() requires staticTemplatedConstant
{
struct Inner
{
static void* operator new(unsigned long /*sz*/) {return new char;}
static void operator delete(void*) {}

Outer _outerInstance;

};

new Inner;
}

};

/0/1/2/3/4/5/6/7
void f()
{
Outer{}.method();
}
EOF

$ g++-14 -std=c++20 -v -c ./ice-14.cpp
Using built-in specs.
COLLECT_GCC=g++-14
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/gcc-14-20240518/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
14.1.1_p20240518 p1' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--enable-systemtap --disable-valgrind-annotations --enable-vtable-verify
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-host-pie --enable-host-bind-now --disable-default-ssp
--disable-fixincludes --with-build-config='bootstrap-lto bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.1 20240516 (Gentoo 14.1.1_p20240518 p1) 
COLLECT_GCC_OPTIONS='-std=c++20' '-v' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/14/cc1plus -quiet -v -D_GNU_SOURCE
./ice-14.cpp -quiet -dumpbase ice-14.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -std=c++20 -version -fcf-protection -o /tmp/cc0hiSMi.s
GNU C++20 (Gentoo 14.1.1_p20240518 p1) version 14.1.1 20240516
(x86_64-pc-linux-gnu)
compiled by GNU C version 14.1.1 20240516, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/14/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include
 /usr/include
End of search list.
Compiler executable checksum: b63801264392b36e05179a0f762d8604
during GIMPLE pass: waccess
./ice-14.cpp: In member function 'void Outer::method() requires 
staticTemplatedConstant [with U = void; T = void]':
./ice-14.cpp:12:29: internal compiler error: Segmentation fault
   12 | template  void method() requires
staticTemplatedConstant
  | ^~
0x55af8dca912c crash_signal
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/toplev.cc:319
0x55af8dbea562 new_delete_mismatch_p
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/gimple-ssa-warn-access.cc:1627
0x55af8d7e15d5 new_delete_mismatch_p
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/gimple-ssa-warn-access.cc:1765
0x55af8d7e15d5 matching_alloc_calls_p
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/gimple-ssa-warn-access.cc:1788
0x55af8e48fcdb matching_alloc_calls_p
   
/us

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #4 from huangqinjin at gmail dot com ---
 g++ -fmodules-ts -std=c++20 module.cpp main.cpp
main.cpp: In function 'int main()':
main.cpp:11:15: error: class template argument deduction failed:
   11 | A b(B{}, 1);
  |   ^
main.cpp:11:15: error: no matching function for call to 'A@Mod(B, int)'
In module Mod, imported at main.cpp:1:
module.cpp:11:9: note: candidate: 'template A@Mod(T)-> A@Mod'
   11 | A(T) {}
  | ^
module.cpp:11:9: note:   template argument deduction/substitution failed:
main.cpp:11:15: note:   candidate expects 1 argument, 2 provided
   11 | A b(B{}, 1);
  |   ^
In module Mod, imported at main.cpp:1:
module.cpp:9:9: note: candidate: 'template A@Mod(U, int)->
A@Mod'
9 | A(U, int) {}
  | ^
module.cpp:9:9: note:   template argument deduction/substitution failed:
main.cpp:11:15: note:   couldn't deduce template parameter 'T'
   11 | A b(B{}, 1);
  |   ^
In module Mod, imported at main.cpp:1:
module.cpp:6:12: note: candidate: 'template A@Mod(A@Mod)->
A@Mod'
6 | struct A
  |^
module.cpp:6:12: note:   template argument deduction/substitution failed:
main.cpp:11:15: note:   'B' is not derived from 'A@Mod'
   11 | A b(B{}, 1);
  |   ^

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #3 from huangqinjin at gmail dot com ---
Created attachment 58291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58291&action=edit
main.cpp

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from huangqinjin at gmail dot com ---
Created attachment 58290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58290&action=edit
module.cpp

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-05-26
 Blocks|103524  |
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you attach a testcase instead of linking to godbolt. Also try one that does
not use cmake. Please read https://gcc.gnu.org/bugs since that points out what
is needed here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/115231] New: [C++20] [Modules] deduction guides reachability

[huangqinjin at gmail dot com via Gcc-bugs]

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

Bug ID: 115231
   Summary: [C++20] [Modules] deduction guides reachability
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangqinjin at gmail dot com
  Target Milestone: ---

Refer to https://eel.is/c++draft/temp.deduct.guide#nt:deduction-guide,

> Deduction guides are not found by name lookup.
> Instead, when performing class template argument deduction,
> all reachable deduction guides declared for the class template are considered.

GCC cannot find the deduction guides that are not exported, while both Clang
and MSVC can.

https://godbolt.org/z/9rW3TTMMM

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Andrew Macleod  ---
> Created attachment 58287
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
> proposed patch
>
> I'm testing this patch, does it resolve your problem?

It did: i386-pc-solaris2.11 and sparc-sun-solaris2.11 bootstraps
completed without issues.  Thanks.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

[mschiffer--- via Gcc-bugs]

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

--- Comment #10 from Matthias Schiffer  ---
(In reply to YunQiang Su from comment #8)
> Ohh, In fact we should use $28 if TARGET_USE_GOT.
> 
> Can you help to test this patch?
> 
> ```
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> index b63d40a357b..fe8641d3916 100644
> --- a/gcc/config/mips/mips.cc
> +++ b/gcc/config/mips/mips.cc
> @@ -3342,7 +3342,7 @@ mips16_gp_pseudo_reg (void)
>  rtx
>  mips_pic_base_register (rtx temp)
>  {
> -  if (MIPS16_GP_LOADS ||!TARGET_MIPS16)
> +  if (MIPS16_GP_LOADS || TARGET_USE_GOT ||!TARGET_MIPS16)
>  return pic_offset_table_rtx;
>  
>if (currently_expanding_to_rtl)
> ```

Testing might take a while, I haven't built GCC for some time.

[Bug c++/105645] Template specializations are not hidden with fvisibility=hidden

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Julian Waters  ---
Hopefully that was enough to draw more attention to this bug. Any ideas why
this might be happening?

[Bug c++/115230] -fvisibility=hidden does not hide Template Specializations from being exported

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug c++/105645] Template specializations are not hidden with fvisibility=hidden

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

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

--- Comment #4 from Andrew Pinski  ---
*** Bug 115230 has been marked as a duplicate of this bug. ***

[Bug c++/115230] New: -fvisibility=hidden does not hide Template Specializations from being exported

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 115230
   Summary: -fvisibility=hidden does not hide Template
Specializations from being exported
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

Consider the following code:

#include 

template
void method(T* src, T* dst, size_t length);

template<>
void method(short* src, short* dst, size_t length) {

}

template<>
void method(int* src, int* dst, size_t length) {

}

Compiled using command line:
g++ -O3 -fvisibility=hidden -std=c++14 -pedantic -Wpedantic -Wall -Werror
templates.cpp

Linked using:
g++ -shared -o libtemplates.so templates.o

When nm is run over it using nm -gDC libtemplates.so, the following symbols are
seen:
 w _ITM_deregisterTMCloneTable
 w _ITM_registerTMCloneTable
1110 T void method(int*, int*, unsigned long)
1100 T void method(short*, short*, unsigned long)
 w __cxa_finalize
 w __gmon_start__

T void method(int*, int*, unsigned long) and T void method(short*,
short*, unsigned long) should not be in the symbol table, but they are even
with -fvisibility=hidden.

Strangely, marking both methods with [[gnu::visibility("hidden")]] works and
results in both not being exported.

This was recently observed in the JDK, inside the Java HotSpot VM (see
https://github.com/openjdk/jdk/pull/17955/files#r1498933843)

[Bug fortran/69654] ICE in gfc_trans_structure_assign

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed all the way back to 10-branch. It should have been closed at the time.

Thanks for the report.

Paul

[Bug fortran/104048] ICE with recursively defined derived type

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

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

--- Comment #6 from Paul Thomas  ---
The "fix" in comment 5 no longer does the job. It's on my TODO list.

Paul