[Bug c++/12341] Request for additional warning for variable shadowing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||joseph.h.garvin at gmail dot 
com

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

[Bug c++/45615] -Wshadow doesn't report class member shadowing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 12341.

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

[Bug c++/94951] [8/9 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||a-yee at u dot northwestern.edu

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

[Bug c++/91343] Spurious strict-aliasing warning with template class inheritance.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216

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

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

--- Comment #12 from Kewen Lin  ---
The patch was posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582454.html

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

--- Comment #6 from Kewen Lin  ---
The proposed patch was tested and just posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582453.html.

[Bug tree-optimization/102920] [12 Regression] Wrong code with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.0
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-10-25

--- Comment #1 from Andrew Pinski  ---
   [local count: 70079549]:
  var_123 = _27(D);
  goto ; [100.00%]


Fre messed up:
Before:
  # var_120_lsm.8_36 = PHI <_1(5), _27(D)(4)>
  # var_120_lsm_flag.9_37 = PHI <1(5), 0(4)>
  # var_123_lsm.10_38 = PHI <_24(D)(5), _43(4)>
  # var_123_lsm_flag.11_39 = PHI <0(5), 1(4)>

After:
  # var_120_lsm.8_36 = PHI <_1(5), _27(D)(4)>
  # var_120_lsm_flag.9_37 = PHI <1(5), 0(4)>
  # var_123_lsm_flag.11_39 = PHI <0(5), 1(4)>

This would mean this was caused by r12-4625-gfe8475c500.

[Bug target/102868] Missed optimization with __builtin_shuffle and zero vector on ppc

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

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

--- Comment #1 from luoxhu at gcc dot gnu.org ---
Patch submitted: 
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582452.html

[Bug fortran/79330] gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
Still fails on master (12.0).

[Bug tree-optimization/102897] [12 Regression] simplify_permutation ICEs on assert since r12-1103-g4a9f2306cb39a3cf

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

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

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
Thanks for reporting and bisection, I'll have a look.

[Bug c++/102514] The allocation function shall not be called when existing an erroneous expression in noptr-new-declarator

[xmh970252187 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from jim x  ---
It seems that they all do not obey [expr.new] p9, which says that

If the expression in a noptr-new-declarator is present, it is implicitly
converted to std​::​size_­t. The expression is erroneous if:

- the expression is of non-class type and its value before converting to
std​::​size_­t is less than zero;

- [...]

If the expression is erroneous after converting to std​::​size_­t: 

- if the expression is a core constant expression, the program is ill-formed; 

- otherwise, an allocation function is not called; instead

  - if the allocation function that would have been called has a non-throwing 
exception specification ([except.spec]), the value of the new-expression is 
the null pointer value of the required result type;  

  - otherwise, the new-expression terminates by throwing an exception of a type 
that would match a handler ([except.handle]) of type
std​::​bad_­array_­new_­ 
length.

[Bug fortran/95375] ICE in add_use_op, Error: mismatching comparison operand types

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
Current behavior on master is to warn, then ICE:

$ x86_64-linux-gnu-gfortran -c z1.f90
z1.f90:1:0:

1 | function f() result(n) bind(c)
  | 
..
6 |   function f() result(n) bind(c)
  |  2
Warning: Type mismatch in function result (INTEGER(4)/CLASS(*)) between (1) and
(2)
z1.f90:4:9:

4 | program p
  | ^
Error: mismatching comparison operand types
struct __class__STAR_a
integer(kind=4)
if (D.4230 != 0) goto ; else goto ;
z1.f90:4:9: internal compiler error: 'verify_gimple' failed
0xfd471d verify_gimple_in_seq(gimple*)
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/tree-cfg.c:5229
0xcee7b6 gimplify_body(tree_node*, bool)
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/gimplify.c:15913
0xcee97d gimplify_function_tree(tree_node*)
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/gimplify.c:15984
0xb1a3b7 cgraph_node::analyze()
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:670
0xb1cec7 analyze_functions
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:1234
0xb1db5d symbol_table::finalize_compilation_unit()
/scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #8 from sandra at gcc dot gnu.org ---
Still present on master, so no, this bug hasn't spontaneously fixed itself. 
:-(

[Bug tree-optimization/102238] missing -Wrestrict for sprintf into the same member array as argument plus offset

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |12.0
Summary|alias_offset in |missing -Wrestrict for
   |gimple-ssa-sprintf.c is |sprintf into the same
   |broken  |member array as argument
   ||plus offset
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102919

--- Comment #9 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582446.html

[Bug tree-optimization/102919] spurious -Wrestrict warning for sprintf into the same member array as argument plus offset

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |12.0

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582446.html

[Bug c++/102921] error: modification of '' is not a constant expression

[f.heckenbach--- via Gcc-bugs]

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

--- Comment #1 from Frank Heckenbach  ---
The following program, compiled with "-std=c++20" gives this error message; I
don't even understand what it's trying to tell me:

  error: modification of '' is not a constant expression

#include 
#include 

constexpr std::initializer_list  a { "" };

Other compilers seem to have no problem with it.

Digging through the headers, I could trace it (via char_traits and
__constant_string_p) to __builtin_is_constant_evaluated. The following version
gives the same error (but I'm still not sure if the problem is in the compiler
or the headers):

#include 
#include 

struct S
{
  constexpr S () noexcept { }
  int a = std::is_constant_evaluated ();
};

constexpr std::initializer_list  a { { } };

[Bug c++/102921] New: error: modification of '' is not a constant expression

[f.heckenbach--- via Gcc-bugs]

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

Bug ID: 102921
   Summary: error: modification of '' is not a constant
expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

[Bug tree-optimization/102920] New: [12 Regression] Wrong code with -O3

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 102920
   Summary: [12 Regression] Wrong code with -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

https://godbolt.org/z/qn3dsxsW8

Reproducer:
#include 

unsigned short a = 42;
unsigned short b = 1;
long long int c = 1;
unsigned char var_120;
unsigned char var_123;

void test(unsigned short a, unsigned short b, long long int c)
__attribute__((noipa));

void test(unsigned short a, unsigned short b, long long c) {
for (char i = 0; i < (char)c; i += 5)
if (!b)
var_120 = a;
else
var_123 = a;
}

int main() {
test(a, b, c);
printf("%hhu\n", var_123);
//if (var_123 != 42)
//__builtin_abort();
}

Error:
>$ g++ -O3 small.cpp && ./a.out
0
>$ g++ -O2 small.cpp && ./a.out
42

GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/testing/gcc/bin_master/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /testing/gcc/gcc_src_master/configure --enable-multilib
--prefix=/testing/gcc/bin_master --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211023 (experimental) (GCC) 
root@abe71269b867:/testing/result/S_1635079215/reduce# cat
/testing/gcc/gcc_rev.txt 
git://gcc.gnu.org/git/gcc.git:master
e3725624ec0735996a18e1a90317e230bef899ac

[Bug tree-optimization/102919] spurious -Wrestrict warning for sprintf into the same member array as argument plus offset

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 Blocks||84774
   Last reconfirmed||2021-10-24
   Keywords||diagnostic
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict

[Bug tree-optimization/102919] New: spurious -Wrestrict warning for sprintf into the same member array as argument plus offset

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

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

Bug ID: 102919
   Summary: spurious -Wrestrict warning for sprintf into the same
member array as argument plus offset
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The write below by sprintf into p->a cannot overlap with the read from p->a + 2
because the length of the string at p->a + 2 is at most 1.  The only it might
overlap is if the string was longer than fits in the array which would make the
sprintf call invalid for another reason: reading past the end.  The -Wrestrict
instance should be avoided here.

$ cat z.c && gcc -O2 -S -Wall z.c
struct A { char a[4]; int i; };

void f (struct A *p)
{ 
  __builtin_sprintf (p->a, "%s", p->a + 2);
}
z.c: In function ‘void f(A*)’:
z.c:5:21: warning: ‘__builtin_sprintf’ argument 3 may overlap destination
object ‘p’ [-Wrestrict]
5 |   __builtin_sprintf (p->a, "%s", p->a + 2);
  |   ~~^~
z.c:3:19: note: destination object referenced by ‘restrict’-qualified argument
1 was declared here
3 | void f (struct A *p)
  | ~~^

[Bug c++/102918] New: Undefined behaviour in regex header (uininitialized boolean)

[camilotalero96 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102918
   Summary: Undefined behaviour in regex header (uininitialized
boolean)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: camilotalero96 at hotmail dot com
  Target Milestone: ---

I am using undefined behaviour sanitizers and they are detecting a potential
bug in teh regex header, the specific report is:

`/usr/include/c++/11/bits/regex.h:909:15: runtime error: load of value 192,
which is not a valid value for type 'bool'`

Which does seem like the use of a potentially uninitialized boolean.

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

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

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

--- Comment #7 from David Edelsohn  ---
Sandra checked in a large number of testcases for interoperability that were
broken from the outset on all platforms -- I saw them failing on multiple Linux
architectures, not just AIX. The testcases should have been XFAILed when
initially checked in.  If the testcases had been XFAILed, it would have been
apparent that the cf-descriptor-5-c.c testcase was not written portably for
different OSes.

My patch apparently swapped which targets produced UNRESOLVED and which
produced FAIL (now PASS).

Known failing portability testcases should not have been checked in to the GCC
repository.

alloca() is a mess.  If you have better visibility into the portability of
alloca() across platforms, you're welcome to fix it.  I suggest that having
different targets use different definitions of alloca muddles the test.  If the
intention is for the system header to substitute __builtin_alloca() for
alloca(), then it suggest would be better use that from the beginning.  The
testcase seems to intend to test C-Fortran interoperability, not alloca().

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Will Wray  ---
The patch above doesn't address the secondary issue,
of ignored and unchecked nested designators:

C b {{.bogus="b"}};

Perhaps reshape_init should be recursed into once more?

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Will Wray  ---
The patch below fixes the main issue (I think, checking)
by adding first_initializer_p to the error condition
it errors only where designators are not allowed.


diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 8a45411c995..f1210e862ca 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6835,7 +6835,7 @@ reshape_init_r (tree type, reshape_iter *d, tree
first_initializer_p,
 array types (one value per array element).  */
   if (TREE_CODE (stripped_str_init) == STRING_CST)
{
- if (has_designator_problem (d, complain))
+ if (first_initializer_p && has_designator_problem (d, complain))
return error_mark_node;
  d->cur++;
  return str_init;

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

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

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #5)
> Previously the test case was unresolved because it referenced alloca without
> a declaration.
> 
> char *adata = (char *) alloca (n);
> 
> If you want to call __builtin_alloca() because this is a testcase for GCC,
> which provides __builtin_alloca(), fine.  You should call it directly and
> not alloca().
> 
> If you want to call alloca(), then you need logic for the different systems
> that declare alloca() in different header files.
> 
> #ifdef alloca
> 
> is wrong because it makes the testcase system dependent and tests different
> behavior.

It seems you broke it with

% git blame gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c
cb17b5054118 (Sandra Loosemore  2021-06-30 20:03:27 -0700  1) #include

cb17b5054118 (Sandra Loosemore  2021-06-30 20:03:27 -0700  2) #include

 (Not Committed Yet 2021-10-24 13:54:29 -0700  3) #ifndef alloca
f1408388f2e2 (David Edelsohn2021-09-30 16:43:58 -0400  4) #include

 (Not Committed Yet 2021-10-24 13:54:29 -0700  5) #endif

Shouldn't the person who broke the testcase fix it?  Or, is it okay
for anyone to commit an unreviewed knowingly broken "fix" to paper over
a failure on whatever target they are working on?

[Bug libstdc++/102916] cmath constexpr can lead to ODR violations/incorrect results

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Darrell Wright  ---
Right, mostly it can fall under as-if(if it wasn't explicitly disallowed) but
because it's observable it can lead to some interesting behaviour differences
when libstdc++ is compiled with gcc and clang.

[Bug c++/102916] cmath constexpr can lead to ODR violations/incorrect results

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Darrell Wright from comment #3)
> > Also http://eel.is/c++draft/library#constexpr.functions-1
> > 
> > An issue is that it's high level observable and not just an optimization
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2013

So it looks GCC decided at the time when the defect report was filed to the C++
language working group, GCC changed to allow the constexpr and then the library
working group changed how to explicitly reject these instead.

[Bug c++/102916] cmath constexpr can lead to ODR violations/incorrect results

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Darrell Wright from comment #3)
> Also http://eel.is/c++draft/library#constexpr.functions-1
> 
> An issue is that it's high level observable and not just an optimization

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2013

[Bug c++/102916] cmath constexpr can lead to ODR violations/incorrect results

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Darrell Wright  ---
Also http://eel.is/c++draft/library#constexpr.functions-1

An issue is that it's high level observable and not just an optimization

[Bug c++/102916] cmath constexpr can lead to ODR violations/incorrect results

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Darrell Wright  ---
The constexpr value returned is different depending on the compiler.  If one
uses clang and gcc this leads to an ODR issue as 

void bar( ) {
  if constexpr( foo<[]{ return std::sqrt( 4.0 ); }>( ) ) {
doA( );
  } else {
doB( );
  }
}

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

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

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #5 from David Edelsohn  ---
Previously the test case was unresolved because it referenced alloca without a
declaration.

char *adata = (char *) alloca (n);

If you want to call __builtin_alloca() because this is a testcase for GCC,
which provides __builtin_alloca(), fine.  You should call it directly and not
alloca().

If you want to call alloca(), then you need logic for the different systems
that declare alloca() in different header files.

#ifdef alloca

is wrong because it makes the testcase system dependent and tests different
behavior.

[Bug c++/102916] cmath constexpr can lead to ODR violations/incorrect results

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

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

--- Comment #1 from Andrew Pinski  ---
> this can lead to ODR issues
I don't think it can the C++ standard allows a compiler to have an extended
const expressions IIRC.

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r12-4278-g74ccca380cde5e79

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
*** Bug 100970 has been marked as a duplicate of this bug. ***

[Bug fortran/100970] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||anlauf at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from anlauf at gcc dot gnu.org ---
All ICEs and accepts-invalid reported here are fixed by r12-4452.

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

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r12-4278-g74ccca380cde5e79

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #7 from anlauf at gcc dot gnu.org ---
*** Bug 67542 has been marked as a duplicate of this bug. ***

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE
 CC||anlauf at gcc dot gnu.org

--- Comment #14 from anlauf at gcc dot gnu.org ---
Indeed this is a duplicate.  All ICEing cases are rejected by the new check.

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

[Bug fortran/102917] [PDT] KIND and LEN type parameters shall not be restricted to default integer

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-October/056791.html

[Bug fortran/102917] [PDT] KIND and LEN type parameters shall not be restricted to default integer

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
   Keywords||rejects-valid
   Last reconfirmed||2021-10-24
 Status|UNCONFIRMED |NEW

[Bug fortran/102917] New: [PDT] KIND and LEN type parameters shall not be restricted to default integer

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

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

Bug ID: 102917
   Summary: [PDT] KIND and LEN type parameters shall not be
restricted to default integer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Reported by Steve:

https://gcc.gnu.org/pipermail/fortran/2021-October/056771.html

We reject valid code.

F2003 has in section 4.5.2 on page 48:

   R435 type-param-def-stmt  is INTEGER [ kind-selector ] , ...

   Each type parameter is itself of type integer.  If its kind selector
   is omitted, the kind type parameter is default integer.

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dje.gcc at gmail dot com

--- Comment #4 from kargl at gcc dot gnu.org ---
David, please, unfix your fix for this testcase.  It is causes 5 FAILs in the
testsuite.

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Sun, Oct 24, 2021 at 05:28:08AM +, pinskia at gcc dot gnu.org wrote:
> 
> --- Comment #2 from Andrew Pinski  ---
> I think the following is better:
> 
> #ifndef alloca
> #define alloca __builtin_alloca
> #endif
> 
> Instead of the include of alloca.h.
> 

I have no preference with regards to the fix.  I do
however prefer that when trivially obvious choices
are available that one is selected and committed.

[Bug fortran/102901] ICE (segfault) when compiling pdt_13.f03 with -fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> Existing pdt_13.f03, pdt_14.f03 and pdt_15.f03 fail when compiled with
> -fcheck=all
> 

PDT are so badly broken any additional PR involving -fcheck is of little use.
At last count, there were 33 open PRs about PDT.

[Bug c++/102916] New: cmath constexpr can lead to ODR violations/incorrect results

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

Bug ID: 102916
   Summary: cmath constexpr can lead to ODR violations/incorrect
results
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Darrell.Wright at gmail dot com
  Target Milestone: ---

Because many of the cmath functions are constexpr, even in conformance mode of
the compiler, this can lead to ODR issues.  It is detectable in C++20 and gives
incorrect results.

#include 

template
consteval auto foo( ) {
  if constexpr (requires {
  []() {}.template operator()<(F(), void(), 0)>();
}) {
return 0;
  } else { 
return 1;
}
}


auto a = foo<[]{ return std::sqrt( 4.0 ); }>( );

https://gcc.godbolt.org/z/M6zGTbTfM


gcc returns 0, clang/libstdc++ and MSVC return 1.

I believe that in conformance -std=c++20 -pedantic mode that gcc should not
mark these methods as constexpr

[Bug c++/102915] New: GCC allows a trailing requires clause on a non templated lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 102915
   Summary: GCC allows a trailing requires clause on a non
templated lambda
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

The following code should not be accepted, please correct me if I am wrong.

template
auto l = []() requires true {};

int main() { l<>(); }

https://godbolt.org/z/h8ndYs3x8

[Bug other/92435] % format codes for diagnostics are not documented in the GCC internals manual

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||qing.zhao at oracle dot com

--- Comment #5 from Eric Gallager  ---
This mailing list message says to look in the commentary in cp/error.c or
c/c-objc-common.c:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582162.html

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

Will Wray  changed:

   What|Removed |Added

 CC||wjwray at gmail dot com

--- Comment #6 from Will Wray  ---
Hit this in implementing P1997 array copy semantics (which generalizes
the char-array <- string-literal case to array <- array initialization).

Compiler Explorer link https://godbolt.org/z/vednE3bYz

The reshape_init_r code that ensadc points to is one problem.
The code effectively special-cases the C rule that allows optional
braces around a string-literal initializer:

  A brace-enclosed string-literal initializer has its braces stripped,
  but then the code does not account at all for nested designators
  (as a recursive call to reshape_init would or should do).

This can be seen in the way that bogus nested designators are ignored:

struct C {char a[2];}

C y = {{.bogus="y"}}; // Invalid, g++ accepts
C z = {{[0]="z"}};// Invalid, g++ accepts (pedantic warning GNU [0])

(so the 'solution' of adding braces is misleading, non-standard, non-portable).

Then, in placing the designator correctly outside the braces, it is not
matched with the brace-enclosed initializer (haven't tracked down why yet):

C w = {.a={"w"}};  // Valid, g++ rejects designated braced
   // (gcc C accepts) (other C++ compilers accept)

A second problem is that the 'matching' of designator to initializer is
brittle even without optional braces; only the exactly-matching char-array
type (i.e. and extent) is accepted in an unbraced string literal:

C u = {.a="u"}; // Valid, designated char[2] literal for char[2] field
C r = {.a=""};  // Valid, g++ rejects designated char[1] for char[2]

A workaround is to match the size of the char array by padding with zeros:

C r = {.a="\0"};

I've spent over a day trying to isolate the 'matching' issue -
could do with assist from a designated-initializer mechanic.

[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.3
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2021-10-24
 Ever confirmed|0   |1

[Bug target/102914] spurious warnings are emitted on ARM about non-delegitimized UNSPEC UNSPEC_TLS

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

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

--- Comment #1 from Andrew Pinski  ---
This warning only happens with checking turned on which is the default for
building off the trunk.

[Bug target/102914] New: spurious warnings are emitted on ARM about non-delegitimized UNSPEC UNSPEC_TLS

[ardb at kernel dot org via Gcc-bugs]

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

Bug ID: 102914
   Summary: spurious warnings are emitted on ARM about
non-delegitimized UNSPEC UNSPEC_TLS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ardb at kernel dot org
  Target Milestone: ---
Target: ARM

The Linux/ARM kernel uses __builtin_thread_pointer() to access the TPIDRURO TLS
register, which triggers warning such as this one when using GCC 12.0.0. The
warning does not appear with 11.2


/home/ard/linux/init/calibrate.c: In function ‘calibrate_delay’:
/home/ard/linux/init/calibrate.c:275:6: note: non-delegitimized UNSPEC
UNSPEC_TLS (17) found in variable location
  275 | void calibrate_delay(void)
  |  ^~~

This appears to be triggered by the presence of notes in the RTL such as the
one below:

(note 1826 74 76 2 (var_location this_cpu (mem:SI (plus:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TLS)
(const_int 8 [0x8])) [5 MEM[(struct thread_info *)cur_24].cpu+0 S4
A64])) NOTE_INSN_VAR_LOCATION)

which are generated from dereferences of the (struct thread_info *) pointer
which is initialized from __builtin_thread_pointer().

(insn 50 2215 2217 2 (set (reg/v/f:SI 3 r3 [orig:124 cur ] [124])
(unspec:SI [
(const_int 0 [0])
] UNSPEC_TLS))
"/home/ard/linux/arch/arm/include/asm/current.h":36:8 401 {load_tp_hard}
 (expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0])
] UNSPEC_TLS)
(nil)))

(insn 54 2226 1499 2 (set (reg/v:SI 2 r2 [orig:125 this_cpu ] [125])
(mem:SI (plus:SI (reg/v/f:SI 3 r3 [orig:124 cur ] [124])
(const_int 8 [0x8])) [5 MEM[(struct thread_info *)cur_24].cpu+0
S4 A64])) "/home/ard/linux/init/calibrate.c":279:6 990 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg/v/f:SI 3 r3 [orig:124 cur ] [124])
(nil)))

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #13 from Dominique d'Humieres  ---
Duplicate of pr102685, fixed by r12-4452?

[Bug fortran/99183] [9/10/11 Regression] Incompatible Runtime types

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #4 from Dominique d'Humieres  ---
> This seems to have been fixed between r12-4097 and r12-4638.

Duplicate of pr102745, fixed by r12-4464?

[Bug fortran/100970] ICE in output_constructor_regular_field, at varasm.c:5514

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
This seems to have been fixed before r12-4638.

[Bug fortran/99183] [9/10/11 Regression] Incompatible Runtime types

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|Incompatible Runtime types  |[9/10/11 Regression]
   ||Incompatible Runtime types

--- Comment #3 from Dominique d'Humieres  ---
This seems to have been fixed between r12-4097 and r12-4638.

[Bug libstdc++/102912] Not full support of const arguments in std::variant

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #1 from 康桓瑋  ---
*** Bug 102913 has been marked as a duplicate of this bug. ***

[Bug libstdc++/102913] variant_construct_single should not remove the const qualifier of Up

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #1 from 康桓瑋  ---
Dup.

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

[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type

[fchelnokov at gmail dot com via Gcc-bugs]

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

Fedor Chelnokov  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Fedor Chelnokov  ---
Thanks for TC's explanation! This is an equivalent code to the question, but
without lambdas: gcc.godbolt.org/z/38T35Yfvs 

GCC is correct in processing the original code, closing the issue.

[Bug fortran/92701] ICE assigning to assumed rank derived type component

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #3 from Dominique d'Humieres  ---
This seems to have been fixed between r11-4933 and r11-6947 and back ported to
gcc10.

[Bug libstdc++/102913] New: variant_construct_single should not remove the const qualifier of Up

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 102913
   Summary: variant_construct_single should not remove the const
qualifier of Up
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

>From https://stackoverflow.com/questions/69696170:

variant#L568:

  template
_GLIBCXX20_CONSTEXPR
void
__variant_construct_single(_Tp&& __lhs, _Up&& __rhs_mem)
{
  using _Type = __remove_cvref_t<_Up>;

This should be using _Type = remove_reference_t<_Up>.

#include 
#include 

int main() {
  using var_t = std::variant;
  var_t v;
  var_t v2(v);
}

https://godbolt.org/z/zaov3GxdY

[Bug libstdc++/102912] New: Not full support of const arguments in std::variant

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102912
   Summary: Not full support of const arguments in std::variant
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program is valid:
```
#include 
#include 

using S = std::variant;

int main() {
S s(1);
S u = s;

S v("abc");
S w = v;
}
```
but its compilation in GCC results in a long error:
```
In file included from :2:
/opt/compiler-explorer/gcc-trunk-20211024/include/c++/12.0.0/variant: In
instantiation of 'constexpr std::__detail::__variant::_Variadic_union<_First,
_Rest ...>::_Variadic_union(std::in_place_index_t<_Np>, _Args&& ...) [with long
unsigned int _Np = 1; _Args = {const int&}; _First = const
std::__cxx11::basic_string; _Rest = {}]':
/opt/compiler-explorer/gcc-trunk-20211024/include/c++/12.0.0/variant:409:4:  
required from 'constexpr std::__detail::__variant::_Variadic_union<_First,
_Rest ...>::_Variadic_union(std::in_place_index_t<_Np>, _Args&& ...) [with long
unsigned int _Np = 2; _Args = {const int&}; _First = const int; _Rest = {const
std::__cxx11::basic_string, std::allocator
>}]'
/opt/compiler-explorer/gcc-trunk-20211024/include/c++/12.0.0/bits/stl_construct.h:119:7:
  required from 'constexpr void std::_Construct(_Tp*, _Args&& ...) [with _Tp =
std::__detail::__variant::_Variadic_union, std::allocator >
>; _Args = {const std::in_place_index_t<2>&, const int&}]'
...
Demo: https://gcc.godbolt.org/z/ocajj3aao

Related discussion: https://stackoverflow.com/q/69696170/7325599
```

[Bug sanitizer/102911] AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #2 from H.J. Lu  ---
The backtrace:

(gdb) bt
#0  __sanitizer::CheckFailed (
file=0xf7b17af4
"/export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_malloc_linux.cpp",
line=46, 
cond=0xf7b17ac0 "((allocated_for_dlsym)) < ((kDlsymAllocPoolSize))", 
v1=1057, v2=1024)
at
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:68
#1  0xf7ababf3 in AllocateFromLocalPool (size_in_bytes=)
at
/export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_malloc_linux.cpp:46
#2  __interceptor_malloc (size=)
at
/export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127
#3  0xf7fe2475 in malloc (size=155) at ../include/rtld-malloc.h:56
#4  __GI__dl_exception_create_format (exception=exception@entry=0xccc4, 
objname=0xf7fc0550
"/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/asan/.libs/libasan.so.8",
 
fmt=fmt@entry=0xf7ff2f11 "undefined symbol: %s%s%s") at dl-exception.c:157
#5  0xf7fd508b in _dl_lookup_symbol_x (undef_name=0xf7b14d64 "crypt_r", 
undef_map=0xf7fc05e0, ref=, symbol_scope=, 
version=0x0, type_class=0, flags=0, skip_map=0xf7fc05e0) at dl-lookup.c:877
#6  0xf7960553 in do_sym (handle=, name=0xf7b14d64 "crypt_r", 
who=who@entry=
--Type  for more, q to quit, c to continue without paging--
igned long*, unsigned long, unsigned long)+38>, vers=0x0, flags=2) at
dl-sym.c:146
#7  0xf79609f4 in _dl_sym (handle=, name=, 
who=0xf7af8b86 <__interception::InterceptFunction(char const*, unsigned
long*, unsigned long, unsigned long)+38>) at dl-sym.c:195
#8  0xf786c617 in dlsym_doit (a=0xcf60) at dlsym.c:40
#9  0xf7960c28 in __GI__dl_catch_exception (exception=, 
exception@entry=0xcea4, operate=, 
operate@entry=0xf786c5f0 , args=, 
args@entry=0xcf60)
at /export/ssd/git/gitlab/x86-glibc/elf/dl-error-skeleton.c:208
#10 0xf7960ce3 in __GI__dl_catch_error (objname=0xcf28, 
errstring=0xcf2c, mallocedp=0xcf27, 
operate=0xf786c5f0 , args=0xcf60)
at /export/ssd/git/gitlab/x86-glibc/elf/dl-error-skeleton.c:227
#11 0xf7fea102 in _rtld_catch_error (objname=0xcf28, errstring=0xcf2c, 
mallocedp=0xcf27, operate=0xf786c5f0 , args=0xcf60)
at /export/ssd/git/gitlab/x86-glibc/elf/dl-error-skeleton.c:260
#12 0xf786bf1a in _dlerror_run (operate=, 
operate@entry=0xf786c5f0 , args=, 
args@entry=0xcf60) at dlerror.c:138
#13 0xf786c696 in dlsym_implementation (dl_caller=, 
name=0xf7b14d64 "crypt_r", handle=0x) at dlsym.c:54
#14 ___dlsym (handle=0x, name=0xf7b14d64 "crypt_r") at dlsym.c:68
#15 0xf7af8b86 in __interception::GetFuncAddr (wrapper_addr=4154798864, 
name=0xf7b14d64 "crypt_r")
at
/export/gnu/import/git/sources/gcc/libsanitizer/interception/interception_linux.cpp:42
#16 __interception::InterceptFunction (name=0xf7b14d64 "crypt_r", 
ptr_to_real=0xf7b908d8 <__interception::real_crypt_r>, func=4154798864, 
wrapper=4154798864)
at
/export/gnu/import/git/sources/gcc/libsanitizer/interception/interception_linux.cpp:61
#17 0xf7ab6c1b in InitializeCommonInterceptors ()
at
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:10463
#18 __asan::InitializeAsanInterceptors ()
at
/export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_interceptors.cp--Type
 for more, q to quit, c to continue without paging--
