[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC

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

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

--- Comment #5 from Andrew Pinski  ---
line 8 is rejected by clang and MSVC also.

[Bug c++/56506] variadic class template specialization not selected as best match

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Confirmed. This ICEs on the trunk (but I don't think it is a regression as
> the assert is a gcc_checking_assert).
> 
> The ICE:
> 
> :12:28: internal compiler error: in comptypes, at cp/typeck.cc:1684
>12 |   Y,char>>::type x;
>   |^~

I should note clang accepts the code.

[Bug c++/56506] variadic class template specialization not selected as best match

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-04
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-checking,
   ||ice-on-valid-code

--- Comment #5 from Andrew Pinski  ---
Confirmed. This ICEs on the trunk (but I don't think it is a regression as the
assert is a gcc_checking_assert).

The ICE:

:12:28: internal compiler error: in comptypes, at cp/typeck.cc:1684
   12 |   Y,char>>::type x;
  |^~

[Bug c++/56506] variadic class template specialization not selected as best match

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> I should note clang accepts the code.

But EDG does not.
While MSVC accepts it.

[Bug c++/57005] alias template's pseudo-destructor is rejected

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

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

--- Comment #3 from Andrew Pinski  ---
MSVC also rejects it.

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|FIXED   |---

--- Comment #5 from Paul Thomas  ---
(In reply to anlauf from comment #4)
> This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 .

Not here. As far as I can tell the results remain exactly the same for both
character and numeric results from 'foo'.

Is it possible that there is a patch lurking in your tree that has fixed it?

Cheers

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

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

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

Bug 113363 Summary: ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|FIXED   |---

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Note, build_qualified_type sets TYPE_CANONICAL of qualified types to either the
returned type or build_qualified_type of the TYPE_CANONICAL of the base type.
So, updating TYPE_CANONICAL of the variants to TYPE_CANONICAL of the base type
looks always wrong, it would need to recompute the TYPE_CANONICAL using
build_qualified_type instead.  But, similarly to build_qualified_type,
build_pointer_type, build_array_type etc. also similarly set TYPE_CANONICAL to
something based on the TYPE_CANONICAL.

So, if you really need to update TYPE_CANONICAL after type is completed, I'd at
least do it only if the new TYPE_CANONICAL is actually different from the base
type, otherwise don't update anything, and if you do update, one needs to also
recompute TYPE_CANONICAL on all the pointer types (those can be found through
for (t = TYPE_POINTER_TO (to_type); t; t = TYPE_NEXT_PTR_TO (t))),
but one would need to do that recursively to also update the **, ***,  etc.
pointers), but also all created ARRAY_TYPEs (the shared ones can be found in
type_hash_table but non-shared can't), FUNCTION_TYPEs etc.

Which makes me wonder if for flag_isoc23 it wouldn't be better to
SET_TYPE_STRUCTURAL_EQUALITY on incomplete structure/union types and therefore
also on any POINTER_TYPE, ARRAY_TYPE, FUNCTION_TYPE, ... derived from that, and
only set
TYPE_CANONICAL when the aggregate is completed.  Yes, it will be slower to
compare
some of the types because one won't be able to use TYPE_CANONICAL, but given
the above it seems really hard to recompute TYPE_CANONICAL on everything that
could have been derived from TYPE_CANONICAL (type) = type of the incomplete
type when it will be later changed.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #8 from uecker at gcc dot gnu.org ---

If we do not care too much about TYPE_CANONICAL being correct in this case
anyway, we could turn off the test and add a condition flag_isoc23 as a
precaution in the FE to not risk any other regressions for pre C23.  Otherwise
we could revert the fix to PR114361 but this also does not seem ideal.


diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index f2083b9d96f..efdbe1a3bde 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9722,7 +9722,8 @@ finish_struct (location_t loc, tree t, tree fieldlist,
tree attributes,
   C_TYPE_VARIABLE_SIZE (x) = C_TYPE_VARIABLE_SIZE (t);
   C_TYPE_VARIABLY_MODIFIED (x) = C_TYPE_VARIABLY_MODIFIED (t);
   C_TYPE_INCOMPLETE_VARS (x) = NULL_TREE;
-  TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
+  if (flag_isoc23)
+   TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
 }

   /* Update type location to the one of the definition, instead of e.g.
diff --git a/gcc/ipa-free-lang-data.cc b/gcc/ipa-free-lang-data.cc
index 16ed55e2e5a..0b75f05fab3 100644
--- a/gcc/ipa-free-lang-data.cc
+++ b/gcc/ipa-free-lang-data.cc
@@ -254,8 +254,11 @@ fld_incomplete_type_of (tree t, class free_lang_data_d
*fld)
  else
first = build_reference_type_for_mode (t2, TYPE_MODE (t),
   TYPE_REF_CAN_ALIAS_ALL (t));
+ // FIXME: temporarily decativated because of PR114493
+#if 0
  gcc_assert (TYPE_CANONICAL (t2) != t2
  && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE
(t)));
+#endif
  if (!fld->pset.add (first))
add_tree_to_fld_list (first, fld);
  return fld_type_variant (first, t, fld);

[Bug c++/111872] GCC rejects out of class definition of inner private class template

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 56248.

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

[Bug c++/56248] [DR 580] access checking of template parameters done too early

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug c++/87713] single character underlined in an error message instead of the whole token

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=40988

--- Comment #2 from Andrew Pinski  ---
See PR 40988 for ways of fixing the inline-asm and even an expanded
explanation.

[Bug c/114598] New: [GCC-14] Miscompilation of `#pragma omp parallel for`

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114598
   Summary: [GCC-14] Miscompilation of `#pragma omp parallel for`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/MPzrsv17v

```
#include 

#define N 2000
int a[N][N];

int main (void)
{
  int i = 0, j = 0;
  for (i = 0; i < N; i++)
#pragma omp parallel for
for (j = 0; j < N; j++)
  a[i][j] = i + j;
  return 0;
}
```

This program will crash if compiled with `gcc-14 -fopenmp-simd`, while clang
can correctly compile it.

[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #14 from kargls at comcast dot net ---
(In reply to anlauf from comment #13)
> Original testcase is fixed for allocate with mold as well as for allocate
> with source, and some test coverage is in r12-5767.
> 
> There are remaining issues for allocatable character arrays, but these
> are tracked elsewhere, e.g. pr113793.
> 
> I suggest to close this one with target milestone 12.x

Seems like a good idea.  Do you believe that original
testcase should be converted to a testcase and committed?

[Bug ipa/111571] [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-9794-gca56b43105fc09021ec445f1978a17cd85ae5e0c
Author: Martin Jambor 
Date:   Thu Apr 4 22:46:16 2024 +0200

ipa: Avoid duplicate replacements in IPA-SRA transformation phase

When the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).

However, when IPA-SRA wants to split out a smaller aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.

Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.

The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up.  The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16).  I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.

gcc/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::common_initialization): Avoid creating
duplicate replacement entries.

gcc/testsuite/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* gcc.dg/ipa/pr111571.c: New test.

[Bug target/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #1 from Andrew Pinski  ---
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.03 (  0%)   0.10 (  0%)
 1903k (  0%)
 phase parsing  : 114.74 ( 95%)  45.79 (100%) 160.53 ( 95%)
 6159M (100%)
 phase lang. deferred   :   0.07 (  0%)   0.00 (  0%)   0.07 (  0%)
 9312  (  0%)
 phase opt and generate :   6.36 (  5%)   0.10 (  0%)   6.46 (  4%)
  293k (  0%)
 phase finalize :   0.00 (  0%)   0.06 (  0%)   1.72 (  1%)
0  (  0%)
 |name lookup   :   0.00 (  0%)   0.01 (  0%)   0.00 (  0%)
  109k (  0%)
 garbage collection :   1.89 (  2%)   0.00 (  0%)   1.89 (  1%)
0  (  0%)
 callgraph construction :   6.35 (  5%)   0.09 (  0%)   6.44 (  4%)
   13k (  0%)
 preprocessing  :  30.74 ( 25%)  24.93 ( 54%)  55.53 ( 33%)
 2047M ( 33%)
 parser (global):  81.10 ( 67%)  20.86 ( 45%) 102.10 ( 60%)
 4111M ( 67%)
 constant expression evaluation :   1.08 (  1%)   0.00 (  0%)   1.08 (  1%)
  304  (  0%)
 post expand cleanups   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 2728  (  0%)
 initialize rtl :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 9032  (  0%)
 rest of compilation:   0.01 (  0%)   0.01 (  0%)   0.00 (  0%)
   16k (  0%)
 TOTAL  : 121.17 45.98168.88   
 6161M
Extra diagnostic checks enabled; compiler may run slowly.


For x86_64-linux-gnu (but with checking enabled). Definitely a front-end issue.
Preprocessing takes 2G is even more shocking.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #4 from Andrew Pinski  ---
The code has 3 huge arrays which is definitely a canidate for  `#embed` usage.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105863

--- Comment #5 from Andrew Pinski  ---
Someone should report this issue to the QT folks to see if they could
reimplement this to use `#embed` (though GCC needs to add #embed support still
but that is PR 105863)

[Bug analyzer/114594] New: Issues seen with -Wanalyzer-malloc-leak on htop/XUtils.c: String_split

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

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

Bug ID: 114594
   Summary: Issues seen with -Wanalyzer-malloc-leak on
htop/XUtils.c: String_split
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
CC: BenBE at geshi dot org
  Target Milestone: ---

Created attachment 57881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57881=edit
Reduced reproducer

User "BenBE2" on #gcc on IRC noted some issues with the attached file; see also
at https://godbolt.org/z/vKbhqMq4T

The analyzer reports a leak, arguably falsely:

: In function 'xRealloc':
:32:7: warning: leak of '' [CWE-401] [-Wanalyzer-malloc-leak]
   32 |   free(ptr);
  |   ^
  'String_split': events 1-2
|
|   38 | char** String_split(const char* s, char sep, size_t* n) {
|  |^~~~
|  ||
|  |(1) entry to 'String_split'
|   39 |const size_t rate = 10;
|   40 |char** out = xCalloc(rate, sizeof(char*));
|  | 
|  | |
|  | (2) calling 'xCalloc' from 'String_split'
|
+--> 'xCalloc': event 3
   |
   |   15 | void* xCalloc(size_t nmemb, size_t size) {
   |  |   ^~~
   |  |   |
   |  |   (3) entry to 'xCalloc'
   |
 'xCalloc': event 4
   |
   |   16 |assert(nmemb > 0);
   |  |^~
   |  ||
   |  |(4) following 'true' branch (when 'nmemb != 0')...
   |
 'xCalloc': event 5
   |
   |   17 |assert(size > 0);
   |  |^~
   |  ||
   |  |(5) ...to here
   |
 'xCalloc': event 6
   |
   |   17 |assert(size > 0);
   |  |^~
   |  ||
   |  |(6) following 'true' branch (when 'size != 0')...
   |
 'xCalloc': events 7-11
   |
   |   18 |if (SIZE_MAX / nmemb < size) {
   |  |   ~ ^
   |  |   | |
   |  |   | (7) ...to here
   |  |   (8) following 'false' branch...
   |..
   |   21 |void* data = calloc(nmemb, size);
   |  | ~~~
   |  | |
   |  | (9) ...to here
   |   22 |if (!data) {
   |  |   ~  
   |  |   |
   |  |   (10) following 'false' branch (when 'data' is
non-NULL)...
   |..
   |   25 |return data;
   |  |      
   |  |   |
   |  |   (11) ...to here
   |
<--+
|
  'String_split': events 12-13
|
|   40 |char** out = xCalloc(rate, sizeof(char*));
|  | ^~~~
|  | |
|  | (12) returning to 'String_split' from 'xCalloc'
|..
|   44 |while ((where = strchr(s, sep)) != NULL) {
|  |~~
|  ||
|  |(13) when 'strchr' returns non-NULL
|
  'String_split': events 14-16
|
|   44 |while ((where = strchr(s, sep)) != NULL) {
|  |^
|  ||
|  |(14) following 'true' branch
(when 'where' is non-NULL)...
|   45 |   size_t size = (size_t)(where - s);
|  | ~~~
|  ||
|  |(15) ...to here
|   46 |   out[ctr] = xStrndup(s, size);
|  |  ~  
|  |  |
|  |  (16) calling 'xStrndup' from 'String_split'
|
+--> 'xStrndup': events 17-21
   |
   |   67 | char* xStrndup(const char* str, size_t len) {
   |  |   ^~~~
   |  |   |
   |  |   (17) entry to 'xStrndup'
   |   68 |char* data = strndup(str, len);
   |  | ~
   |  | |
   |  | (18) allocated here
   |   69 |if (!data) {
   |  |   ~
   |  |   |
   |  |   (19) assuming 'data' is 

[Bug c++/86181] [DR 1839] static object mangling conflicts

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||94404
 Status|SUSPENDED   |NEW

--- Comment #5 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1839

[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to
DR at the February, 2021 meeting.]


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug c++/92648] Handling of unknown attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||o_kniemeyer at maxon dot net

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

[Bug c++/88221] Only restricted set of balanced token sequences allowed for attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 92648 and fixed for GCC 8.4.0, 9.3.0 and 10+.

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

[Bug c++/88371] Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed in GCC 10+.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #4)
> I guess I should add the test.

Though cpp23/lookup2.C does look close to this testcase here.

[Bug c++/66124] AIX 5.3 - greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

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

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

--- Comment #2 from Andrew Pinski  ---
This preprocessed source works on the trunk on x86_64 with a small change.
Replace:
typedef char *va_list;
with
typedef __builtin_va_list va_list;

[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #14)
> (In reply to anlauf from comment #13)
> > Original testcase is fixed for allocate with mold as well as for allocate
> > with source, and some test coverage is in r12-5767.
> > 
> > There are remaining issues for allocatable character arrays, but these
> > are tracked elsewhere, e.g. pr113793.
> > 
> > I suggest to close this one with target milestone 12.x
> 
> Seems like a good idea.  Do you believe that original
> testcase should be converted to a testcase and committed?

Only if something reasonable is tested *beyond* those added/modified
in r12-5767:

gcc/testsuite/gfortran.dg/allocate_with_source_26.f90
gcc/testsuite/gfortran.dg/allocate_with_mold_4.f90

So what is missing here?

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:27b6d081f68528435066be2234c7329e31e0e84f

commit r14-9796-g27b6d081f68528435066be2234c7329e31e0e84f
Author: Wilco Dijkstra 
Date:   Tue Mar 26 15:08:02 2024 +

libatomic: Fix build for --disable-gnu-indirect-function [PR113986]

Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
Always build atomic_16.S, add aliases to the __atomic_ functions if
!HAVE_IFUNC.
Include auto-config.h in atomic_16.S to avoid having to pass defines via
makefiles.  Fix build if HWCAP_ATOMICS/CPUID are not defined.

libatomic:
PR target/113986
* Makefile.in: Regenerated.
* Makefile.am: Make atomic_16.S not depend on HAVE_IFUNC.
Remove predefine of HAVE_FEAT_LSE128.
* acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128.
* configure: Regenerated.
* config/linux/aarch64/atomic_16.S: Add __atomic_ alias if
!HAVE_IFUNC.
* config/linux/aarch64/host-config.h: Correctly handle !HAVE_IFUNC.
Add defines for HWCAP_ATOMICS and HWCAP_CPUID.

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

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

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

--- Comment #7 from Martin Jambor  ---
Thanks, I will bootstrap and test the patch on x86_64 and submit it
for review then.

Can I ask you, can you please modify the testcase so that it does not
use printf but simply calls __builtin_abort in the miscompiled case
and just returns zero from main if it is OK?  That way we could
include it in our test suite.  Thanks a lot.

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.1.0
  Known to fail||11.4.0
   Keywords||needs-bisection, wrong-code

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed in GCC 12+.

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #25 from g.peterh...@t-online.de ---
Hi Matthias,
to get good results on average (all FP-types: (B)FP16..FP128,
scalar/vectorized(SIMD)/parallel/...) this algorithm seems to me (so far) to be
suitable:

template 
inline constexpr Type   hypot_gp(Type x, Type y, Type z)noexcept
{
using limits = std::numeric_limits;

constexpr Type
sqrt_min= std::sqrt(limits::min()),
sqrt_max= std::sqrt(limits::max()),
scale_up= std::exp2( Type(limits::max_exponent/2)),
scale_down  = std::exp2(-Type(limits::max_exponent/2)),
zero= 0;

x = std::abs(x);
y = std::abs(y);
z = std::abs(z);

if (!(std::isnormal(x) && std::isnormal(y) && std::isnormal(z)))
[[unlikely]]
{
if (std::isinf(x) | std::isinf(y) | std::isinf(z))  return
limits::infinity();
else if (std::isnan(x) | std::isnan(y) | std::isnan(z)) return
limits::quiet_NaN();
else
{
const bool
xz{x == zero},
yz{y == zero},
zz{z == zero};

if (xz)
{
if (yz) return zz ? zero : z;
else if (zz)return y;
}
else if (yz && zz)  return x;
}
}

if (x > z) std::swap(x, z);
if (y > z) std::swap(y, z);

if ((z >= sqrt_min) && (z <= sqrt_max)) [[likely]]
{
//  no scale
return std::sqrt(__builtin_assoc_barrier(x*x + y*y) + z*z);
}
else
{
const Type
scale = (z >= sqrt_min) ? scale_down : scale_up;

x *= scale;
y *= scale;
z *= scale;
return std::sqrt(__builtin_assoc_barrier(x*x + y*y) + z*z);
}
}

[Bug c/114597] New: [GCC-14] Miscompilation of pointer assignment with inline assembly

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114597
   Summary: [GCC-14] Miscompilation of pointer assignment with
inline assembly
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/Pn4EG3zzj

```
struct node { void *p; } n;
struct head { struct node *n; } h;

int main () {
  n.p = 
  asm("":"=m"(n.p):"r"(n.p));
  if (n.p != )
__builtin_abort();
  return 0;
}
```

I sanitized this program with all sanitizers I know, they report nothing.
When compile this program with `gcc-14 -O2`, the compiled program aborts, while
`-O0` normally exits.

Any potential undefined behavior:
1. strict aliasing, I added option `-fno-strict-aliasing` to `-O2`, the abort
still exists.
2. If there is some other undefined behavior unknown to me cause this
compilation inconsistency, please let me know.

Regarding the inline assembly, it's important to note that even though `n.p` is
specified as an output operand with `=m`, this doesn't necessarily imply that
`n.p` will be altered. The inline assembly might simply reassign the original
value to `n.p`, leaving it effectively unchanged.

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Compiles since r12-3643:

commit 18b57c1d4a8777bedfe4ed47166f033e71bc144b
Author: Jason Merrill 
Date:   Fri Sep 17 14:18:55 2021 -0400

c++: improve lookup of member-qualified names

I guess I should add the test.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

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

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

--- Comment #5 from Andrew Pinski  ---
Note with checking enabled we get an ICE:
:23:17: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   23 | { return foo(); }
  | ^
_Z3foov.resolver/12 (_Z3foov.resolver)

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Keywords|needs-bisection |
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed by r12-2975:

commit 32c3a75390623a0470df52af13f78baddd562981
Author: Jakub Jelinek 
Date:   Tue Aug 17 21:06:39 2021 +0200

c++: Implement P0466R5 __cpp_lib_is_layout_compatible compiler helpers
[PR101539]


that patch doesn't have any __is_standard_layout tests so I'll add mine.

[Bug rtl-optimization/114595] New: rtl-expand emit redundant store for bitwise-and expression

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114595
   Summary: rtl-expand emit redundant store for bitwise-and
expression
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

Hi, here's a weird case:
```
int g1, g3;
char g2;
void func_1() {
g3 = (g2 = (1 && 1 & g1)) ;
}

```
one store to `g2` is splted into two since gcc-5 under -O2:
```
func_1():
  401130:   mov0x2efe(%rip),%eax# 404034 
  401136:   mov%al,0x2ef0(%rip)# 40402c 
  40113c:   and$0x1,%eax
  40113f:   andb   $0x1,0x2ee6(%rip)# 40402c 
  401146:   mov%eax,0x2ee4(%rip)# 404030 
```

RTL-expand choose to do this and no other pass could optimize it.

```
;;
;; Full RTL generated for this function:
;;
1: NOTE_INSN_DELETED
3: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
5: r82:SI=[`g1']
6: [`g2']=r82:SI#0
7: {[`g2']=[`g2']&0x1;clobber flags:CC;}
8: {r86:SI=r82:SI&0x1;clobber flags:CC;}
9: [`g3']=r86:SI
```

[Bug c++/114377] [13/14 Regression] GCC crashes on an example of CTAD for alias templates

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:801e82acd6b4f0cf863529875947e394899ea7b9

commit r14-9795-g801e82acd6b4f0cf863529875947e394899ea7b9
Author: centurion 
Date:   Wed Mar 27 18:36:37 2024 +

c++: alias CTAD and template template parm [PR114377]

To match all the other places that pull a _TEMPLATE_PARM out of a
_DECL (get_template_parm_index, etc.).

This change is too small to be legally significant for copyright.

PR c++/114377

gcc/cp/ChangeLog:

* pt.cc (find_template_parameter_info::found): Use TREE_TYPE for
TEMPLATE_DECL instead of DECL_INITIAL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias19.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/70667] SFINAE error disambiguating using alignas

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

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

--- Comment #3 from Andrew Pinski  ---
So if we have (note the extra f which has no arguments):
```
template  struct A { alignas (N) int a; };
template  struct B { char c; };

template  int f (int (*)[sizeof (A)]) { return 0; }
template  int f (int (*)[sizeof (B)]) { return 1; }
template  int f () { return 2; }

int i = f<3>();

```
This started to get accepted in GCC 12.

[Bug c++/86748] Terminates abnormally without error messages

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #3)
> Richard: Can you please update Known to work?

Looks to be the wrong bug #.

[Bug c++/91578] bool to size_t warning -Wsign-conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||9.5.0
   Keywords||needs-bisection
  Known to work||10.1.0

--- Comment #3 from Andrew Pinski  ---
Looks to be fixed in GCC 10+.

[Bug middle-end/114596] New: [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

Bug ID: 114596
   Summary: [OpenMP] "declare variant" scoring seems incorrect for
construct selectors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57882=edit
reduced test case

Background: I've been working on integrating the dynamic selector support added
for "metadirective" (patches previously submitted but not yet approved) with
the existing support for "declare variant", rewriting a bunch of code so that
they both share the same representations and functions for matching, scoring,
and sorting.  Those patches aren't yet ready to submit and are stage 1
material, but in comparing differences in test results between my new
implementation and the previous behavior, it looks to me like the scoring for
construct selectors in "declare variant" is pretty borked on mainline.

The attached testcase is a reduced version of
c-c++-common/gomp/declare-variant-12.c.  The "16+8+4" comment on f14 agrees
with what the code is doing, but it seems incorrect according to the spec.  By
my reading, the OpenMP context at the point of call to f17 is {teams, parallel,
for, parallel, for} with associated scores {1, 2, 4, 8, 16}, per sections 7.1
and 7.3 of the 5.2 spec, respectively.  My understanding of the latter part of
item (1) in 7.3

"if the traits that correspond to the construct selector set appear multiple
times in the OpenMP context, the highest valued subset of context traits that
contains all selectors in the same order are used"

is that the matching selectors don't have to appear contiguously, so the score
would be 1+8+16.  In discussion with Tobias, he thinks there is still some
ambiguity about which of the duplicates is preferred for the match, though.

I added some instrumentation to the code to try to figure out how it was coming
up with "16+8+4"; the patch is attached, and produced output 

$ install/bin/x86_64-linux-gnu-gcc declare-variant-12.c -fopenmp
-foffload=disable -S

codes[0] = omp_for
codes[1] = omp_parallel
codes[2] = omp_for
codes[3] = omp_parallel
codes[4] = omp_teams
constructs[0] = omp_for
constructs[1] = omp_parallel
constructs[2] = omp_teams
omp_teams, i = 2, j = 4, position = 4
omp_parallel, i = 1, j = 3, position = 3
omp_for, i = 0, j = 2, position = 2
constructs[0] = omp_for, scores[0] = 4, score = 16
constructs[1] = omp_parallel, scores[1] = 3, score = 8
constructs[2] = omp_teams, scores[2] = 2, score = 4

For selector construct = {teams, parallel, for}
  score1 = 29   score2 = 29

The "codes" array is the OpenMP context, "constructs" are the traits in the
construct selector, and the "scores" array does not contain scores, but rather
the positions of the elements of the "constructs" array in the "codes" array.

I believe there are at least three bugs here:

(1) The constructs array is being processed backwards from n-1 to 0, but the
scores array is indexed from 0 to n-1, and later it's assumed both arrays are
in the same order.

(2) The codes array is backwards and so are the position values, and there's no
adjustment to subtract the position from the length of the "codes" array in
computing the corresponding score.

(3) It's choosing the wrong subset from the duplicate traits, preferring the
should-be-lower-valued outer ones over the higher-valued inner ones.

I don't know if anybody wants to tackle a bug fix for this code for GCC 14.  As
I've said, I've got a complete rewrite I'm planning to submit early in stage 1,
which I hope will be an improvement from an engineering perspective in terms of
readability/maintainability, with cleaner and better-documented interfaces and
references to the spec to explain what it is doing.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #3 from Andrew Pinski  ---
The real way to fix this is to have `#embed` supported for both C++ and C and
move this code over to use that instead.

[Bug c++/88266] nonsense warning about parentheses with all bool not equals

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-04
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1
Summary|nonsense warning about  |nonsense warning about
   |parentheses for comparison  |parentheses with all bool
   ||not equals

--- Comment #1 from Andrew Pinski  ---
Confirmed, != with all boolean types is definitely the only one corner case
where the order does not matter. In other cases (non-boolean or ==, <, etc.)
the order does make a difference.

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.4.0
   Keywords||needs-bisection
  Known to work||12.1.0

--- Comment #3 from Andrew Pinski  ---
Looks to be fixed in GCC 12+.

[Bug c++/12944] [meta-bug] C++ name-lookup problems

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

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

Bug 85570 Summary: Resolution of unqualified-id in member access involving 
templates fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85570

   What|Removed |Added

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

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed then.

[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
(In reply to TC from comment #4)
> Dup of bug 55120?

Yes.

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

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

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

[Bug target/114595] rtl-expand emit redundant store for bitwise-and expression

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #1 from absoler at smail dot nju.edu.cn ---
gcc-4's result:
```
func_1():
movlg1(%rip), %eax
andl$1, %eax
movb%al, g2(%rip)
movl%eax, g3(%rip)
ret
```

[Bug target/114591] [12/13/14 Regression] register allocators introduce an extra load operation since gcc-12

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/114559] [11/12/13/14 Regression] After function inlining some optimizations missing

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug tree-optimization/114511] [11/12/13/14 Regression] Missed optimization: x = -y; x = c + x + y; ==> x=c;

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug target/114595] rtl-expand emit redundant store for bitwise-and expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Already fixed on the trunk. Most likely by r14-6420-g85c5efcffed19c .

We get now:
```
func_1:
movzbl  g1(%rip), %eax
andl$1, %eax
movb%al, g2(%rip)
movsbl  %al, %eax
movl%eax, g3(%rip)
```

There is a small extra zero extend but the extra load/store is gone

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Created attachment 57883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57883=edit
patch to add instrumentation as diagnostic aid

[Bug c/114598] [GCC-14] Miscompilation of `#pragma omp parallel for`

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

wierton <141242068 at smail dot nju.edu.cn> changed:

   What|Removed |Added

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

--- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> ---
Seems invalid, as `j` is not private within the openmp region

[Bug c++/82475] GCC is unable to compile OpenACC with class fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.4.0
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
  Known to work||12.1.0

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 12+ most likely via PR 92120.

[Bug c++/91083] [9 Regression] inconsistent -Wsign-compare warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug c++/90691] [9 regression] -Wsign-compare false-positive with constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||karol.wozniak at linuxmail dot 
org

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

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #26 from g.peterh...@t-online.de ---
must of course be "... / scale".
How can I still edit posts?

[Bug tree-optimization/114545] [11/12/13/14 Regression] Missed optimization for CSE

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[13/14 Regression] wrong|[13 Regression] wrong code
   |code with -Oz -fno-dce  |with -Oz -fno-dce
   |-fno-forward-propagate  |-fno-forward-propagate
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fweb since r13-1826|-fweb since r13-1826

--- Comment #7 from Jeffrey A. Law  ---
Given the problems we've generally had in this space, it's probably quite
reasonable to treat modifications to the stack pointer as memory accesses.

It probably would have been enough to avoid the RISC-V bug I just fixed a week
or so ago.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #3 from wierton <141242068 at smail dot nju.edu.cn> ---
Thanks a lot, I have checked it out.

I'm still somewhat confused. Does the difference in compilation stem from GCC
interpreting "=m" and "=r" differently, leading it to assume that once "n.p" is
declared as an output operand without matched input declaration (eg. "=m"
expects "m", "=r" expects "r"), its value is expected to change?

```
asm("":"=m"(n.p):"r"(n.p)); // n.p is expected to change
asm("":"=r"(n.p):"r"(n.p)); // n.p can retain its value
asm("":"=m"(n.p):"m"(n.p)); // n.p can retain its value
```

Thanks in advance for any further explanation you can provide.

[Bug ipa/114599] New: ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975) with -O2 -fcondition-coverage

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114599
   Summary: ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int)
(bitmap.cc:975) with -O2 -fcondition-coverage
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57884=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fcondition-coverage testcase.c -wrapper
valgrind,-q
==26792== Invalid write of size 4
==26792==at 0xF3D16E: bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975)
==26792==by 0xFB61F3: symtab_node::check_ifunc_callee_symtab_nodes()
(symtab.cc:1449)
==26792==by 0xFCF454: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2320)
==26792==by 0xFD2797: compile (cgraphunit.cc:2315)
==26792==by 0xFD2797: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2589)
==26792==by 0x1513631: compile_file() (toplev.cc:476)
==26792==by 0xDE845B: do_compile (toplev.cc:2154)
==26792==by 0xDE845B: toplev::main(int, char**) (toplev.cc:2310)
==26792==by 0xDE9C3A: main (main.cc:39)
==26792==  Address 0x527a330 is 32 bytes inside a block of size 65,536 alloc'd
==26792==at 0x483E804: malloc (vg_replace_malloc.c:442)
==26792==by 0x2AA5B4B: xmalloc (xmalloc.c:149)
==26792==by 0x2AA2384: call_chunkfun (obstack.c:94)
==26792==by 0x2AA2384: _obstack_begin_worker (obstack.c:141)
==26792==by 0xFD0EDE: analyze_functions(bool) (cgraphunit.cc:1172)
==26792==by 0xFD272D: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2560)
==26792==by 0x1513631: compile_file() (toplev.cc:476)
==26792==by 0xDE845B: do_compile (toplev.cc:2154)
==26792==by 0xDE845B: toplev::main(int, char**) (toplev.cc:2310)
==26792==by 0xDE9C3A: main (main.cc:39)
...
during IPA pass: profile
testcase.c: In function 'do_all_fn_LHASH_DOALL_ARG_arg2':
testcase.c:16:1: internal compiler error: Segmentation fault
   16 | }
  | ^
0x151314f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:319
0x15fba9a hash_table_mod1(unsigned int, unsigned int)
/repo/gcc-trunk/gcc/hash-table.h:344
0x15fba9a hash_table, unsigned int> >::hash_entry,
false, xcallocator>::find_with_hash(gcond* const&, unsigned int)
/repo/gcc-trunk/gcc/hash-table.h:985
0x15f9c9b hash_map, unsigned int> >::get(gcond*
const&)
/repo/gcc-trunk/gcc/hash-map.h:191
0x15f9c9b condition_uid
/repo/gcc-trunk/gcc/tree-profile.cc:370
0x15f9c9b find_conditions(function*)
/repo/gcc-trunk/gcc/tree-profile.cc:877
0x140dc23 branch_prob(bool)
/repo/gcc-trunk/gcc/profile.cc:1549
0x15f92f4 tree_profiling
/repo/gcc-trunk/gcc/tree-profile.cc:1917
0x15f92f4 execute
/repo/gcc-trunk/gcc/tree-profile.cc:2046
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9799-20240405035546-g4c8b3600c48-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9799-20240405035546-g4c8b3600c48-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240405 (experimental) (GCC)

[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC

[hstong at ca dot ibm.com via Gcc-bugs]

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

Hubert Tong  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Hubert Tong  ---
A().i on line 8 is specified to be an xvalue of type "volatile int" nowadays.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host||arm-linux-gnueabihf
 Target|arm-linux-gnueabihf |
  Component|target  |c++

--- Comment #2 from Andrew Pinski  ---
Though 111MB preprocessed source makes this a huge one in general but if we say
on average a token is 3 characters and a token takes ~16 bytes each. that does
expand to over 500 MB of memory since we do up front lexing for C++.

[Bug ipa/111571] [13 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE in   |[13 Regression] ICE in
   |modify_call, at |modify_call, at
   |ipa-param-manipulation.cc:6 |ipa-param-manipulation.cc:6
   |56  |56

--- Comment #6 from Martin Jambor  ---
Fixed on master, fix queued for backporting to gcc 13 branch.

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41

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

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

--- Comment #71 from Martin Jambor  ---
I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6le5s25kl@virgil.suse.cz/T/#u

[Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64 and x86_64

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

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

--- Comment #24 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #23)
> I however wonder if we really guarantee to copy the paddings everywhere else
> then the total scalarization part?
> (i.e. in all paths through the RTL expansion)

I wanted that we sometimes don't do that in PR 80689 and the idea was
refused.  And as far as I can recall the code I don't think we do.

Anyway, I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6jzlc25db@virgil.suse.cz/T/#u

[Bug c++/70667] SFINAE error disambiguating using alignas

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

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

--- Comment #4 from Andrew Pinski  ---
If we had:
```
int i = f<3>(nullptr);
```
clang, edg and MSVC also rejects it for the same reason as GCC.

[Bug analyzer/114594] Issues seen with -Wanalyzer-malloc-leak on htop/XUtils.c: String_split

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

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

--- Comment #1 from David Malcolm  ---
The "leak" was fixed in htop by
https://github.com/htop-dev/htop/commit/62c2d820add3dadea7569af051d2afd804f08432

[Bug c++/91083] [9 Regression] inconsistent -Wsign-compare warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
  Known to work||10.1.0, 8.1.0, 8.5.0
Summary|inconsistent -Wsign-compare |[9 Regression] inconsistent
   |warnings|-Wsign-compare warnings
  Known to fail||9.5.0

[Bug middle-end/92120] OpenMP 5 – implicit mapping of this->member variable access – "this[:1]" shall be mapped

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug c++/66053] openmp target data mappings containing this pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 12 via the patch which fixed PR 92120 .

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #8 from Patrick O'Neill  ---
Adjusted testcase:
union a {
  unsigned short b;
  int c;
  signed short d;
};
int e, f = 1, g;
long h;
const int **i;
void j(union a k, int l, unsigned m) {
  const int *a[100];
  i = [0];
  h = k.d;
}
static int o(union a k) {
  k.d = -1;
  while (1)
if (f)
  break;
  j(k, g, e);
  return 0;
}
int main() {
  union a n = {1};
  o(n);
  if (h != -1)
__builtin_abort();
}

Commands:
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O2 test.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out

> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O3 test.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out
zsh: IOT instruction (core dumped) 
/scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out

[Bug c++/82008] nonnull attribute and multiple inheritance

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98646
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #3 from Andrew Pinski  ---
Fxied in GCC 11 (most likely via the patch which fixed PR 98646 ).

[Bug c++/86748] Terminates abnormally without error messages

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2018-07-31 00:00:00 |2024-4-4

--- Comment #5 from Andrew Pinski  ---
Note clang has a similar issue here and it still fails.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The value that goes into the second operand of the  inline-asm is correct.

But since you don't mark the inline-asm as reading the memory location,  gcc
thinks you are not reading it (which is correct based on the definition of how
inline-asm works).

So invalid.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

  Attachment #57874|0   |1
is obsolete||

--- Comment #16 from Martin Uecker  ---
Created attachment 57885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57885=edit
patch


New version. This should work with and without the flag_isoc23 guards.

[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 CC||xry111 at gcc dot gnu.org
 Resolution|MOVED   |---

--- Comment #2 from Xi Ruoyao  ---
Jan Beulich believe the issue is in GCC.  Reopen as "waiting".

[Bug c++/102635] Wrong rejection of function default argument value depending on argument name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Not just very closely, it is exactly the same.

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

[Bug c++/50479] Unevaluated usage of parameters in function default arguments is accepted

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

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

[Bug tree-optimization/114551] [13 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||14.0
Summary|[14 Regression] wrong code  |[13 Regression] wrong code
   |at -O3 on x86_64-linux-gnu  |at -O3 on x86_64-linux-gnu
   |since r14-2944  |since r14-2944
   Target Milestone|14.0|13.3

--- Comment #8 from Richard Biener  ---
Fixed on trunk, but the problem is surely latent.  I'm queueing for a GCC 13
backport but will not bother with it further.

[Bug rtl-optimization/114575] [14 Regression] SVE addressing modes broken since g:839bc42772ba7af66af3bd16efed4a69511312ae

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #2 from Richard Biener  ---
I proposed reverting the offending revision but am waiting for Seghers OK.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto

--- Comment #11 from Richard Biener  ---
Wrong TYPE_CANONICAL leads to wrong TBAA.  And yes "fixing" TYPE_CANONICAL
after the fact means possibly merging two equivalence classes which means you
have to
fix all members of both classes to have the corresponding TYPE_CANONICAL.  Plus
the complication of derived types (vector, pointer, and others) which have
constraints based on their contained type equivalence class.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #12 from Jakub Jelinek  ---
Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
seems c-typeck.cc doesn't actually use that, so it is mainly middle-end then).
See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at least
one TYPE_CANONICAL is NULL (aka TYPE_STRUCTURAL_EQUALITY_P), and otherwise at
least without checking will rely on TYPE_CANONICAL comparison and that is it.
So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as long as
comptypes etc. works correctly).  Having TYPE_CANONICAL non-NULL and not
actually matching could cause type comparisons to think types are the same when
they aren't or vice versa.

Now, when you set TYPE_CANONICAL on completion of the flag_isoc23 aggregates,
you could surely also update TYPE_CANONICAL of the variant types using
build_qualified_type and perhaps pointers too, just to handle the common case. 
But unlike the case where the TYPE_CANONICAL of the aggregate TYPE_MAIN_VARIANT
would be initially different, you wouldn't need to chase down everything,
including TYPE_CANONICAL on FUNCTION_TYPE which have pointers to array type of
array type of pointer of pointer of qualified pointer to the aggregate etc.,
just the common things.
And setting TYPE_CANONICAL just based on the tag would be also wrong, if one
can define struct S { int s; }; in one scope and struct S { int a, b; }; in
another scope and those types are supposed to be different.

[Bug target/114576] [14 regression] VEX-prefixed AES instruction without AVX enabled

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/110501] [13/14 regression] Invalid -Wuse-after-free / realloc with a store/load happening

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/110501] [13/14 regression] Invalid -Wuse-after-free / realloc with a store/load happening

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

--- Comment #9 from Richard Biener  ---
(In reply to John Baldwin from comment #7)
> I believe I am hitting this same issue using GCC 13 to compile FreeBSD's
> userland. (I looked through several of the other bugs for the
> Wuse-after-free metabug and this one seems the closest to what I'm
> encountering).  The code in question does not trigger the -Wuse-after-free
> warning when using GCC 12, but now triggers the warning with GCC 13.  It is
> just calling free on the old value after realloc fails which should be safe.
> The simplest version I've encountered so far in FreeBSD's tree is this:
> 
> static int
> group_resize(void)
> {
>   char *buf;
> 
>   if (gbufsize == 0)
>   gbufsize = 1024;
>   else
>   gbufsize *= 2;
> 
>   buf = gbuffer;
>   gbuffer = realloc(buf, gbufsize);
>   if (gbuffer == NULL) {
>   free(buf);

the problem with this is that 'gbuffer' is a global and we diagnose this
early before applying memory CSE so we don't see the 'gbuffer' being
stored and 'gbuffer' being tested against NULL as equal.

IIRC with GCC 13 we moved some diagnostics early from late as late has
issues with jump threading exposing very many false positives.

Testcase (which I believe we have a duplicate for):

void *gbuffer;
unsigned long gbufsize;
void foo()
{
  char *buf = gbuffer;
  gbuffer = __builtin_realloc(buf, gbufsize);
  if (!gbuffer) {
  __builtin_free(buf);
  return;
  }
  __builtin_memset (gbuffer, 0, gbufsize);
}

I'll note that for the early -Wuninitialized I added cheap value numbering
to prune unreachable code paths.  The plan was to wrap all of the early
diagnostics with such cheap VN _analysis_ (but not do any code changes)
which would allow these cases to be identified as equal.  The diagnostic
passes would need to apply some valueization then of course.

[Bug middle-end/110972] 13% fatigue regression with r14-3078-gd9f3ea61fe36e2

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #13 from Martin Uecker  ---


(In reply to Richard Biener from comment #11)
> Wrong TYPE_CANONICAL leads to wrong TBAA.  And yes "fixing" TYPE_CANONICAL
> after the fact means possibly merging two equivalence classes which means
> you have to
> fix all members of both classes to have the corresponding TYPE_CANONICAL. 
> Plus
> the complication of derived types (vector, pointer, and others) which have
> constraints based on their contained type equivalence class.


Is upgrading incomplete types from structural comparison to TYPE_CANONICAL
meant to be allowed?

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #14 from Martin Uecker  ---
(In reply to Jakub Jelinek from comment #12)
> Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
> TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
> seems c-typeck.cc doesn't actually use that, so it is mainly middle-end
> then).
> See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at
> least one TYPE_CANONICAL is NULL (aka TYPE_STRUCTURAL_EQUALITY_P), and
> otherwise at least without checking will rely on TYPE_CANONICAL comparison
> and that is it.
> So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as long
> as comptypes etc. works correctly).  Having TYPE_CANONICAL non-NULL and not
> actually matching could cause type comparisons to think types are the same
> when they aren't or vice versa.
> 
> Now, when you set TYPE_CANONICAL on completion of the flag_isoc23
> aggregates, you could surely also update TYPE_CANONICAL of the variant types
> using build_qualified_type and perhaps pointers too, just to handle the
> common case.  But unlike the case where the TYPE_CANONICAL of the aggregate
> TYPE_MAIN_VARIANT would be initially different, you wouldn't need to chase
> down everything, including TYPE_CANONICAL on FUNCTION_TYPE which have
> pointers to array type of array type of pointer of pointer of qualified
> pointer to the aggregate etc., just the common things.
> And setting TYPE_CANONICAL just based on the tag would be also wrong, if one
> can define struct S { int s; }; in one scope and struct S { int a, b; }; in
> another scope and those types are supposed to be different.


According to my understanding, setting based on tag would form larger
equivalence classes, so should give correct code but suboptimal aliasing
analysis.

There are two general issues I see here.

1.) The middle end idea of type compatibility is not necessarily the same as
the language semantics. In particular type compatibility in C is not based on
mutual equivalence, so any mechanism based on forming equivalence classes using
TYPE_CANONICAL can only be an approximation (which to be correct, must be less
precise than the language semantics). 

2.) If compatibility relationship changes for types (as it the case when
completing types, then we either have to use an equivalence class that does not
need to change (e.g. based on tags) or only use structural equivalency, or
upgrade structural equivalency to the  equivalency class for the completed type
if this is allowed.

[Bug tree-optimization/114555] ICE: definition in block 14 does not dominate use in block 15 at -O and above with _BitInt() bitfield

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:48530efdcccb154d3ed200246384edc162debc5d

commit r14-9783-g48530efdcccb154d3ed200246384edc162debc5d
Author: Jakub Jelinek 
Date:   Thu Apr 4 10:47:00 2024 +0200

bitint: Handle m_bitfld_load cast in outer m_cast_conditional [PR114555]

We ICE on the following testcase, because we use result of a PHI node
which is only conditional because of a m_cast_conditional on the outermost
loops PHI node argument and so is invalid SSA form.

The following patch fixes it like similar cases elsewhere by adding
needed intervening PHI(s).

2024-04-04  Jakub Jelinek  

PR tree-optimization/114555
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): For
m_bitfld_load and save_cast_conditional add any needed PHIs
and adjust t4 accordingly.

* gcc.dg/bitint-103.c: New test.
* gcc.dg/bitint-104.c: New test.

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #19 from Richard Biener  ---
Alexander - the testcase at -O1 shows curiously high

   3.16%  9840  cc1plus  cc1plus [.] mergesort

which is attributed (by callgrind) to

  if (sizeof (size_t) == 8 && LIKELY (c->size == 8))
--> MERGE_ELTSIZE (8);

and the caller in tree-into-ssa.cc:prune_unused_phi_nodes doing

  qsort (defs, adef, sizeof (struct dom_dfsnum), cmp_dfsnum);

I'm not sure why callgrind pins it this way, but perf somewhat agrees:

Samples││MERGE_ELTSIZE (8);   
▒
 1 │2d0:│  mov%r9,%rsi
▒
 8 ││  mov%r9,0x8(%rsp)   
▒
   528 ││  mov%r12,%rdi   
▒
31 ││→ call   *0x0(%r13)  
▒
   236 ││  mov0x8(%rsp),%r9   
▒
 2 ││  sar$0x1f,%eax  
▒
   244 ││  mov%r12,%rcx   
▒
   ││  movslq %eax,%rdx   
▒
   531 ││  and$0x8,%eax   
▒
62 ││  add$0x8,%rbx   
▒
   ││  cltq   
◆
   725 ││  xor%r9,%rcx
▒
   914 ││  add%rax,%r12   
▒
 1 ││  and%rdx,%rcx   
▒
   ││  xor%r9,%rcx
▒
 3 ││  mov(%rcx),%rcx 
▒
  2155 ││  mov%rcx,-0x8(%rbx) 
▒
29 ││  cmp%r12,%rbx   
▒
   │└──je 1d7

I'll note the swapping of 8 bytes is a bit odd and it seems to be
if-converted, thus always doing a write.

I'm of course questioning what prune_unused_phi_nodes does but I have no
idea if that's sensible at all, but it seems slow for this testcase, and
the sorting is the slowest part of it.

[Bug libstdc++/93672] [11/12/13/14 Regression] std::basic_istream::ignore hangs if delim MSB is set

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|std::basic_istream::ignore  |[11/12/13/14 Regression]
   |hangs if delim MSB is set   |std::basic_istream::ignore
   ||hangs if delim MSB is set
  Known to fail||11.4.0, 12.3.0, 13.2.0,
   ||14.0, 4.0.0, 9.1.0
  Known to work||3.4.6
   Target Milestone|--- |11.5

--- Comment #4 from Jonathan Wakely  ---
The incorrect behaviour was introduced with r0-59139-g80dddedcaf316e

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

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

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

Arnaud Charlet  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #12 from Arnaud Charlet  ---
Yes, on paper this looks like a very nice cleanup, thank you!

The tricky part is to carefully review the conversion code, as well as the
change in GNAT.Sockets* (perhaps consider separating the changes in
GNAT.Socket* in another patch on top of the first one, that will ease the
review if possible).

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-9781-ge152177b362143465e2b9d721ea632cae3f13445
Author: Richard Biener 
Date:   Wed Apr 3 14:53:30 2024 +0200

tree-optimization/114551 - loop splitting and undefined overflow

When loop splitting hoists a guard computation it needs to make sure
that can be safely evaluated at this place when it was previously
only conditionally evaluated.  The following fixes this for the
case of undefined overflow.

PR tree-optimization/114551
* tree-ssa-loop-split.cc (split_loop): If the guard is
only conditionally evaluated rewrite computations with
possibly undefined overflow to unsigned arithmetic.

* gcc.dg/torture/pr114551.c: New testcase.

[Bug c++/84373] g++ incorrectly resolves names for default parameters

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Dup of bug 62244.

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

[Bug c++/62244] Function parameter should be in scope in its own default argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||smcallis at gmail dot com

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

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #10 from uecker at gcc dot gnu.org ---

Yes, this makes sense. I will try this. (I tried this approach already but I
did not get this work, probably because something I missed). 

Otherwise one could try setting TYPE_CANONICAL only based on the tag, which
would then never need to change, but this would lose a lot of information. 

What consequences does it have to have the wrong TYPE_CANONICAL on pointers? I
am asking because the current behavior also seems wrong because now
TYPE_CANONICAL for complete and incomplete types may turn out to be different.
Or am I missing something?