[Bug target/105052] New: Incorrect constraint on SSSE3 split patterns with MMX operands

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

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

Bug ID: 105052
   Summary: Incorrect constraint on SSSE3 split patterns with MMX
operands
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

define_insn_and_split "ssse3_phwv4hi3"

and

define_insn_and_split "ssse3_phdv2si3"

have the Yv register constraint:

(define_register_constraint "Yv"
 "TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS : NO_REGS"
 "@internal For AVX512VL, any EVEX encodable SSE register
(@code{%xmm0-%xmm31}), otherwise any SSE register.")

But these instructions aren't available with EVEX encoding.  The x register
constraint should be used.

[Bug tree-optimization/105051] consider not combining malloc + memset to calloc when inside calloc itself

[godmar at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Godmar Back  ---
Thank you for your reply.  

To make sure I understand, the only work-around is to completely disable all
builtins (as in -fno-builtin), or is using `-fno-builtin-memset` as I proposed
sufficient?

I'm not sure why this bug is invalid, either. To me, applying this optimization
inside `calloc` seems invalid.

[Bug middle-end/78074] gcc-6.2.0 miscompiles calloc reimplementation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||godmar at gmail dot com

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

[Bug tree-optimization/105051] consider not combining malloc + memset to calloc when inside calloc itself

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 78074.

Also the code to do this has been there since 2014 (8 years ago) so your 18
year old calloc implementation has been broken for 8 years and it was 10 year
at the time it was broken.

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

[Bug tree-optimization/105051] New: consider not combining malloc + memset to calloc when inside calloc itself

[godmar at gmail dot com via Gcc-bugs]

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

Bug ID: 105051
   Summary: consider not combining malloc + memset to calloc when
inside calloc itself
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: godmar at gmail dot com
  Target Milestone: ---

gcc 8.5.0 (and later) just broke our 18-year-old calloc implementation, which
goes like this:

void *
calloc (size_t a, size_t b)
{
  /* Calculate block size and make sure it fits in size_t. */
  size_t size = a * b;

  /* Allocate and zero memory. */
  void *p = malloc (size);
  if (p != NULL)
memset (p, 0, size);

  return p;
}

by producing this ingenuous code sequence:

calloc:
imulq   %rsi, %rdi
movl$1, %esi
jmp calloc


I believe that this is due to an optimization whereby a sequence of malloc
followed by memset is transformed into a call to calloc.

My suggestion would be to suppress this optimization inside a function that is
itself called calloc as it leads to an infinite loop.

I'm also curious what the proper work-around is.  Is it `-fno-builtin-memset`?

I discovered this in 8.5.0 but Godbolt says it's present in the trunk as of
now:
https://godbolt.org/z/MKMT98qnr

This may be related to Bug #83022

[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

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

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

--- Comment #9 from David Malcolm  ---
(In reply to Richard Biener from comment #1)
> Does not enabling sanitizer improve things?

Removing the sanitizer options speeds up the non-analyzer part of the build,
reducing the overall wallclock time of cc1 from about 36s to 21s; the
-fanalyzer part of that remains steady at about 16s.

Without -fanalyzer, cc1 wallclock is:
  with sanitizer:~18s
  without sanitizer:  ~5s

[Bug ada/66390] Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases

[tornenvi at gmail dot com via Gcc-bugs]

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

tornenvi at gmail dot com changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #5 from tornenvi at gmail dot com ---
Appears to have been fixed in 2016 with commit
 c7518e6f52aad178875818666fcfc92ff4e08e8f

[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
At this point, the analyzer is taking less than half of the wallclock time of
cc1 on this file, so I'm declaring success.

[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:5f6197d7c197f9d2b7fb2e1a19dac39a023755e8

commit r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8
Author: David Malcolm 
Date:   Thu Mar 24 20:58:10 2022 -0400

analyzer: add region::tracked_p to optimize state objects [PR104954]

PR analyzer/104954 tracks that -fanalyzer was taking a very long time
on a particular source file in the Linux kernel:
  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

One issue occurs with the repeated use of dynamic debug lines e.g. via
the DC_LOG_BANDWIDTH_CALCS macro, such as in print_bw_calcs_dceip in
drivers/gpu/drm/amd/display/dc/calcs/calcs_logger.h:

 
DC_LOG_BANDWIDTH_CALCS("#");
  DC_LOG_BANDWIDTH_CALCS("struct bw_calcs_dceip");
 
DC_LOG_BANDWIDTH_CALCS("#");

  [...snip dozens of lines...]

  DC_LOG_BANDWIDTH_CALCS("[bw_fixed] dmif_request_buffer_size: %d",
 bw_fixed_to_int(dceip->dmif_request_buffer_size));

When this is configured to use __dynamic_pr_debug, each of these becomes
code like:

  do {
static struct _ddebug __attribute__((__aligned__(8)))
__attribute__((__section__("__dyndbg"))) __UNIQUE_ID_ddebug277 = {
  [...snip...]
};
if (arch_static_branch(&__UNIQUE_ID_ddebug277.key, false))
  __dynamic_pr_debug(&__UNIQUE_ID_ddebug277, [...the message...]);
  } while (0);

The analyzer was naively seeing each call to __dynamic_pr_debug, noting
that the __UNIQUE_ID_ object escapes.  At each call, as successive
__UNIQUE_ID_ object escapes, there are N escaped objects, and thus N
need clobbering, and so we have O(N^2) clobbering of escaped objects
overall,
leading to huge amounts of pointless work: print_bw_calcs_data has 225
uses of DC_LOG_BANDWIDTH_CALCS, many of which are in loops.

This patch adds a way to identify declarations that aren't interesting
to the analyzer, so that we don't attempt to create binding_clusters
for them (i.e. we don't store any state for them in our state objects).
This is implemented by adding a new region::tracked_p, implemented for
declarations by walking the existing IPA data the first time the
analyzer sees a declaration, setting it to false for global vars that
have no loads/stores/aliases, and "sufficiently safe" address-of
ipa-refs.

The patch gives a large speedup of -fanalyzer on the above kernel
source file:
   Before  After
Total cc1 wallclock time:180s36s
analyzer wallclock time: 162s17s
% spent in analyzer:  90%47%

gcc/analyzer/ChangeLog:
PR analyzer/104954
* analyzer.opt (-fdump-analyzer-untracked): New option.
* engine.cc (impl_run_checkers): Handle it.
* region-model-asm.cc (region_model::on_asm_stmt): Don't attempt
to clobber regions with !tracked_p ().
* region-model-manager.cc (dump_untracked_region): New.
(region_model_manager::dump_untracked_regions): New.
(frame_region::dump_untracked_regions): New.
* region-model.h (region_model_manager::dump_untracked_regions):
New decl.
* region.cc (ipa_ref_requires_tracking): New.
(symnode_requires_tracking_p): New.
(decl_region::calc_tracked_p): New.
* region.h (region::tracked_p): New vfunc.
(frame_region::dump_untracked_regions): New decl.
(class decl_region): Note that this is also used fo SSA names.
(decl_region::decl_region): Initialize m_tracked.
(decl_region::tracked_p): New.
(decl_region::calc_tracked_p): New decl.
(decl_region::m_tracked): New.
* store.cc (store::get_or_create_cluster): Assert that we
don't try to create clusters for base regions that aren't
trackable.
(store::mark_as_escaped): Don't mark base regions that we're not
tracking.

gcc/ChangeLog:
PR analyzer/104954
* doc/invoke.texi (Static Analyzer Options): Add
-fdump-analyzer-untracked.

gcc/testsuite/ChangeLog:
PR analyzer/104954
* gcc.dg/analyzer/asm-x86-dyndbg-1.c: New test.
* gcc.dg/analyzer/asm-x86-dyndbg-2.c: New test.
* gcc.dg/analyzer/many-unused-locals.c: New test.
* gcc.dg/analyzer/untracked-1.c: New test.
* gcc.dg/analyzer/unused-local-1.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:319ba7e241e7e21f9eb481f075310796f13d2035

commit r12-7808-g319ba7e241e7e21f9eb481f075310796f13d2035
Author: Avinash Sonawane 
Date:   Tue Mar 22 07:32:44 2022 +0530

Docs: Document that taint analyzer checker disables some warnings
[PR103533]

gcc/ChangeLog:
PR analyzer/103533
* doc/invoke.texi: Document that enabling taint analyzer
checker disables some warnings from `-fanalyzer`.

Signed-off-by: Avinash Sonawane 

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Alan Modra  ---
So, similar code to what we have in rs6000_call_aix to handle
  if ((INTVAL (cookie) & CALL_LONG) != 0
  && GET_CODE (func_desc) == SYMBOL_REF)
should be added to rs6000_sibcall_aix, I think.

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Alan Modra  ---
I'm sorry, I forgot exactly what was happening when I talked about this on the
call.  What I should have said is that -mlongcall code is correct but is
missing a sibcall optimisation.  -fno-plt code (after removing the assert or
using your patch) is incorrect.  A direct call is wrong, because it may require
a plt call stub.  gcc ought to be producing an inline plt call.  Change the
testcase to

void foo();

void bar() {
   foo();
   foo();
}

to see what I mean.  The asm output is

mflr 0
std 0,16(1)
stdu 1,-96(1)
.cfi_def_cfa_offset 96
.cfi_offset 65, 16
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
mtctr 12
.reloc .-4,R_PPC64_PLTSEQ,foo
.reloc .,R_PPC64_PLTCALL_NOTOC,foo
bctrl
addi 1,1,96
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
b foo@notoc

That "b foo@notoc" ought to be
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
mtctr 12
.reloc .-4,R_PPC64_PLTSEQ,foo
.reloc .,R_PPC64_PLTCALL_NOTOC,foo
bctr

[Bug c++/105050] New: error: expression '' is not a constant expression

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

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

Bug ID: 105050
   Summary: error: expression '' is not a constant
expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template
  struct expected
  {
void _M_swap_val(expected&) { }

void _M_swap_unex(expected&) { }

void _M_swap_val_unex(expected&) { }

bool _M_has_value = true;

constexpr void
swap(expected& __x)
{
  if (this->has_value())
  {
if (__x.has_value())
  this->_M_swap_val(__x);
else
  this->_M_swap_val_unex(__x);
  }
  else
  {
if (__x.has_value())
  __x._M_swap_val_unex(*this);
else
  this->_M_swap_unex(__x);
  }
}

constexpr bool has_value() const noexcept { return this->_M_has_value; }
  };

constexpr bool
test_swap()
{
  expected e1, e2;
  e1.swap(e2);

  return true;
}

static_assert(test_swap());



This doesn't give a very helpful diagnostic:

x.ii:43:24: error: non-constant condition for static assertion
   43 | static_assert(test_swap());
  |   ~^~
x.ii:43:24:   in 'constexpr' expansion of 'test_swap()'
x.ii:38:10: error: 'constexpr void expected<_Tp>::swap(expected<_Tp>&) [with
_Tp = int]' called in a constant expression
   38 |   e1.swap(e2);
  |   ~~~^~~~
x.ii:13:5: note: 'constexpr void expected<_Tp>::swap(expected<_Tp>&) [with _Tp
= int]' is not usable as a 'constexpr' function because:
   13 | swap(expected& __x)
  | ^~~~
x.ii:15:7: error: expression '' is not a constant expression
   15 |   if (this->has_value())
  |   ^~


The problem is that the _M_swap_val, _M_swap_unex and _M_swap_val_unex
functions are not constexpr, but the diagnostic doesn't make that obvious.

[Bug c++/104284] [9/10/11 Regression] ICE: unexpected expression '' of kind implicit_conv_expr since r9-6073-ge8b3c1bc3ba22dcf

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE:
   |ICE: unexpected expression  |unexpected expression
   |'' of kind   |'' of kind
   |implicit_conv_expr since|implicit_conv_expr since
   |r9-6073-ge8b3c1bc3ba22dcf   |r9-6073-ge8b3c1bc3ba22dcf

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/104284] [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr since r9-6073-ge8b3c1bc3ba22dcf

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:9fdac7e16c940fb6264e6ddaf99c761f1a64a054

commit r12-7805-g9fdac7e16c940fb6264e6ddaf99c761f1a64a054
Author: Marek Polacek 
Date:   Thu Mar 17 14:39:37 2022 -0400

c++: ICE with template code in constexpr [PR104284]

Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.

It happens because we're performing build_vec_init while processing
a template, which calls get_temp_regvar which creates an INIT_EXPR.
This INIT_EXPR's RHS contains an rvalue conversion so we create an
IMPLICIT_CONV_EXPR.  Its operand is not type-dependent and the whole
INIT_EXPR is not type-dependent.  So we call build_non_dependent_expr
which, with -fchecking=2, calls fold_non_dependent_expr.  At this
point the expression still has an IMPLICIT_CONV_EXPR, which ought to
be handled in instantiate_non_dependent_expr_internal.  However,
tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call
tsubst_copy which does nothing when args is null.  So we fail to
replace the IMPLICIT_CONV_EXPR and ICE.

The problem is that we call build_vec_init in a template in the
first place.  We can avoid doing so by checking p_t_d before
calling build_aggr_init in check_initializer.

PR c++/104284

gcc/cp/ChangeLog:

* decl.cc (check_initializer): Don't call build_aggr_init in
a template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-104284-1.C: New test.
* g++.dg/cpp1y/constexpr-104284-2.C: New test.
* g++.dg/cpp1y/constexpr-104284-3.C: New test.
* g++.dg/cpp1y/constexpr-104284-4.C: New test.

[Bug tree-optimization/105049] New: ICE: in build_vector_from_val, at tree.cc:2119 with -O -fno-tree-forwprop

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105049
   Summary: ICE: in build_vector_from_val, at tree.cc:2119 with -O
-fno-tree-forwprop
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-forwprop testcase.c 
during GIMPLE pass: veclower2
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in build_vector_from_val, at
tree.cc:2119
6 | foo (void)
  | ^~~
0x8077e9 build_vector_from_val(tree_node*, tree_node*)
/repo/gcc-trunk/gcc/tree.cc:2119
0x15ff0aa expand_vector_operations_1
/repo/gcc-trunk/gcc/tree-vect-generic.cc:2176
0x15ff0aa expand_vector_operations
/repo/gcc-trunk/gcc/tree-vect-generic.cc:2372
0x15ff0aa execute
/repo/gcc-trunk/gcc/tree-vect-generic.cc:2418
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> 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-r12-7804-20220324143116-g346ab5a54a8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7804-20220324143116-g346ab5a54a8-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220324 (experimental) (GCC)

[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode

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

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

--- Comment #31 from Jonathan Wakely  ---
std::construct_at and std::destroy_at are in  alongside
std::_Construct and std::_Destroy. But the latter need iterator category
definitions for destroying sequences. std::construct_at and std::destroy_at
have no dependencies. They could be moved into  or
 or something smaller. This would benefit  (and
maybe other headers).

[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

--- Comment #10 from Elliott M  ---
Eyes must have glazed over when trying to find other reports.  105048 is indeed
a duplicate.

Another option might be "R" for architectures which haven't
already grabbed "R" for something else.  I notice Clang though doesn't appear
to have "R" implemented which seems to suggest actual uses of the current
definition of "R" are rare.

There are multiple calls for this feature, any chance of an implementation?

[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ehem+gccbugs at m5p dot com

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

[Bug c/105048] [enhancement] Allow specific register constraints

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

Elliott M  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #6 from Elliott M  ---
That is true, but you're still forcing the creation of an extra variable which
makes the macro less safe.  Notably `FOO(dummy)` will fail, whereas if inputs
could be marked clobbered the macro would only need a variable for return (for
which the macro name itself can be used, since that is guaranteed not to cause
problems).

[Bug c/105048] [enhancement] Allow specific register constraints

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

--- Comment #1 from Elliott M  ---
Created attachment 52684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52684=edit
Sample of with and without this feature

Hmm, Bugzilla attachment during initial submission failed.

[Bug c/105048] New: [enhancement] Allow specific register constraints

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

Bug ID: 105048
   Summary: [enhancement] Allow specific register constraints
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: inline-asm
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ehem+gccbugs at m5p dot com
  Target Milestone: ---

Using local register variables to constrain assembly-language inputs and
outputs to particular registers is really ugly.  Better to have explicit syntax
for this.  I would suggesting using "R" for this.

Using "R" conflicts with x86, but x86 effectively already has this since "a",
"b", "c", "d", "S", "D" covers most of the registers used for calling
conventions.  I though also note Clang doesn't appear to have implemented "R"
which suggests this has rarely, if ever, been used. (another letter could be
used on x86, or it might be possible to repurpose)

This is particularly valuable for interfacing with systems using foreign
calling conventions.

The example is how one might interface with a hypervisor on ARM64.  This seems
valuable as the register specification is a feature of the
inline-assembly-language, not a feature of the variable.

This could result in superior output, by avoiding copies.  In particular
`hypercall_inline()` might well end up with 5 extra `mov` instructions (plus a
call and return) which are never optimized out, whereas `hypercall_macro()` is
rather likely to produce a single instruction.

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

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

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

--- Comment #5 from Peter Bergner  ---
(In reply to Alan Modra from comment #4)
> Do check that the result is not a direct call.  I think I was wrong to say
> the assert could be removed (or modified as you have done).

I'm assuming you mean check that we DO have a direct call.

When we talked offline, you said you were worried about what happens when we
use -mlongcall with this test csae.  When I use that option, we never end up
calling rs6000_sibcall_aix(), so that option basically disables sibling calls
altogether.  I believe if we call rs6000_sibcall_aix(), we know we have a
direct call that is also a valid sibling call and the assert is just confirming
that.

Before pcrel, valid sibling calls required the caller and callee to have the
same TOC value (which is what that assert was verifying) because the TOC
restore is done in the caller and not the callee and if we do a sibling call,
we'll skip the TOC restore in the caller, which only works if the callee has
the same TOC value.

Now with pcrel, the caller doesn't use r2 as a TOC pointer at all and doesn't
expect or need it to be restored.  Additionally, callers to a pcrel function
don't expect r2 to be preserved either.  This allows pcrel callers to sibling
call callees we couldn't before, so I think we do just want to relax the assert
to verify we have the same TOC value only when the caller is not pcrel.

Given we only call rs6000_sibcall_aix() with direct calls that are valid for
sibling calls, do you agree my patch above is ok or do you see some other issue
I'm not thinking of?

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

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

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

--- Comment #5 from Jakub Jelinek  ---
Sure, but it doesn't force the input to be an lvalue.
You can add variables even in macros in statement expressions,
#define FOO(whatever) \
  ({ int dummy; __asm ("" : "=c" (dummy) : ...); retval; })

[Bug c++/105047] New: invalid non-dependent call to non-static member of the current instantiation not rejected ahead of time

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

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

Bug ID: 105047
   Summary: invalid non-dependent call to non-static member of the
current instantiation not rejected ahead of time
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

Accepts-invalid testcase:

template
class A {
  void f();

  static void g() {
f();  // invalid because 'this' unavailable
  }

  void h() {
f(0); // invalid because wrong # of arguments
  }
};

We probably should be able to reject both calls to f ahead of time.

[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 52683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52683=edit
Tentative patch

This patch provides an error message somewhat similar to NAG, e.g.

pr50549.f90:13:6:

   13 |   u=t(p1)! different character length
  |  1
Error: Unequal character lengths (2/1) for pointer component 'p2' in
constructor at (1)


Regtesting looks fine.

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

Elliott M  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #4 from Elliott M  ---
I had guessed this was exposing internals, I had hopes those were the internals
from a score of years ago and could readily be resolved now.

This is valuable for interfacing with things which have calling conventions
distinct enough not to work with pure-C, but similar enough to only need 1-2
assembly instructions.  Notably avoiding lvalues is valuable for things which
could otherwise fit into macros.

Jakub Jelinek, your example fails, `dummy` is an lvalue.  Notably if this is
part of a `#define SOME_MACRO(foo)`, then `SOME_MACRO(dummy)` won't work.

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #5)
> it's not *just* a glibc feature; Darwin Libc uses the same macro, too, for
> example

Yes and Darwin (and FreeBSD, OpenBSD, NetBSD, etc.) should document it in their
libc too.

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
it's not *just* a glibc feature; Darwin Libc uses the same macro, too, for
example

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Note, it certainly doesn't force them to be lvalues.
You can do something like:
  int dummy;
  __asm ("whatever" : "=c" (dummy) : "0" (256) : "edi");
to say you want rvalue 256 in 32-bit %ecx register and say that the %ecx
register is clobbered in the inline asm and %edi too.

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
And you provide an example of why you want this improvement?

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ra
  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
Basically extended inline-asm in gcc exposes the internals representation to
the users. I can expand on this on why things like this request is bad for the
representation and all.

[Bug c/105046] New: [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com via Gcc-bugs]

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

Bug ID: 105046
   Summary: [enhancement] Allow inline-assembly clobbers to
overlap inputs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: inline-asm
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ehem+gccbugs at m5p dot com
  Target Milestone: ---

From:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers

"Clobber descriptions may not in any way overlap with an input or output
operand. For example, you may not have an operand describing a register class
with one member when listing that register in the clobber list. Variables
declared to live in specific registers (see Explicit Register Variables) and
used as asm input or output operands must have no part mentioned in the clobber
description. In particular, there is no way to specify that input operands get
modified without also specifying them as output operands."

Inline assembly language SHOULD be able to clobber inputs.  Forcing clobbered
inputs to be declared as outputs (which also forces them to be lvalues) is a
recipe for introducing bugs into programs.

The documentation leaves me with the impression this restriction was introduced
with the initial implementation of extended inline assembly language (likely
pre-2000).  I suspect improvements in the back-end likely mean this can be
readily removed.

I'm unsure about allowing outputs to overlap clobbers.  If the clobber list is
treated as a list of registers/memory which are modified, then it would make
sense to allow outputs to be clobbered.  Issue is whether this is allowing
programmers to be sloppy and cause more bugs, versus making the job easier.

Alternatively a '-' prefix could be added for marking inputs which are
clobbered in the assembly language.  This could be a nicer expression, but
changes the language.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:346ab5a54a831ad9c78afcbd8dfe98e0e07e3070

commit r12-7804-g346ab5a54a831ad9c78afcbd8dfe98e0e07e3070
Author: Jason Merrill 
Date:   Tue Mar 22 01:10:44 2022 -0400

c++: delayed parse DMI [PR96645]

With the changes for PR81359 and PR88368 to make get_nsdmi errors be
treated
as substitution failure, we have the problem that if we check
std::is_default_constructible for a complete class that still has unparsed
default member initializers, we get an answer (false) that will be wrong
once the DMIs have been parsed.  The traits avoid this problem for regular
incomplete classes by giving an error if the operand is incomplete; we
should do the same if get_nsdmi is going to fail due to unparsed DMI.

PR c++/96645

gcc/cp/ChangeLog:

* cp-tree.h (type_has_default_ctor_to_be_synthesized): Declare.
* class.cc (type_has_default_ctor_to_be_synthesized): New.
(type_has_non_user_provided_default_constructor_1): Support it.
(type_has_non_user_provided_default_constructor): Now a wrapper.
* method.cc (complain_about_unparsed_dmi): New.
(constructible_expr): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_constructible3.C: Expect error.
* g++.dg/ext/is_constructible7.C: New test.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #10 from Patrick Palka  ---
(In reply to Jason Merrill from comment #8)
> (In reply to Patrick Palka from comment #7)
> > IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
> > consteval call then we'll currently correctly accept/reject it ahead of
> > time, e.g.:
> 
> Right.  The problem we're hitting is that within a template we're trying to
> evaluate the immediate invocation inside build_over_call rather than when we
> return to e.g. finish_call_expr and build up the call to actually go into
> the template trees: if we fold_non_dependent_expr at that point instead, it
> should be fine.  The only problem with that is that there are a bunch of
> places that need to be changed.

That'd work for finish_call_expr and build_new_method call since they're given
the original arguments, but other callers e.g. build_new_op never see the
original arguments, so we wouldn't be able to do fold_non_dependent_expr from
there IIUC.  For build_new_op in particular, we'd have to instead
fold_non_dependent_expr from _its_ callers, the build_x_* class of functions, I
think..

[Bug c++/102990] [9/10/11 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
   |in tsubst_copy_and_build|tsubst_copy_and_build with
   |with NSDMI and double to|NSDMI and double to int
   |int conversion  |conversion

--- Comment #10 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/102990] [9/10/11/12 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

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

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

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-7803-gf0530882d99abc410bb080051aa04e5cea848f18
Author: Marek Polacek 
Date:   Tue Mar 22 18:42:27 2022 -0400

c++: FIX_TRUNC_EXPR in tsubst [PR102990]

This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().

The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into gcc_unreachable () in r258821 (see this thread:
).

In a template, we should never create a FIX_TRUNC_EXPR (that's what
conv_unsafe_in_template_p is for).  But in this test we are NOT in
a template when we call digest_nsdmi_init which ends up calling
convert_like, converting 1.0e+0 to int, so convert_to_integer_1
gives us a FIX_TRUNC_EXPR.

But then when we get to parsing f's parameters, we are in a template
when processing decltype(Helpers{}), and since r268321, when the
compound literal isn't instantiation-dependent and the type isn't
type-dependent, finish_compound_literal falls back to the normal
processing, so it calls digest_init, which does fold_non_dependent_init
and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and
therefore crash in tsubst_copy_and_build.

The fateful call to fold_non_dependent_init comes from massage_init_elt,
We shouldn't be calling f_n_d_i on the result of get_nsdmi.  This we can
avoid by eschewing calling f_n_d_i on CONSTRUCTORs; their elements have
already been folded.

PR c++/102990

gcc/cp/ChangeLog:

* typeck2.cc (massage_init_elt): Avoid folding CONSTRUCTORs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template22.C: New test.
* g++.dg/cpp0x/nsdmi-template23.C: New test.

[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'

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

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 52682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52682=edit
gcc12-pr103775.patch

This untested patch seems to work.

[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||frederik at gcc dot gnu.org,
   ||sandra at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #34 from Thomas Schwinge  ---
I'm totally lacking all context here ;-) -- but did see "OpenACC" mentioned,
so:

(In reply to Richard Biener from comment #33)
> I'll note the OpenACC folks were working on making gfortran preserve
> multi-dimensional array accesses

See Frederik's submission "Fortran: Delinearize array accesses",
,
primarily developed by Sandra Loosemore, with help from Tobias Burnus (from
what I remember).  Intended for discussion for GCC 13.

> not sure how they address this issue.  With
> a single dimension there's not much value in using ARRAY_REF over
> pointer arithmetic and dereference.

[Bug c++/105006] [12 Regression] ice: tree check: expected function_decl, have using_decl in maybe_push_used_methods, at cp/class.cc:1325

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed

[Bug c++/105045] New: [modules] Can't deduce defaulted template parameter

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 105045
   Summary: [modules] Can't deduce defaulted template parameter
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/3WMd4T48h.

`mod.cpp`:
```C++
export module mod;
export template void f(U) { }
```

`test.cpp`:
```C++
import mod;
int main() { f(0); }
```

Output:
```
test.cpp: In function 'int main()':
test.cpp:2:15: error: no matching function for call to 'f(int)'
2 | int main() { f(0); }
  |  ~^~~
In module mod, imported at /app/test.cpp:1:
mod.cpp:2:40: note: candidate: 'template void f@mod(U)'
2 | export template void f(U) { }
  |^
mod.cpp:2:40: note:   template argument deduction/substitution failed:
test.cpp:2:15: note:   couldn't deduce template parameter 'T'
2 | int main() { f(0); }
  |  ~^~~
```

[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Though, maybe it shouldn't be the duty of every pass to check this and instead
something like insn_invalid_p should reject those?

If so, shall we worry about that just when reload_completed?

[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I think this is a REE bug.
However inefficient (but we get that because of -Og and
-fno-forward-propagate),
(insn 12 39 13 2 (set (reg:SI 1 x1 [orig:93 _2 ] [93])
(zero_extend:SI (mem/c:QI (pre_modify:DI (reg/f:DI 0 x0 [114])
(plus:DI (reg/f:DI 0 x0 [114])
(const_int 16 [0x10]))) [1 u128_1+0 S1 A128])))
"pr103775.c":5:35 117 {*zero_extendqisi2_aarch64}
 (expr_list:REG_INC (reg/f:DI 0 x0 [114])
(nil)))
(insn 13 12 14 2 (set (reg:DI 0 x0 [orig:112 _2 ] [112])
(zero_extend:DI (reg:SI 1 x1 [orig:93 _2 ] [93]))) "pr103775.c":5:16
111 {*zero_extendsidi2_aarch64}
 (nil))
is valid, but turning that into:
(insn 12 39 44 2 (set (reg:DI 0 x0)
(zero_extend:DI (mem/c:QI (pre_modify:DI (reg/f:DI 0 x0 [114])
(plus:DI (reg/f:DI 0 x0 [114])
(const_int 16 [0x10]))) [1 u128_1+0 S1 A128])))
"pr103775.c":5:35 119 {*zero_extendqidi2_aarch64}
 (expr_list:REG_INC (reg/f:DI 0 x0 [114])
(nil)))
(insn 44 12 14 2 (set (reg:DI 1 x1)
(reg:DI 0 x0)) "pr103775.c":5:35 -1
 (nil))
is invalid, as one instruction can't set the same register multiple times.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

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

https://gcc.gnu.org/g:647537adefb34041cc2d44585252fd765cc0daae

commit r12-7802-g647537adefb34041cc2d44585252fd765cc0daae
Author: Patrick Palka 
Date:   Thu Mar 24 11:42:31 2022 -0400

c++: missing SFINAE for non-constant consteval calls [PR104620]

Here we weren't respecting SFINAE when evaluating a call to a consteval
function, which caused us to reject the new testcase below.  This patch
fixes this by making build_over_call use the SFINAE-friendly version of
cxx_constant_value.

This change causes us to no longer diagnose ahead of time a couple of
non-constant non-dependent consteval calls in consteval-if2.C with
-fchecking=2.  These errors were apparently coming from the call to
fold_non_dependent_expr in build_non_dependent_expr (for the RHS of the +=)
despite complain=tf_none being passed.  Now that build_over_call respects
the value of complain during constant evaluation of a consteval call,
the errors are gone.

That the errors are also gone without -fchecking=2 is a regression caused
by r12-7264-gc19f317a78c0e4 and is the subject of PR104620.  As described
in comment #5, I think it's basically an accident that we were diagnosing
these two calls correctly before r12-7264, so perhaps we can live without
these errors for GCC 12.  Thus this patch just XFAILs the two tests.

PR c++/104620

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use cxx_constant_value_sfinae
instead of cxx_constant_value to evaluate a consteval call.
* constexpr.cc (cxx_constant_value_sfinae): Add decl parameter
and pass it to cxx_eval_outermost_constant_expr.
* cp-tree.h (cxx_constant_value_sfinae): Add decl parameter.
* pt.cc (fold_targs_r): Pass NULL_TREE as decl parameter to
cxx_constant_value_sfinae.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/consteval-if2.C: XFAIL two dg-error tests where
the argument to the non-constant non-dependent consteval call is
wrapped by NON_DEPENDENT_EXPR.
* g++.dg/cpp2a/consteval30.C: New test.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 52681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52681=edit
gcc12-pr103691.patch

Untested FE patch.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #8 from Jason Merrill  ---
(In reply to Patrick Palka from comment #7)
> IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
> consteval call then we'll currently correctly accept/reject it ahead of
> time, e.g.:

Right.  The problem we're hitting is that within a template we're trying to
evaluate the immediate invocation inside build_over_call rather than when we
return to e.g. finish_call_expr and build up the call to actually go into the
template trees: if we fold_non_dependent_expr at that point instead, it should
be fine.  The only problem with that is that there are a bunch of places that
need to be changed.

[Bug c++/101906] Constant evaluation failure in concepts

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

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

--- Comment #2 from Patrick Palka  ---
FWIW one workaround is to use a class template instead of an alias template,
e.g.

  -template using voidify = void;
  +template struct voidify {};

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
gfc_get_derived_type sets the unlimited_entity flag for these, but I guess not
all unlimited entities should have the same TYPE_CANONICAL, e.g. on
subroutine foo (a, b, c, d, e, f)
  class(*) :: a
  class(*) :: b(:)
  class(*) :: c(:, :, :)
  class(*), pointer :: d
  class(*), pointer :: e(:)
  class(*), pointer :: f(:, :)
end subroutine
there are various RECORD_TYPEs.
So just adding a single tree to use for those would be wrong, thus I think
best would be really to register the unlimited entities in the derived type
list and handle them in gfc_compare_derived_types.  But I'm afraid I don't know
enough about this stuff to do this myself.

Tobias or Paul, could you please have a look?
This is a P1 bug and therefore GCC 12 blocker.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #7 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #4)
> This one is valid, but before your r12-7264 was incorrectly rejected because
> 8 * baz (0) etc. is wrapped in NON_DEPENDENT_EXPR,
> potential_constant_expression_1 recursed on the NON_DEPENDENT_EXPR operand,
> found it is ok but cxx_eval_constant_expression
> rejected the NON_DEPENDENT_EXPR.

Makes sense, similar to the #2 case in comment #5.

> Bet for the build_over_call
> processing_template_decl immediate_invocation_p code we need to punt
> silently if there is something we can't handle but fail loudly if we can
> handle everything but it is clearly always not a constant expression. 
> potential_constant_expression_1 isn't 100% accurate, there are cases where
> it gets stuff through.

IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
consteval call then we'll currently correctly accept/reject it ahead of time,
e.g.:

consteval int foo(int x) { return x; }

template
void bar(int x)
{
  constexpr int y = 0;
  foo(x); // error: 'x' is not a constant expression
  foo(y); // OK
  foo(x * 1); // no (ahead of time) error due to NON_DEPENDENT_EXPR
}

[Bug ipa/99309] [10/11/12 Regression] Segmentation fault with __builtin_constant_p usage at -O2

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

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

--- Comment #10 from Richard Biener  ---
The issue for FRE is that we have

   [local count: 10737416]:
  step.val = 610334368;
  value.val = 1;
  goto ; [100.00%]

   [local count: 1073741824]:
  # __1 = PHI <0(2), __11(4)>
  if (__1 != 100)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 1063004409]:
  __builtin_printf ("%d %d\n", 1, 610334368);
  m = step;
  _12 = m.val;
  _13 = __builtin_constant_p (_12);
  if (_13 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [local count: 1063004409]:
  __builtin_puts (&"normal"[0]);
  m ={v} {CLOBBER(eol)};
  __builtin_printf ("%d %d\n", 1, 610334368);
  __11 = __1 + 1;
  goto ; [100.00%]

   [count: 0]:
  __builtin_unreachable ();

and while the first FRE iteration correctly determines that m.val is 610334368
we then make the backedge of the loop executable and because we translated
the lookup expression from m.val to step.val we are refusing to handle loops
(the abort_on_visited argument to get_continuation_for_phi, set from
translated in walk_non_aliased_vuses).

I don't remember why I disregarded the fix in comment#3 of PR54498, a fix
along that line would enable CSE here.  The concern was probably
compile-time (but we limit the amount of alias queries done).

It's a bit late to do such change for GCC 12 I think.  I will queue this
for GCC 13.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #6 from Patrick Palka  ---
The reason that the two tests in constexpr-if2.C don't fail with -fchecking=2
after r12-7264 seems to be a latent bug.  The error comes from the call to
fold_non_dependent_expr in build_non_dependent_expr (which is guarded by
flag_checking > 1), despite passing complain=tf_none.  I think build_over_call
needs to use cxx_constant_value_sfinae instead of cxx_constant_value when
evaluating a consteval call...  I have a patch for this.

[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl

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

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

--- Comment #9 from Martin Liška  ---
You should see the difference in between -D_FORTIFY_SOURCE=2 and
-D_FORTIFY_SOURCE=3 in the attached pre-processed source files.

$ gcc fs2.i -c -O2 -Werror
$ gcc fs3.i -c -O2 -Werror
In file included from /usr/include/string.h:535,
 from libacl/__acl_to_any_text.c:25:
In function ‘strcpy’,
inlined from ‘__acl_to_any_text’ at libacl/__acl_to_any_text.c:90:3:
/usr/include/bits/string_fortified.h:79:10: error: ‘__builtin___strcpy_chk’
writing 1 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
   79 |   return __builtin___strcpy_chk (__dest, __src, __glibc_objsize
(__dest));
  | 
^   
cc1: all warnings being treated as errors

Note the warning exactly corresponds to the call that aborts during run-time.

[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl

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

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

--- Comment #8 from Martin Liška  ---
Created attachment 52680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52680=edit
libacl/__acl_to_any_text.c with FS == 3

[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl

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

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

--- Comment #7 from Martin Liška  ---
Created attachment 52679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52679=edit
libacl/__acl_to_any_text.c with FS == 2

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #5 from Patrick Palka  ---
Some context: consider the simplified/extended C++20 testcase (the consteval-if
seems to be a red herring):

consteval int foo(int x) { return x; }

template
void bar(int x)
{
  constexpr int y = 0;
  foo(8 * x); // #1
  foo(8 * y); // #2
}

Before r12-7264, we would indeed correctly reject #1 ahead of time (which has a
non-constant arg), but we would also incorrectly reject #2 (which has a
constant arg), because both arguments are wrapped in NON_DEPENDENT_EXPR which
cxx_eval_constant_expr considers to be always non-constant.  So essentially we
used to reject the two now-failing tests in consteval-if2.C only by accident.

After r12-7264, is_constant_expr returns false for NON_DEPENDENT_EXPR
(mirroring cxx_eval_constant_expr) which in particular means that
fold_non_dependent_expr no longer tries to check a non-dependent consteval call
ahead of time if it has a "complex" argument (i.e. one that is wrapped in
NON_DEPENDENT_EXPR).  Thus we no longer reject #1 ahead of time, and we also no
longer incorrectly reject #2.  IMHO this is overall an improvement, since not
rejecting #1 ahead of time is a QoI issue, whereas rejecting #2 is a
correctness issue.  This also fixed PR103443 for a similar reason.

(In reply to Jakub Jelinek from comment #3)
> So, either build_non_dependent_arg should be made smarter and not wrap even
> simple arithmetics etc. where no C++ template-ish trees appear inside of it
> and everything is like in normal non-template-ish code, or we should
> reconsider
> the r12-7264 case because clearly often we can handle NON_DEPENDENT_EXPR
> just fine.

I wonder if we can get rid of NON_DEPENDENT_EXPR entirely?  I'm not sure if
it's at all necessary anymore.  Or perhaps we could change tsubst /
is_constant_expr / eval_constant_expr to actually look through
NON_DEPENDENT_EXPR.  These ideas seem out of scope for GCC 12 though :/

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Another testcase to consider is:
consteval int foo (int x) { return x; }
consteval int bar () { return 2; }
constexpr int baz (int x) { return x; }

template 
constexpr int
qux (int x)
{
  int r = 0;
  if consteval  // { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
  r += 2 * bar ();
}
  else
{
  r += foo (8 * baz (0));
}
  if ! consteval// { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
  r += foo (32 * baz (0));
}
  if consteval  // { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
  r += 32 * bar ();
}
  return r;
}

This one is valid, but before your r12-7264 was incorrectly rejected because 8
* baz (0) etc. is wrapped in NON_DEPENDENT_EXPR,
potential_constant_expression_1 recursed on the NON_DEPENDENT_EXPR operand,
found it is ok but cxx_eval_constant_expression
rejected the NON_DEPENDENT_EXPR.  Bet for the build_over_call
processing_template_decl immediate_invocation_p code we need to punt silently
if there is something we can't handle but fail loudly if we can handle
everything but it is clearly always not a constant expression. 
potential_constant_expression_1 isn't 100% accurate, there are cases where it
gets stuff through.

[Bug debug/105036] Missing variables when debugging due to overlapping ranges after unrolling, instruction scheduling, and inlining at -O3

[assaiante at diag dot uniroma1.it via Gcc-bugs]

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

--- Comment #2 from Cristian Assaiante  ---
Indeed, we understand some information may be lost for the sake of keeping
debug info correct.

We reported this in the first place because, besides the missing variables, a
wrong function (i.e., foo) is reported as executing in gdb, while the program
is executing a line located in its caller (i.e., main).

Perhaps, if it would be possible to fix the ranges as not to overlap, also the
missing variables would become visible? Since DWARF info for i=0, j=0 is
emitted but not in a way “retrievable” by gdb during source-level debugging.

[Bug target/105014] [nvptx] FAIL: gcc.dg/pr97459-1.c execution test

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

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

--- Comment #5 from Tom de Vries  ---
Minimal test-case:
...
void __attribute__((noinline)) foo (unsigned long long d0) {
  unsigned long long __a;
  __a = 0x38;
  for (; __a > 0; __a -= 8)
if (((d0 >> __a) & 0xff) != 0)
  break;

   __builtin_printf ("__a: 0x%llx\n", __a);
}

int main (void) {
  foo (1);
  return 0;
}
...

Different value of __a:
...
$ ./install/bin/nvptx-none-run -O0 ./pr97459-1.exe ; echo;
./install/bin/nvptx-none-run ./pr97459-1.exe 
__a: 0x0

__a: 0x30
...

[Bug debug/104564] '-fcompare-debug' failure w/ -std=c++20 -O1 -fharden-conditional-branches -fopenacc -gno-statement-frontiers

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

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Fixed

[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function

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

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #5 from Alexandre Oliva  ---
Fixed

[Bug target/103302] wrong code with -fharden-compares

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #17 from Alexandre Oliva  ---
The patch went in on 2022-03-02, commit
12f8dc0b642db5edc702f252af1a5231606b29db, but I failed to tag this PR in the
commit message.

[Bug demangler/105039] rust demangler stack overflow

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

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #1 from Nick Clifton  ---
Proposed patch submitted here:

https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592244.html

[Bug debug/104564] '-fcompare-debug' failure w/ -std=c++20 -O1 -fharden-conditional-branches -fopenacc -gno-statement-frontiers

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r12-7801-gfb488cba571539b6644e8f99f1dd997cdb4c82c1
Author: Alexandre Oliva 
Date:   Thu Mar 24 10:02:29 2022 -0300

hardened conditionals: drop copied identifiers

The copies of identifiers, indended to associate hardening SSA
temporaries to the original variables they refer to, end up causing
-fcompare-debug to fail, because DECL_UIDs are not identical, and the
nouid flag used in compare-debug dumps doesn't affect the uids in
naked identifiers, so the divergence becomes apparent.

This patch drops the naked identifiers.  Though somewhat desirable,
they're not necessary.


for  gcc/ChangeLog

PR debug/104564
* gimple-harden-conditionals.cc (detach_value): Keep temps
anonymous.

for  gcc/testsuite/ChangeLog

PR debug/104564
* c-c++-common/torture/harden-comp.c: Adjust.
* c-c++-common/torture/harden-cond.c: Adjust.

[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r12-7800-gb8c4171ebd72079e55aceadbcfc883f517cdf895
Author: Alexandre Oliva 
Date:   Thu Mar 24 10:02:27 2022 -0300

hardcmp: split before dispatch edge

If we harden a compare at the end of a block with an edge to the
abnormal dispatch block, it won't have a single successor.  Arrange to
split the block at its final stmt so as to have a single succ.


for  gcc/ChangeLog

PR middle-end/104975
* gimple-harden-conditionals.cc
(pass_harden_compares::execute): Force split in case of
multiple edges.

for  gcc/testsuite/ChangeLog

PR middle-end/104975
* gcc.dg/pr104975.c: New.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

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

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

--- Comment #54 from Iain Sandoe  ---
(In reply to Martin Liška from comment #53)
> > Yes, I forgot to mention that.
> > I hope you are right and someone will make these backports in 10.1, 10.2,
> > 10.3, 11.1, 11.2.
> 
> Note one can't rewrite history, but as written, pull the gcc-11 branch and
> it's fixed there.

so, to be clear it will be fixed in 11.3 when that is released (and I have a
set of backports on my TODO for 11.x and 10.x, so also we could expect this
issues to be fixed in 10.4).

There is no easy solution to the general problem - which is finding time to do
all the various jobs ;)

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

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

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

--- Comment #53 from Martin Liška  ---
> Yes, I forgot to mention that.
> I hope you are right and someone will make these backports in 10.1, 10.2,
> 10.3, 11.1, 11.2.

Note one can't rewrite history, but as written, pull the gcc-11 branch and it's
fixed there.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

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

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

--- Comment #52 from Martin Liška  ---
It's fixed on master with r12-3350-g88974974d8188cf1 and it *got* backported to
gcc-11 branch.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #51 from Mkkt Bkkt  ---
(In reply to Avi Kivity from comment #50)
> Your reproducer does pass in trunk. So perhaps just a missing backport.

Yes, I forgot to mention that.
I hope you are right and someone will make these backports in 10.1, 10.2, 10.3,
11.1, 11.2.
Or is this a naive idea of GCC development process?
If so, what should I do to make these backports appear?

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #50 from Avi Kivity  ---
Your reproducer does pass in trunk. So perhaps just a missing backport.

[Bug target/105011] [nvptx] FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #5 from Tom de Vries  ---
Fixed by commit.

[Bug target/105011] [nvptx] FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:11fb784ac592567dbcb7874c27e67ee0feb8fbf0

commit r12-7799-g11fb784ac592567dbcb7874c27e67ee0feb8fbf0
Author: Tom de Vries 
Date:   Wed Mar 23 16:37:45 2022 +0100

[libatomic] Fix return value in libat_test_and_set

On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
...
FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
...
which mimimized to:
...
  #include 
  atomic_flag a = ATOMIC_FLAG_INIT;
  int main () {
if ((atomic_flag_test_and_set) ())
  __builtin_abort ();
return 0;
  }
...

The atomic_flag_test_and_set is implemented using __atomic_test_and_set_1,
which corresponds to the "word-sized compare-and-swap loop" version of
libat_test_and_set in libatomic/tas_n.c.

The semantics of a test-and-set is that the return value is "true if and
only
if the previous contents were 'set'".

But the code uses:
...
  return woldval != 0;
...
which means it doesn't look only at the byte that was either set or not
set,
but at the entire word.

Fix this by using instead:
...
  return (woldval & ((UTYPE) ~(UTYPE) 0 << shift)) != 0;
...

Tested on nvptx.

libatomic/ChangeLog:

2022-03-24  Tom de Vries  

PR target/105011
* tas_n.c (libat_test_and_set): Fix return value.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[valera.mironow at gmail dot com via Gcc-bugs]

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

Mkkt Bkkt  changed:

   What|Removed |Added

 CC||valera.mironow at gmail dot com

--- Comment #49 from Mkkt Bkkt  ---
I don't think undefined sanitizer works with coroutines in GCC 11.2.0.
I have a code that doesn't work.

Error description:
https://gist.github.com/MBkkt/e50520096933eab997a16f54d402919b

Branch for reproduce:
https://github.com/YACLib/YACLib/tree/mbkkt/issue_to_gcc_ubsan

Generally:
I suspend coroutine not in initial/final state
Then I resume it
After resume, coroutine have valid addresses of stack objects.
But dtor of objects on coroutine stack will be called on invalid addresses.

Minimal example:
https://godbolt.org/z/5h33Maeqf

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase for -std=c++23
consteval int foo (int x) { return x; }
consteval int bar () { return 2; }

template 
constexpr int
qux (int x)
{
  int r = 0;
  if consteval
{
  r += 2 * bar ();
}
  else
{
  r += foo (8 * x); // { dg-error "is not a constant expression" }
}
  if ! consteval
{
  r += foo (32 * x);// { dg-error "is not a constant expression" }
}
  if consteval
{
  r += 32 * bar ();
}
  return r;
}

The intent of the testcase was to test whether we catch at least some of the
non-dependent consteval calls already during template parsing and so regardless
of whether we actually instantiate them or not.
Worst case it will be diagnosed during instantiation, sure.
But x is not type nor value dependent and neither is 8 * x nor 32 * x.
And make_args_non_dependent calls build_non_dependent_arg which will not wrap
say x or 8, but does wrap x * 8 even when both arguments have integral types.
So, either build_non_dependent_arg should be made smarter and not wrap even
simple arithmetics etc. where no C++ template-ish trees appear inside of it and
everything is like in normal non-template-ish code, or we should reconsider
the r12-7264 case because clearly often we can handle NON_DEPENDENT_EXPR just
fine.

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Martin Liška  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=28998

[Bug fortran/105037] gfortran emits incorrect debug information if compiled with -finit-real=snan

[christian.friedl at gmx dot at via Gcc-bugs]

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

--- Comment #2 from Christian Friedl  ---
> What do you think is wrong?

The lines

  IF(IREST.EQ.0) THEN
  CALL WO2(1,N1,N2,O2)
  ENRGOLD=EMP2

get emitted twice when -finit-real=snan is used. The first time that they are
emitted, they don't fit the assembly that they refer to.

> Have you raised the gdb issue with the gdb folks?

No. I wasn't really able to provide a minimal example for the error. Using
objdump, I saw that the cause probably was the debug information and not gdb
itself.

[Bug c++/105035] [11 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] tree |[11 Regression] tree check:
   |check: expected field_decl, |expected field_decl, have
   |have identifier_node in |identifier_node in
   |operand_equal_p, at |operand_equal_p, at
   |fold-const.c:3335 since |fold-const.c:3335 since
   |r11-5181-g0862d007b564eca8  |r11-5181-g0862d007b564eca8

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:568377743e22c1377d0aaa1ac9113da3ff1b6bd4

commit r12-7798-g568377743e22c1377d0aaa1ac9113da3ff1b6bd4
Author: Jakub Jelinek 
Date:   Thu Mar 24 12:25:15 2022 +0100

testsuite: Add compat.exp testcase for most common zero width bitfld ABI
passing [PR102024]

On Tue, Mar 22, 2022 at 05:51:58PM +0100, Jakub Jelinek via Gcc wrote:
> I guess it would be nice to include the testcases we are talking about,
> like { float x; int : 0; float y; } and { float x; int : 0; } and
> { int : 0; float x; } into compat.exp testsuite so that we see ABI
> differences in compat testing.

Here is a patch that does that.  It uses the struct-layout-1* framework,
but isn't generated because we don't want in this case pseudo-random
structure layouts, but particular ones we know cause or could cause
problems
on some targets.  If other problematic cases are discovered, we can add
further ones.

Tested on x86_64-linux with:
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=gcc
ALT_CXX_UNDER_TEST=g++ compat.exp=pr102*'
and with
make check-gcc check-g++ RUNTESTFLAGS='compat.exp=pr102*'
The former as expected has:
FAIL: gcc.dg/compat/pr102024 c_compat_x_tst.o-c_compat_y_alt.o execute
FAIL: gcc.dg/compat/pr102024 c_compat_x_alt.o-c_compat_y_tst.o execute
fails because on x86_64 we've changed the C ABI but kept the C++ ABI here.
E.g. on rs6000 it should be the g++.dg such tests to fail (all assuming
the alt gcc/g++ is GCC 4.5 through 11).

2022-03-24  Jakub Jelinek  

PR target/102024
* gcc.dg/compat/pr102024_main.c: New test.
* gcc.dg/compat/pr102024_test.h: New test.
* gcc.dg/compat/pr102024_x.c: New test.
* gcc.dg/compat/pr102024_y.c: New test.
* g++.dg/compat/pr102024_main.C: New test.
* g++.dg/compat/pr102024_test.h: New test.
* g++.dg/compat/pr102024_x.C: New test.
* g++.dg/compat/pr102024_y.C: New test.

[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:8698ff67cdff4364c8adad2921ed532359a155ec

commit r12-7797-g8698ff67cdff4364c8adad2921ed532359a155ec
Author: Jakub Jelinek 
Date:   Thu Mar 24 12:23:51 2022 +0100

fold-const: Handle C++ dependent COMPONENT_REFs in operand_equal_p
[PR105035]

As mentioned in the PR, operand_equal_p already contains some hacks so that
it can be called already on pre-instantiation C++ trees from templates,
but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
case broke this.  Many such COMPONENT_REFs are already punted on earlier
because they have NULL TREE_TYPE, but in this case the code knows what
type they have but still uses an IDENTIFIER_NODE as second operand
of COMPONENT_REF (I think SCOPE_REF is something that could be used too).

The following patch looks at those DECL_FIELD_*OFFSET fields only if
both field[01] args are FIELD_DECLs and otherwise keeps it to the
earlier OP_SAME (1) check that guards this whole block.

2022-03-24  Jakub Jelinek  

PR c++/105035
* fold-const.cc (operand_equal_p) : If either
field0 or field1 is not a FIELD_DECL, return false.

* g++.dg/warn/Wduplicated-cond2.C: New test.

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

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

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

--- Comment #3 from Richard Biener  ---
This isn't really a GCC bug since it's a glibc feature.  Please open a
bugreport on sourceware.

[Bug c++/105044] New: [modules] ICE in comptypes, at cp/typeck.c:1529

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 105044
   Summary: [modules] ICE in comptypes, at cp/typeck.c:1529
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/YGo78aPE8.

`mod.cpp`:
```C++
export module mod;

export template
struct downcast_base {
  using downcast_base_type = BaseType;
  friend auto downcast_guide(downcast_base);
};

export template concept Downcastable = true;

export template
struct downcast_child : T {
  friend auto downcast_guide(typename T::downcast_base) { return T(); }
};

export struct ratio { int num; };

export template
struct scaled_unit : downcast_base> {};

export template
struct unit : downcast_child> {};

export struct unknown_coherent_unit : unit {};
```

`test.cpp`:
```C++
import mod;
struct u : downcast_base { };
int main() { }
```

Output:
```
In module mod, imported at /app/test.cpp:1:
mod.cpp: In instantiation of 'struct downcast_base@mod':
test.cpp:2:12:   required from here
mod.cpp:4:8: internal compiler error: in comptypes, at cp/typeck.cc:1529
4 | struct downcast_base {
  |^
0x218c519 internal_error(char const*, ...)
???:0
0x741b3f fancy_abort(char const*, int, char const*)
???:0
0xa7e346 comptypes(tree_node*, tree_node*, int)
???:0
0x828f6d complete_vars(tree_node*)
???:0
0x7a1a5c finish_struct_1(tree_node*)
???:0
0xa01359 instantiate_class_template(tree_node*)
???:0
0xa7739b complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0x841a1c xref_basetypes(tree_node*, tree_node*)
???:0
0x986b0d c_parse_file()
???:0
0xb18ae2 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2022-03-24
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Indeed, it looks like the warning could be less stupid here.

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
Currently the only documentation is in .

[Bug tree-optimization/105043] Please document -D_FORTIFY_SOURCE

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-24
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
And I would add a caveat about the usage of malloc_usable_size.

[Bug ada/104767] [10/11/12 regression] GNAT.Serial_Communications does not properly close the port

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug ada/104767] [10/11/12 regression] GNAT.Serial_Communications does not properly close the port

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:

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

commit r10-10511-gd800a6f6c03e404a5f033299d9fd1c5caa3b7738
Author: Pascal Obry 
Date:   Thu Mar 24 11:30:05 2022 +0100

Properly reset the port handle when closing

When the serial port is closed, we need to ensure that the port handle is
properly reset for it to be detected as closed.

gcc/ada/
PR ada/104767
* libgnat/g-sercom__mingw.adb (Close): Reset port handle to -1.
* libgnat/g-sercom__linux.adb (Close): Likewise.

[Bug ada/104767] [10/11/12 regression] GNAT.Serial_Communications does not properly close the port

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:4c649dc71189f20ab8ed09b03a7353299f1022c8

commit r11-9691-g4c649dc71189f20ab8ed09b03a7353299f1022c8
Author: Pascal Obry 
Date:   Thu Mar 24 11:30:05 2022 +0100

Properly reset the port handle when closing

When the serial port is closed, we need to ensure that the port handle is
properly reset for it to be detected as closed.

gcc/ada/
PR ada/104767
* libgnat/g-sercom__mingw.adb (Close): Reset port handle to -1.
* libgnat/g-sercom__linux.adb (Close): Likewise.

[Bug tree-optimization/105043] New: Please document -D_FORTIFY_SOURCE

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

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

Bug ID: 105043
   Summary: Please document -D_FORTIFY_SOURCE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
  Target Milestone: ---

I would like to see documentation of the feature, as well as what each level
(1-3) enables. If it's documented in glibc, then please provide a link to the
feature.

[Bug ada/104767] [10/11/12 regression] GNAT.Serial_Communications does not properly close the port

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r12-7796-gd937c6e44ba64694c0fc88f40f42390149d1d624
Author: Pascal Obry 
Date:   Thu Mar 24 11:30:05 2022 +0100

Properly reset the port handle when closing

When the serial port is closed, we need to ensure that the port handle is
properly reset for it to be detected as closed.

gcc/ada/
PR ada/104767
* libgnat/g-sercom__mingw.adb (Close): Reset port handle to -1.
* libgnat/g-sercom__linux.adb (Close): Likewise.

[Bug ada/104767] [10/11/12 regression] GNAT.Serial_Communications does not properly close the port

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|GNAT.Serial_Communications  |[10/11/12 regression]
   |windows package |GNAT.Serial_Communications
   |allows/causes multiple  |does not properly close the
   |closing of the same windows |port
   |handle. |
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2022-03-24
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.4
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Confirmed, this happens on Linux too.

[Bug ada/94181] Misidentified dangling reference in container implementation

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.2
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Eric Botcazou  ---
Thanks for checking.

[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77

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

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

--- Comment #7 from Martin Liška  ---
With the following debugging patch:

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 8f06ee0e54f..150cc6fae1b 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4755,6 +4755,7 @@ undo_to_marker (void *marker)
  *undo->where.i = undo->old_contents.i;
  break;
case UNDO_MODE:
+ fprintf (stderr, "undo called: %p\n", undo->where.r);
  adjust_reg_mode (*undo->where.r, undo->old_contents.m);
  break;
case UNDO_LINKS:
diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index f4404d7abe3..f98e5eb46f7 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -1226,6 +1226,8 @@ emit_status::ensure_regno_capacity ()
   regno_pointer_align = (unsigned char *) tmp;

   rtx *new1 = GGC_RESIZEVEC (rtx, regno_reg_rtx, new_size);
+  fprintf (stderr, "emit_status::ensure_regno_capacity: %p-%p\n", new1, new1
+  + (new_size * sizeof(rtx)));
   memset (new1 + old_size, 0, (new_size - old_size) * sizeof (rtx));
   regno_reg_rtx = new1;


emit_status::ensure_regno_capacity: 0x775fc000-0x77605300
emit_status::ensure_regno_capacity: 0x775f8000-0x7760a600
undo called: 0x775f87e8
undo called: 0x775f87e8
...
emit_status::ensure_regno_capacity: 0x775ea000-0x7760ec00
undo called: 0x775f8c48

As seen the last *undo->where.r access a memory that is GGC freed and that was
previously allocated by emit_status::ensure_regno_capacity.

The last emit_status::ensure_regno_capacity that reallocates is called here:

#0  emit_status::ensure_regno_capacity (this=0x3082010 ) at
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:1229
#1  0x00e2fa3f in gen_reg_rtx (mode=E_DImode) at
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:1201
#2  0x012f088d in maybe_legitimize_operand (icode=CODE_FOR_ashldi3,
opno=0, op=0x7fff9f90) at /home/marxin/Programming/gcc/gcc/optabs.cc:7791
#3  0x012f126d in maybe_legitimize_operands (icode=CODE_FOR_ashldi3,
opno=0, nops=3, ops=0x7fff9f90) at
/home/marxin/Programming/gcc/gcc/optabs.cc:7935
#4  0x012f1326 in maybe_gen_insn (icode=CODE_FOR_ashldi3, nops=3,
ops=0x7fff9f90) at /home/marxin/Programming/gcc/gcc/optabs.cc:7954
#5  0x012dadde in expand_binop_directly (icode=CODE_FOR_ashldi3,
mode=E_DImode, binoptab=ashl_optab, op0=0x772cb420, op1=0x7760f5c0,
target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN, last=0x772c78c0) at
/home/marxin/Programming/gcc/gcc/optabs.cc:1442
#6  0x012db335 in expand_binop (mode=E_DImode, binoptab=ashl_optab,
op0=0x772cb420, op1=0x7760f5c0, target=0x0, unsignedp=1,
methods=OPTAB_LIB_WIDEN) at /home/marxin/Programming/gcc/gcc/optabs.cc:1529
#7  0x012da55c in expand_simple_binop (mode=E_DImode, code=ASHIFT,
op0=0x772cb420, op1=0x7760f5c0, target=0x0, unsignedp=1,
methods=OPTAB_LIB_WIDEN) at /home/marxin/Programming/gcc/gcc/optabs.cc:1261
#8  0x00eba222 in force_operand (value=0x772cb450, target=0x0) at
/home/marxin/Programming/gcc/gcc/expr.cc:7957
#9  0x00e68948 in force_reg (mode=E_DImode, x=0x772cb450) at
/home/marxin/Programming/gcc/gcc/explow.cc:682
#10 0x01ac255f in mips_move_integer (temp=0x77769bd0,
dest=0x77769c60, value=4294167595) at
/home/marxin/Programming/gcc/gcc/config/mips/mips.cc:3662
#11 0x02172535 in gen_split_51 (curr_insn=0x77768840,
operands=0x3168f20 ) at
/home/marxin/Programming/gcc/gcc/config/mips/mips.md:4699
#12 0x0231ce2f in split_6 (x1=0x772c9760, insn=0x77768840) at
/home/marxin/Programming/gcc/gcc/config/mips/mips.md:796
#13 0x0232072d in split_7 (x1=0x772c9760, insn=0x77768840) at
/home/marxin/Programming/gcc/gcc/config/mips/mips.md:7077
#14 0x023220a6 in split_insns (x1=0x772c9760, insn=0x77768840)
at /home/marxin/Programming/gcc/gcc/config/mips/mips.md:7060
#15 0x023608c9 in combine_split_insns (pattern=0x772c9760,
insn=0x77768840) at /home/marxin/Programming/gcc/gcc/combine.cc:530
#16 0x02373b1d in try_combine (i3=0x77768840, i2=0x77768800,
i1=0x777687c0, i0=0x0, new_direct_jump_p=0x7fffd5f8,
last_combined_insn=0x77768840) at
/home/marxin/Programming/gcc/gcc/combine.cc:3588

and the crashing undo with:

#0  0x00e2ff70 in adjust_reg_mode (reg=0xa5a5a5a5a5a5a5a5,
mode=E_SImode) at /home/marxin/Programming/gcc/gcc/emit-rtl.cc:1296
#1  0x023814f1 in undo_to_marker (marker=0x0) at
/home/marxin/Programming/gcc/gcc/combine.cc:4759
#2  0x02381571 in undo_all () at
/home/marxin/Programming/gcc/gcc/combine.cc:4780
#3  0x0237c2e4 in try_combine (i3=0x77768840, i2=0x77768800,
i1=0x777687c0, i0=0x0, new_direct_jump_p=0x7fffd5f8,
last_combined_insn=0x77768840) at
/home/marxin/Programming/gcc/gcc/combine.cc:4050

[Bug libgomp/105042] [libgomp, GOMP_NVPTX_JIT=-O0] Openacc testsuite failures when X runs on nvidia driver

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> Doesn't whatever driver/library API we use from libgomp to invoke workloads
> report actual errors?  Maybe we need to improve there.

Good point, it reported some form of timeout.  I'll post the exact form once I
reproduce.

[Bug ada/104703] GNAT 11.2 exception traceback output is mostly garbled on Intel x64 (MSYS2)

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Eric Botcazou  ---
This should be fixed in 11.3, in the meantime add -largs -no-pie.

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #12 from Siddhesh Poyarekar  ---
Fixed.

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

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

commit r12-7794-gc1d233e3334df07cfb4f732ace4d93d3cbc28bca
Author: Siddhesh Poyarekar 
Date:   Wed Mar 23 23:09:02 2022 +0530

tree-optimization/104970: Limit size computation for access attribute

Limit object size computation only to the simple case where access
attribute has been explicitly specified.  The object passed to
__builtin_dynamic_object_size could either be a pointer or a VLA whose
size has been described using access attribute.

Further, return a valid size only if the object is a void * pointer or
points to (or is a VLA of) a type that has a constant size.

gcc/ChangeLog:

PR tree-optimization/104970
* tree-object-size.cc (parm_object_size): Restrict size
computation scenarios to explicit access attributes.

gcc/testsuite/ChangeLog:

PR tree-optimization/104970
* gcc.dg/builtin-dynamic-object-size-0.c (test_parmsz_simple2,
test_parmsz_simple3, test_parmsz_extern, test_parmsz_internal,
test_parmsz_internal2, test_parmsz_internal3): New tests.
(main): Use them.

Signed-off-by: Siddhesh Poyarekar 

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #18 from Eric Botcazou  ---
> TYPE_MODE should be ok too, it is just passing of arguments by value and
> returning by value that could be problematic on
> aarch64, arm, i386, ia64, iq2000, mips, riscv, rs6000, s390, sh and sparc
> I think sh is ok, it ignores integer_zerop (DECL_SIZE (field)).

On SPARC, the 32-bit ABI passes structures by reference so is not concerned
while the 64-bit ABI does the same as SH:

  /* Walk the real fields, but skip those with no size or a zero size.
 ??? Fields with variable offset are handled as having zero offset.  */
  for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL)
  {
if (!DECL_SIZE (field) || integer_zerop (DECL_SIZE (field)))
  continue;

so is not affected either.

[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
Summary|Wrong array types used for  |[9/10/11/12 Regression]
   |negative stride accesses|Wrong array types used for
   ||negative stride accesses,
   ||gfortran.dg/vector_subscrip
   ||t_1.f90  FAILs

--- Comment #33 from Richard Biener  ---
Btw, for GCC 12 this issue is now visible through IPA modref and results in

FAIL: gfortran.dg/vector_subscript_1.f90   -O1  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O2  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -Os  execution test

on at least x86_64-unknown-linux-gnu.

The testcase in comment#1 still shows the issue is older.  Since gfortran 4.3
works this is still a regression (I guess it became appearant with the alias
oracle introduction).

I'll note the OpenACC folks were working on making gfortran preserve
multi-dimensional array accesses, not sure how they address this issue.  With
a single dimension there's not much value in using ARRAY_REF over
pointer arithmetic and dereference.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

[yann at droneaud dot fr via Gcc-bugs]

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

--- Comment #16 from Yann Droneaud  ---
(In reply to Marek Polacek from comment #13)
> I have a patch which fixes all the testcases here.

I've checked my test cases using godbolt gcc trunk, and, yeah, thanks a lot !

[Bug c++/104994] extern thread_local declaration rejected in constexpr

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:72124f487ccb5c8065dd5f7b8fba254600b7e611

commit r12-7793-g72124f487ccb5c8065dd5f7b8fba254600b7e611
Author: Jakub Jelinek 
Date:   Thu Mar 24 10:12:25 2022 +0100

c++: extern thread_local declarations in constexpr [PR104994]

C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to passing through declaration but
https://cplusplus.github.io/CWG/issues/2552.html
has been filed for it yesterday.

The following patch implements the proposed wording of CWG 2552 in addition
to fixing the C++14 - C++20 handling bug.
If you'd like instead to keep the current pedantic C++23 wording for now,
that would mean taking out the first hunk (cxx_eval_constant_expression)
and
g++.dg/cpp23/constexpr-nonlit2.C hunk.

2022-03-24  Jakub Jelinek  

PR c++/104994
* constexpr.cc (cxx_eval_constant_expression): Don't diagnose
passing
through extern thread_local declarations.  Change wording from
declaration to definition.
(potential_constant_expression_1): Don't diagnose extern
thread_local
declarations.  Change wording from declared to defined.
* decl.cc (start_decl): Likewise.

* g++.dg/diagnostic/constexpr1.C: Change expected diagnostic
wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit1.C: Likewise.
(garply): Change dg-error into dg-bogus.
* g++.dg/cpp23/constexpr-nonlit2.C: Change expected diagnostic
wording
from declaration to definition.
* g++.dg/cpp23/constexpr-nonlit6.C: Change expected diagnostic
wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit7.C: New test.
* g++.dg/cpp2a/constexpr-try5.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp2a/consteval3.C: Likewise.