p:619
#19 0xf7ac988e in __asan::AsanInitInternal ()
at /export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_rtl.cpp:444
#20 0xf7fdb29d in _dl_init (main_map=, argc=1, argv=0xd0e4, 
env=0xd0ec) at dl-init.c:102
#21 0xf7fc90fa in _dl_start_user ()
   from
/export/build/gnu/tools-build/glibc-32bit-cet-gitlab/build-i686-linux/elf/ld-linux.so.2
(gdb) 

Is there a memory after glibc 2.33 which doesn't have this problem?

[Bug tree-optimization/102908] [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again by r12-4598

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582419.html

--- Comment #4 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582419.html

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #12 from Dominique d'Humieres  ---
As for r12-4638 the tests are now rejected whit

Error: The shape of component 'c' in the structure constructor at (1) differs
from the shape of the declared component for dimension 1 (2/1)

So this old PR could probably be closed as FIXED.

[Bug c++/102514] The allocation function shall not be called when existing an erroneous expression in noptr-new-declarator

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm, clang, GCC, ICC and MSVC all have the same behavior for the testcase.

[Bug bootstrap/102828] [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker
   Keywords||build, internal-improvement

[Bug c/88790] No warning for misleading indentation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |c
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-24

--- Comment #5 from Andrew Pinski  ---
Confirmed. Both the C and C++ front-ends don't warn.  Note even clang does not
warn.

[Bug c++/102846] Misleading suggestion to include cassert

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-24

--- Comment #2 from Andrew Pinski  ---
Confirmed,
Clang message is even funnier:
:15:21: error: use of undeclared identifier 'assert'; did you mean
'__assert'?

[Bug demangler/102851] Failure to demangle c++ symbol

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

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

--- Comment #1 from Andrew Pinski  ---
Do you have the C++ preprocessed source that produces this mangled symbol?

The lambda part might be causing the difference between LLVM and GCC and such.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

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

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

Bug 102909 Summary: Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909

   What|Removed |Added

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

[Bug c/44677] Warn for variables incremented but not used

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mytbk920423 at gmail dot com

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

[Bug c/102909] Missing -Wunused-but-set-variable warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 44677.

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

[Bug fortran/92701] ICE assigning to assumed rank derived type component

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
The testcase no longer ICEs on mainline head.  Just mark this issue fixed, or
would it be useful to identify what fixed it?