[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Author: amker   
Date: Tue Apr 23 03:54:59 2019  
New Revision: 270499

URL: https://gcc.gnu.org/viewcvs?rev=270499&root=gcc&view=rev   
Log:
PR tree-optimization/92001  
* tree-chrec.c (evolution_function_is_univariate_p): New parameter  
and check univariate against it.
* tree-chrec.h (evolution_function_is_univariate_p): New parameter. 
* tree-data-ref.c (add_other_self_distances): Pass new argument.

gcc/testsuite   
* gcc/testsuite/gfortran.dg/pr90021.f90: New test.  

Added:  
trunk/gcc/testsuite/gfortran.dg/pr90021.f90 
Modified:   
trunk/gcc/ChangeLog 
trunk/gcc/testsuite/ChangeLog   
trunk/gcc/tree-chrec.c  
trunk/gcc/tree-chrec.h  
trunk/gcc/tree-data-ref.c

[Bug translation/90119] Merge translation msgids that only differ in placeholders

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Thank you Roland for working on that. Can you please integrate your script
with:
contrib/check-internal-format-escaping.py

?

[Bug sanitizer/90208] New: [7/8/9 Regression] error: EH landing pad label

[marxin at gcc dot gnu.org]

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

Bug ID: 90208
   Summary: [7/8/9 Regression] error: EH landing pad label
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This is a following up of PR89280:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr89280.c 
-fexceptions -fsanitize=thread -O3
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr89280.c: In
function ‘test4’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr89280.c:48:1:
error: EH landing pad label 
   48 | }
  | ^
 is not first in a sequence of labels in bb 4during GIMPLE pass: einline
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr89280.c:48:1:
internal compiler error: verify_flow_info failed
0x8d931b verify_flow_info()
/home/marxin/Programming/gcc/gcc/cfghooks.c:265
0xd4a684 checking_verify_flow_info
/home/marxin/Programming/gcc/gcc/cfghooks.h:211
0xd4a684 cleanup_tree_cfg_noloop
/home/marxin/Programming/gcc/gcc/tree-cfgcleanup.c:1108
0xd4a684 cleanup_tree_cfg(unsigned int)
/home/marxin/Programming/gcc/gcc/tree-cfgcleanup.c:1159
0xc1f0cf execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1930
0xc1ff7e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2031
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

And I have also a reduced test-case that started with r269243:

$ cat ice-new.c 
void *b;
void a();
void c(int d) {
  while (d)
a();
}
void e() {
  c(2);
  __builtin_setjmp(b);
}

$ gcc -fexceptions -fsanitize=thread -O2 ice-new.c
ice-new.c: In function ‘e’:
ice-new.c:10:1: error: EH landing pad label 
   10 | }
  | ^
 is not first in a sequence of labels in bb 4during GIMPLE pass: einline
ice-new.c:10:1: internal compiler error: verify_flow_info failed
0x8d931b verify_flow_info()
/home/marxin/Programming/gcc/gcc/cfghooks.c:265
0xd4a684 checking_verify_flow_info
/home/marxin/Programming/gcc/gcc/cfghooks.h:211
0xd4a684 cleanup_tree_cfg_noloop
/home/marxin/Programming/gcc/gcc/tree-cfgcleanup.c:1108
0xd4a684 cleanup_tree_cfg(unsigned int)
/home/marxin/Programming/gcc/gcc/tree-cfgcleanup.c:1159
0xc1f0cf execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1930
0xc1ff7e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2031
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/90208] [7/8/9 Regression] error: EH landing pad label

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2019-4-23
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.5
  Known to fail||7.4.0, 8.3.1, 9.0

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Can you please use:
$ export UBSAN_OPTIONS="print_stacktrace=1"

so that we see the complete back-trace? Thanks.

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Nick Clifton from comment #13)
> FYI - I have now checked in a patch to the RX assembler which fixes this
> problem.
> 
> Martin - I will leave it to you to verify that the build now works (since I
> am lazy, and it is the start of a long weekend) but if there are problems
> please let me know.
> 
> Cheers
>   Nick

Yep, I'm fine with that. Thanks for the fix.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #38 from Florian Weimer  ---
(In reply to H.J. Lu from comment #28)
> (In reply to Thiago Macieira from comment #27)
> > (In reply to Jakub Jelinek from comment #26)
> > > Plus, if KDE uses so small binaries, why don't just compile them with 
> > > -fPIC
> > > then?
> > > You can then link them as normal executables or PIEs, depending on what 
> > > you
> > > prefer, and still it supposedly wouldn't use copy relocations, as all
> > > references to externals would be through .got.
> > 
> > Can you guarantee that the linker won't generate copy relocs for -fPIC?
> 
> Yes.

I do not think this follows from the ELF specification, so portable
applications cannot assume this.  Considering the recent proliferation of link
editors, relying on specific BFD ld behavior seems increasingly unwise.

(Not sure why this bug is marked RESOLVED/FIXED—shouldn't it be INVALID?)

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[rsandifo at gcc dot gnu.org]

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
Yeah, the patch I committed fixed two separate instances of
undefined overflow, but I think there are a lot more left.
The testsuite results with bootstrap-ubsan show a lot of failures
generally, so the compiler isn't UB-free even for our existing tests.

I fixed another instance in r85164 that was unrelated to the testcases
in this PR, so if you're just applying the patches locally, it'd be worth
trying that as well.

Could you open separate PRs for the new tests?  We could perhaps
have a meta-bug for ubsan failures too, if we don't already.

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
> 
> Could you open separate PRs for the new tests?  We could perhaps
> have a meta-bug for ubsan failures too, if we don't already.

We do have one ('ubsan' alias name):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-23
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|ICE in extract_insn, at |[8/9 Regression] ICE in
   |recog.c:2304 x86_64 |extract_insn, at
   ||recog.c:2304 x86_64
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Doesn't reproduce on the trunk starting with r265489, likely latent afterwards.
Started with r253975, likely latent before.
I'll have a look.

[Bug rtl-optimization/90209] New: codegen regression (x < 0 ? -x : x) results in branch instead of single instruction on x86_64

[vegard.nossum at oracle dot com]

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

Bug ID: 90209
   Summary: codegen regression (x < 0 ? -x : x) results in branch
instead of single instruction on x86_64
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
  Target Milestone: ---

This test case:

double abs1(double x) {
return x < 0 ? -x : x;
}

used to generate just a single "andpd" instruction before r131381
(5921cbdff68):

abs1:
andpd   .LC2(%rip), %xmm0
ret

afterward this revision, it generated this:

fabs1:
movapd  %xmm0, %xmm1
ucomisd .LC0(%rip), %xmm0
jb  .L7
.L2:
movapd  %xmm1, %xmm0
ret
.L7:
jp  .L2
movsd   .LC1(%rip), %xmm0
xorpd   %xmm0, %xmm1
movapd  %xmm1, %xmm0
ret

The branch is still present on trunk, as can be seen here:

https://godbolt.org/z/P4tQMB

Thanks to jakub for narrowing it down to r131375..r131425.

Three related bugs (AFAICT) are #29253, #62055, and #64897.

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Simplified testcase:
double a[64];
double *foo (void);

void
bar (int x, const double *y)
{
  int i;
  for (i = 0; i < x; i++)
if (y[i] < a[i])
  a[i] = y[i];
}

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
It looks like middle-end is bypassing sminv2df3 expander and constructs RTX by
hand. This should not be done, since the expander decides whether IEEE or
non-IEEE variant should be used.

Please note that there is also an issue with {smax,smin}{sf,df}3, where

&& !(MEM_P (operands[1]) && MEM_P (operands[2]))

is (intentionally?) missing, and we depend on RA to fix invalid RTX.

[Bug c++/90196] std:: types unused without warnings but simple type not affected

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Максим Прохоренко from comment #3)
> Allocate GiB of unused memory and don't warn about it? But 1 simple double -
> it is a big problem.

Nobody said that. But the warning has to be driven by simple rules. An unused
double is easy to detect and warn about. Knowing if a complex type exists for
some reason that the compiler can't infer is harder to do.

> For std:: objects with side effect - OK!
> But for simple unused vector or set or map???

Destroying elements and deallocating memory is a side effect.

The compiler doesn't do arbitrarily complex analysis of what a destructor does,
it just considers a non-trivial destructor to be doing something.

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
That is not what I see.
I see that vcondv2dfv2df is being expanded, and that one has general_operand
and vector_operand predicates which do allow MEM.
That calls ix86_expand_sse_fp_minmax which doesn't ensure both operands aren't
MEM.

[Bug rtl-optimization/90209] codegen regression (x < 0 ? -x : x) results in branch instead of single instruction on x86_64

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Try with -fno-signed-zeros.

[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |9.0

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 46228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46228&action=edit
gcc9-pr90187.patch

Untested fix.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 23 09:55:33 2019
New Revision: 270502

URL: https://gcc.gnu.org/viewcvs?rev=270502&root=gcc&view=rev
Log:
Fix std::variant regression caused by never-valueless optimization

A regression was introduced by the recent changes to provide the strong
exception safety guarantee for "never valueless" types that have O(1),
non-throwing move assignment. The problematic code is:

  else if constexpr (__detail::__variant::_Never_valueless_alt())
{
  // This construction might throw:
  variant __tmp(in_place_index<_Np>, __il,
std::forward<_Args>(__args)...);
  // But _Never_valueless_alt means this won't:
  *this = std::move(__tmp);
}

When the variant is not assignable, the assignment is ill-formed, so
should not be attempted. When the variant has a copy assignment operator
but not a move assignment operator, the assignment performs a copy
assignment and that could throw, so should not be attempted.

The solution is to only take that branch when the variant has a move
assignment operator, which is determined by the _Traits::_S_move_assign
constant. When that is false the strong exception safety guarantee is
not possible, and so the __never_valueless function should also depend
on _S_move_assign.

While testing the fixes for this I noticed that the partial
specialization _Never_valueless_alt> incorrectly
assumed that is_nothrow_move_constructible> is
always true, but that's wrong for fully-dynamic COW strings. Fix the
partial specialization, and improve the comment describing
_Never_valueless_alt to be clear it depends on move construction as well
as move assignment.

Finally, I also observed that _Variant_storage::_M_valid()
was not taking advantage of the __never_valueless() function to
avoid a runtime check. Only the _Variant_storage::_M_valid()
function was using __never_valueless. That is also fixed.

PR libstdc++/87431
* include/bits/basic_string.h (_Never_valueless_alt): Make partial
specialization also depend on is_nothrow_move_constructible.
* include/std/variant (__detail::__variant::__never_valueless()):
Only true if the variant would have a move assignment operator.
(__detail::__variant::_Variant_storage::_M_valid()):
Check __never_valueless().
(variant::emplace): Only perform non-throwing move assignments
for never-valueless alternatives if the variant has a move assignment
operator.
* testsuite/20_util/variant/compile.cc: Check that never-valueless
types can be emplaced into non-assignable variants.
* testsuite/20_util/variant/run.cc: Check that never-valueless types
don't get copied when emplaced into non-assignable variants.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h
trunk/libstdc++-v3/include/std/variant
trunk/libstdc++-v3/testsuite/20_util/variant/compile.cc
trunk/libstdc++-v3/testsuite/20_util/variant/run.cc

[Bug c++/90210] New: [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization

[tyker at outlook dot com]

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

Bug ID: 90210
   Summary: [C++17] CTAD forbidding explicit deduction guide for
copy-list-initialization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tyker at outlook dot com
  Target Milestone: ---

gcc currently allows the following code:

template struct tuple { tuple(T); };
template explicit tuple(T t) -> tuple;
tuple t = { 1 };

this should fail to compile because the deduction guide is marked explicit.
the issue may come from the implicit deduction guide not being overridden by
the user defined one.

example from other compilers:
https://godbolt.org/z/M198L5

the standard says in [over.match.list]:
"In copy-list-initialization, if an explicit constructor is chosen, the
initialization is ill-formed."

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Or would you prefer:
--- gcc/config/i386/i386.c.jj   2019-04-16 10:40:15.077091789 +0200
+++ gcc/config/i386/i386.c  2019-04-23 11:55:59.397227347 +0200
@@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
   else
 {
   code = is_min ? SMIN : SMAX;
-  tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
+  rtx operands[3] = { dest, if_true, if_false };
+  ix86_fixup_binary_operands_no_copy (code, mode, operands);
+  tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
+  dest = operands[0];
 }

   emit_insn (gen_rtx_SET (dest, tmp));
instead?  I think a switch on mode to handle all the possible modes in there
and assign the different gen_{smin,smax}* in those cases would be too large.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #78 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 23 10:03:41 2019
New Revision: 270504

URL: https://gcc.gnu.org/viewcvs?rev=270504&root=gcc&view=rev
Log:
PR target/89093
* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Diagnose
if used with general-regs-only.
(arm_conditional_register_usage): Don't add non-general regs if
general-regs-only.
(arm_valid_target_attribute_rec): Handle general-regs-only.
* config/arm/arm.h (TARGET_HARD_FLOAT): Return false if
general-regs-only.
(TARGET_HARD_FLOAT_SUB): Define.
(TARGET_SOFT_FLOAT): Define as negation of TARGET_HARD_FLOAT_SUB.
(TARGET_REALLY_IWMMXT): Add && !TARGET_GENERAL_REGS_ONLY.
(TARGET_REALLY_IWMMXT2): Likewise.
* config/arm/arm.opt: Add -mgeneral-regs-only.
* doc/extend.texi: Document ARM general-regs-only target.
* doc/invoke.texi: Document ARM -mgeneral-regs-only.
libgcc/
* config/arm/pr-support.c: Add #pragma GCC target("general-regs-only").
* config/arm/unwind-arm.c: Likewise.
* unwind-c.c (PERSONALITY_FUNCTION): Add general-regs-only target
attribute for ARM.
libobjc/
* exception.c (PERSONALITY_FUNCTION): Add general-regs-only target
attribute for ARM.
libphobos/
* libdruntime/gcc/deh.d: Import gcc.attribute.
(personality_fn_attributes): New enum.
(scanLSDA, CONTINUE_UNWINDING, gdc_personality, __gdc_personality):
Add @personality_fn_attributes.
libstdc++-v3/
* libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Add
general-regs-only target attribute for ARM.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/arm.opt
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/libgcc/ChangeLog
trunk/libgcc/config/arm/pr-support.c
trunk/libgcc/config/arm/unwind-arm.c
trunk/libgcc/unwind-c.c
trunk/libobjc/ChangeLog
trunk/libobjc/exception.c
trunk/libphobos/ChangeLog
trunk/libphobos/libdruntime/gcc/deh.d
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_personality.cc

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P4
 CC||ebotcazou at gcc dot gnu.org,
   ||ian at gcc dot gnu.org

--- Comment #79 from Jakub Jelinek  ---
Fixed for all languages but Ada and Go, neither of them is release critical.

[Bug debug/90131] wrong debug info at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 23 10:10:10 2019
New Revision: 270505

URL: https://gcc.gnu.org/viewcvs?rev=270505&root=gcc&view=rev
Log:
2019-04-23  Richard Biener  

PR debug/90131
* tree-cfgcleanup.c (move_debug_stmts_from_forwarder): Add
dest_single_pred_p argument.
(remove_forwarder_block): Adjust.
(remove_forwarder_block_with_phi): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfgcleanup.c

[Bug c++/90101] [P0732] Error using non-type template parameter in a template template argument

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #1 from Benjamin Buch  ---
simplified test case:


template
struct A{};

template>
struct B {};


$ g++ -std=c++2a test.cpp
test.cpp:4:17: error: invalid use of incomplete type 'struct A'

4 | template>

  | ^~~

test.cpp:2:8: note: declaration of 'struct A'

2 | struct A{};

  |^

$ g++ --version
g++ (Compiler-Explorer-Build) 9.0.1 20190422 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


https://godbolt.org/z/kdDPaO

[Bug tree-optimization/90211] New: [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351

[asolokha at gmx dot com]

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

Bug ID: 90211
   Summary: [8/9 Regression] ICE: tree check: expected ssa_name,
have real_cst in first_readonly_imm_use, at
ssa-iterators.h:351
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20190421 snapshot (r270485) ICEs when compiling the following
testcase w/ -O3 (-Ofast) -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop:

double
yk (int d9)
{
  double vy, q4 = 0.0;

  while (d9 < 3)
{
  int tc;

  vy = 0.0;
  tc = 0;
  while (tc < d9)
{
  vy += 1.0;
  ++tc;
}

  q4 += 1.0;
  ++d9;
}

  return vy + q4;
}

% gcc-9.0.0-alpha20190421 -O3 -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop -c vnd2w3xt.c
during GIMPLE pass: parloops
vnd2w3xt.c: In function 'yk':
vnd2w3xt.c:2:1: internal compiler error: tree check: expected ssa_name, have
real_cst in first_readonly_imm_use, at ssa-iterators.h:351
2 | yk (int d9)
  | ^~
0x6f1e75 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.c:9900
0x69d256 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.h:3176
0x69d256 first_readonly_imm_use
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/ssa-iterators.h:351
0x69d256 try_create_reduction_list
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:2817
0x69d256 parallelize_loops
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3392
0xe0583d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3506
0xe0583d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3485

[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)
> Or would you prefer:
> --- gcc/config/i386/i386.c.jj 2019-04-16 10:40:15.077091789 +0200
> +++ gcc/config/i386/i386.c2019-04-23 11:55:59.397227347 +0200
> @@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
>else
>  {
>code = is_min ? SMIN : SMAX;
> -  tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
> +  rtx operands[3] = { dest, if_true, if_false };
> +  ix86_fixup_binary_operands_no_copy (code, mode, operands);
> +  tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
> +  dest = operands[0];
>  }
>  
>emit_insn (gen_rtx_SET (dest, tmp));
> instead?  I think a switch on mode to handle all the possible modes in there
> and assign the different gen_{smin,smax}* in those cases would be too large.

No, the proposed patch that forces if_true operand to a register should be
enough. It doesn't make much difference calling ix86_fixup_binary_operands_*
without memory output operand.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #24 from Jonathan Wakely  ---
Fixed again, I hope.

[Bug c++/90210] [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-23
 Ever confirmed|0   |1

[Bug tree-optimization/90211] [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4

--- Comment #1 from Jakub Jelinek  ---
Started with r255267.
Cleaned up testcase:
/* PR tree-optimization/90211 */
/* { dg-do compile } */
/* { dg-require-effective-target pthread } */
/* { dg-options "-O3 -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop" } */

double
foo (int x)
{
  double a, b = 0.0;
  while (x < 3)
{
  int c;
  a = 0.0;
  c = 0;
  while (c < x)
{
  a += 1.0;
  ++c;
}
  b += 1.0;
  ++x;
}
  return a + b;
}

[Bug c++/90170] [7/8/9 Regression] ICE in unify, at cp/pt.c:22209

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|error-recovery  |ice-on-valid-code
   Target Milestone|--- |9.0

--- Comment #2 from Richard Biener  ---
If previous compilers didn't ICE but still reject the testcase this PR would be
P4, if we correctly accepted the code before it would be P1.

[Bug middle-end/90191] [9 regression] -Wformat-overflow depends on --param max-jump-thread-duplication-stmts=17

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
So is the warning good or bad?  That it now depends on the param suggests a
change in default optimization behavior.

[Bug c++/90212] New: [8/9 Regression] by-ref capture of constexpr class object rejected

[redi at gcc dot gnu.org]

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

Bug ID: 90212
   Summary: [8/9 Regression] by-ref capture of constexpr class
object rejected
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

template struct tuple {
constexpr tuple(T&& t) : t(t) { }
int t;
};

void foo() {
constexpr tuple v1{1};
constexpr auto v2 = v1;
[&]{ constexpr auto v2 = v1; };
}

Since r256842 GCC 8 and trunk reject this:


a.cc: In lambda function:
a.cc:9:30: error: lambda capture of ‘v1’ is not a constant expression
 [&]{ constexpr auto v2 = v1; };
  ^~

Clang and icc accept it, and I think it's valid.

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
Version|unknown |8.3.1
   Keywords||wrong-debug
   Last reconfirmed||2019-04-23
 CC||aoliva at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |8.4

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue is that the line number program only contains line number
6
and the consumer (gdb) doesn't handle a jump in a stmt sequence as "ending"
a line, thus 'next' advances to after the loop.  We expand from

   [local count: 118111600]:
  [t.c:5:3] # DEBUG BEGIN_STMT
  [t.c:5:8] # DEBUG BEGIN_STMT
  [t.c:5:12] # DEBUG i => 0
  # DEBUG i => 0
  # DEBUG base => base_7(D)
  [t.c:5:3] if (count_9(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]:
  ivtmp.10_4 = (unsigned long) dst_10(D);
  _14 = (unsigned int) count_9(D);
  _15 = _14 * 15;
  _21 = base_7(D) + _15;

   [local count: 955630224]:
  # base_17 = PHI 
  # ivtmp.10_6 = PHI 
  # DEBUG i => NULL
  # DEBUG base => base_17
  [t.c:6:5] # DEBUG BEGIN_STMT
  _16 = (void *) ivtmp.10_6;
  [t.c:6:12] MEM[base: _16, offset: 0B] = base_17;
  [t.c:5:30] # DEBUG i => D#1
  [t.c:5:40] base_13 = base_17 + 15;
  [t.c:5:40] # DEBUG base => base_13
  # DEBUG i => D#1
  # DEBUG base => base_13
  ivtmp.10_5 = ivtmp.10_6 + 4;
  [t.c:5:3] if (base_13 != _21)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111601]:
  [t.c:7:1] return;

notice how the only stmt marker inside the loop body is for t.c:6.

gimplification shows

test (unsigned int * dst, unsigned int base, int count)
[t.c:4:1] {
  [t.c:5:3] # DEBUG BEGIN_STMT
  [t.c:5:3] {
int i;

[t.c:5:8] # DEBUG BEGIN_STMT
[t.c:5:12] i = 0;
[t.c:5:3] goto ;
:
[t.c:6:5] # DEBUG BEGIN_STMT
[t.c:6:8] _1 = (long unsigned int) i;
[t.c:6:8] _2 = _1 * 4;
[t.c:6:8] _3 = dst + _2;
[t.c:6:12] [t.c:6:8] *_3 = base;
[t.c:5:30] i = i + 1;
[t.c:5:40] base = base + 15;
:
[t.c:5:3] if (i < count) goto ; else goto ;
:

so the debug begin_stmt for the loop is attached before the IV
initialization.  Not sure if that has consequences.

The testcase behaves as expected with -gno-statement-frontiers

Alex?

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Just to say I used gdb 8.2 for my investigation.

[Bug middle-end/90191] [9 regression] -Wformat-overflow depends on --param max-jump-thread-duplication-stmts=17

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> So is the warning good or bad?  That it now depends on the param suggests a
> change in default optimization behavior.

Sorry not to be clear

Warning with --param ... is incorrect.

And creduced testcase has "dead" code: "if(0) goto ...;"
May be some pass (jump-threading?) cant simplify it?

If so then smth like 90037 probably will be the root PR

[Bug tree-optimization/90211] [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-23
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 46229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46229&action=edit
gcc9-pr90211.patch

Untested fix.

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  ---
Created attachment 46230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46230&action=edit
gcc 7 reduced testcase

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  ---
While my original testcase fails on gcc 7, 8, and 9, the one reduced using gcc
9
only failed on trunk.  I've now ran creduce with the original testcase against
both gcc 7 and 8.  Each run produced a different reduced testcase, neither of
which is fixed by applying the trunk patch to the branches.

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Created attachment 46231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46231&action=edit
gcc 8 reduced testcase

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #9 from Rainer Orth  ---
Reopening as explained in Comment 7.

[Bug middle-end/90139] [7/8 Regression] ICE in emit_block_move_hints, at expr.c:1601

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9 Regression] ICE in   |[7/8 Regression] ICE in
   |emit_block_move_hints, at   |emit_block_move_hints, at
   |expr.c:1601 |expr.c:1601

--- Comment #10 from Jakub Jelinek  ---
That is a 7/8 regression though then.  Or do you have a testcase that still
fails on the trunk?

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #16 from Vittorio Zecca  ---
On Saturday afternoon I had a power failure that probably damaged my disk,
so I cannot help you now.

[Bug c/90167] invalid example in GCC documentation wrt. effective type rules

[lersek at redhat dot com]

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

--- Comment #2 from Laszlo Ersek (RH)  ---
(In reply to Segher Boessenkool from comment #1)
> The code accesses d, of type double, as an int.  That is not a
> compatible type.

Agreed; I didn't claim it was.

> It does not matter how it got there, what pointer casts trickery with
> unions it did.

I disagree, and in my opinion, the standard disagrees too.

> You can access a union type as the type of any of its members.  But a
> double is not a union type.

I didn't claim it was.

The standard writes,

An object [the double] shall have its stored value accessed only by
an lvalue expression that has one of the following types:

[...]

- a [...] union type that includes [a type compatible with the
  effective type of the [double] object] among its members

It says we can access a "double" through a union which has a "double"
member.

  union u {
int i;
double d1;
  };

  double d2;

The expression (*(union u *)&d2) is an lvalue expression that has a
union type that includes a double among its members.

To me this seems to follow from the letter of the standard. If my
interpretation is incorrect, or the standard is unclear or incorrect,
please show that. Thanks.

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> because we talk to apply this constraint:

s/talk/fail/

[Bug middle-end/90139] [7/8 Regression] ICE in emit_block_move_hints, at expr.c:1601

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Jakub Jelinek  ---
> That is a 7/8 regression though then.  Or do you have a testcase that still
> fails on the trunk?

No: it seems the original testcase produces the same ICE in different
places on gcc 7, 8, and 9.

I'm not certain about the regression part, TBH: when I tried the
original (preprocessed) testcase with gcc [876].1.0, it ICEd on all of
them, but it wouldn't even compile on gcc 5.1.0.  So I don't have a gcc
release where it worked.

[Bug tree-optimization/90213] New: UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'

[marxin at gcc dot gnu.org]

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

Bug ID: 90213
   Summary: UBSAN: signed integer overflow: -5621332293356458048 *
8 cannot be represented in type 'long int'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Fails for:

$ cat ubsan.c
int a[4];
void f()
{
  long int b = 7818038963515661296;
  a[0xA699ECD2C348A3A0] = a[b];
}

$ ~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/xgcc -B
~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/  ubsan.c -c -O
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:753:21:
runtime error: signed integer overflow: -5621332293356458048 * 8 cannot be
represented in type 'long int'
#0 0x139a5ef in if_nonpoly,
poly_int_traits::is_poly>::type& poly_int<1u, long>::operator*=(int
const&)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:753
#1 0x139a5ef in fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*))
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/gimple-fold.c:6992
#2 0x139bfd0 in gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/gimple-fold.c:6426
#3 0x25df8ec in ccp_fold
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:1257
#4 0x25df8ec in evaluate_stmt
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:1785
#5 0x25e449c in visit_assignment
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2355
#6 0x284805d in ssa_propagation_engine::simulate_stmt(gimple*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:230
#7 0x284900c in ssa_propagation_engine::simulate_block(basic_block_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:337
#8 0x284ddc1 in ssa_propagation_engine::ssa_propagate()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:802
#9 0x25c726f in do_ssa_ccp
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2474
#10 0x25c726f in execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2518
#11 0x1c6d018 in execute_one_pass(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2487
#12 0x1c70921 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2573
#13 0x1c70964 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2574
#14 0x1c70a18 in execute_pass_list(function*, opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2584
#15 0x1c67cd6 in do_per_function_toporder(void (*)(function*, void*),
void*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:1705
#16 0x1c72d7d in execute_ipa_pass_list(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2932
#17 0xdb75c8 in ipa_passes
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2484
#18 0xdb75c8 in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2620
#19 0xdc0d5b in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2599
#20 0xdc0d5b in symbol_table::finalize_compilation_unit()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2865
#21 0x2148fc4 in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:481
#22 0x7bf43a in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2205
#23 0x7bf43a in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2340
#24 0x83062e in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/main.c:39
#25 0x77976b7a in __libc_start_main ../csu/libc-start.c:308
#26 0x834749 in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/cc1+0x834749)

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 23 12:48:18 2019
New Revision: 270509

URL: https://gcc.gnu.org/viewcvs?rev=270509&root=gcc&view=rev
Log:
PR libstdc++/90165 constrain variant(T&&) constructor

Also refactor some constraints slightly to be more readable.

PR libstdc++/90165
* include/std/variant (variant::__not_self): New helper for the
is_same_v, variant>==false constraints.
(variant::__to_type_impl): Remove.
(variant::__to_type): Add default argument to check pack size, instead
of using __to_type_impl.
(variant::__accepted_type): Add default argument using __not_self.
(variant::__is_in_place_tag, variant::__not_in_place_tag): New helpers
for variant(T&&) constructor constraint.
(variant::variant(T&&)): Use __not_in_place_tag in constraints.
Extract __accepted_type into a named template parameter for reuse in
other constraints and in the exception specification.
(variant::variant(in_place_type_t, Args&&...))
(variant::variant(in_place_type_t, initializer_list, Args&&...))
(variant::variant(in_place_index_t, Args&&...))
(variant::variant(in_place_index_t, initializer_list, Args&&...))
(variant::operator=T&&)): Remove redundant && from trait arguments.
* testsuite/20_util/variant/compile.cc: Check variant(T&&) constructor
isn't used for in_place_type or in_place_index arguments.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant
trunk/libstdc++-v3/testsuite/20_util/variant/compile.cc

[Bug rtl-optimization/90214] New: UBSAN: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int'

[marxin at gcc dot gnu.org]

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

Bug ID: 90214
   Summary: UBSAN: signed integer overflow: 162675373468811328 -
-9060696663385964544 cannot be represented in type
'long int'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following fails:

$ cat ubsan2.c
long b[1][9];
typedef long V __attribute__((vector_size (16), may_alias));

void
foo ()
{
  V *c = (V *) ((char *) b + -9060696663385964544);
  *c = (V) { 1, 1 };
  long __attribute__((may_alias)) *d = (long *) ((char *) b +
162675373468811328);
  *d = 1;
}

$ ~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/xgcc -B
~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/  ubsan2.c -c -O
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:944:5:
runtime error: signed integer overflow: 162675373468811328 -
-9060696663385964544 cannot be represented in type 'long int'
#0 0x4335e62 in poly_int<1u, poly_result::result_kind>::type> operator-<1u, long,
long>(poly_int_pod<1u, long> const&, poly_int_pod<1u, long> const&)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:944
#1 0x4335e62 in record_store
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:1573
#2 0x43393d2 in scan_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:2568
#3 0x43393d2 in dse_step1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:2680
#4 0x43393d2 in rest_of_handle_dse
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:3597
#5 0x43393d2 in execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:3655
#6 0x1c6d018 in execute_one_pass(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2487
#7 0x1c70921 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2573
#8 0x1c70964 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2574
#9 0x1c70a18 in execute_pass_list(function*, opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2584
#10 0xdb211d in cgraph_node::expand()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2198
#11 0xdb64ab in expand_all_functions
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2336
#12 0xdb64ab in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2687
#13 0xdc0d5b in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2599
#14 0xdc0d5b in symbol_table::finalize_compilation_unit()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2865
#15 0x2148fc4 in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:481
#16 0x7bf43a in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2205
#17 0x7bf43a in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2340
#18 0x83062e in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/main.c:39
#19 0x77976b7a in __libc_start_main ../csu/libc-start.c:308
#20 0x834749 in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/cc1+0x834749)

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
> Could you open separate PRs for the new tests?  We could perhaps
> have a meta-bug for ubsan failures too, if we don't already.

I did so: PR90213 and PR90214.

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to work||9.0
   Target Milestone|--- |8.4
  Known to fail||8.3.0

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064

[zhroma at gcc dot gnu.org]

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

--- Comment #5 from Roman Zhuykov  ---
Author: zhroma
Date: Tue Apr 23 12:53:43 2019
New Revision: 270511

URL: https://gcc.gnu.org/viewcvs?rev=270511&root=gcc&view=rev
Log:
modulo-sched: fix branch scheduling issue (PR84032)

PR rtl-optimization/84032
* modulo-sched.c (ps_insn_find_column): Change condition so that
branch will always be the last insn in a row inside partial
schedule.

testsuite:

PR rtl-optimization/84032
* gcc.dg/pr84032.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84032.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/modulo-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/90208] [7/8/9 Regression] error: EH landing pad label

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46232&action=edit
gcc9-pr90208.patch

Untested fix.

[Bug tree-optimization/90208] [7/8/9 Regression] error: EH landing pad label

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|sanitizer   |tree-optimization
 Ever confirmed|0   |1

[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |zhroma at gcc dot 
gnu.org

--- Comment #6 from Roman Zhuykov  ---
Fixed.

[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393

[zhroma at gcc dot gnu.org]

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

--- Comment #3 from Roman Zhuykov  ---
Author: zhroma
Date: Tue Apr 23 13:14:57 2019
New Revision: 270512

URL: https://gcc.gnu.org/viewcvs?rev=270512&root=gcc&view=rev
Log:
modulo-sched: prevent division by zero (PR87979)

PR rtl-optimization/87979
* modulo-sched.c (sms_schedule): Start ii value "mii" should
not equal zero.

testsuite:

PR rtl-optimization/87979
* gcc.dg/pr87979.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr87979.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/modulo-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

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

--- Comment #4 from Roman Zhuykov  ---
Fixed.

[Bug d/88238] libphobos compile problems on Solaris 10

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Buclaw  ---
> (In reply to Rainer Orth from comment #0)
[...]
>> * 
>> 
>>  symbol not found: dl_iterate_phdr   
>> (libdruntime/.libs/libgdruntime.so)
>> 
>>   Unlike Solaris 11, dl_iterate_phdr support was only backported to a late
>>   Solaris 10 update and even so only lives in libdl, not in libc.  Not yet
>>   fixed.
>> 
>
> So does dlopen and dl_iterate_phdr live in separate libraries?  I would have

In Solaris 10, dlopen lives in libc, but is just a filter on ld.so.1
(the runtime linker), while dl_iterate_phdr only exists in libdl.so.1.

In Solaris 11, OTOH, both exist in libc as filter on ld.so.1.

> thought that DRUNTIME_LIBRARIES_DLOPEN would correctly add -ldl to the driver
> spec file.

Since no separate library is needed for dlopen, -ldl isn't added to $LIBS.

This could certainly be fixed by augmenting the autoconf test.

>> *
>> 
>>  symbol not found: getprogname   
>> (libdruntime/.libs/libgdruntime.so)
>> 
>>   Solaris 10 lacks getprogname or equivalent; for now I'm faking this by just
>>   returning "a.out".
>> 
>
> There's the following function in rt/dmain2.d
>
> extern (C) string[] rt_args();
>
> Would the basename() of argv[0] be a suitable fallback?  Looking at illumos,

Sure.  As an initial hack, I even used a hardcoded "a.out".

> they use dlinfo(RTLD_SELF, RTLD_DI_ARGSINFO) and strrchr(argv0, '/').

True, and that dlinfo request already exists in Solaris 10.

>> *
>> symbol not found: posix_memalign   
>> (src/.libs/libgphobos.so)
>> 
>>   Also missing from Solaris 10.  I've not yet checked what to do here.  One
>>   might be able to use pagealign_alloc from gnulib instead?
>
> If the OS version can be obtained from the compiler, same as FBSD_MAJOR, then

Right now, it can't.  However, the Studio compilers predefine
__SunOS_RELEASE, and gcc could be changed to mimic that.  Of course, the
test could always be made in configure one way or the other and the
outcome used in libdruntime, similarly to OS_Have_Dlpi_Tls_Modid.

> one option would be to provide posix_memalign internally in druntime.
>
> extern(D) int posix_memalign(void** ptr, size_t alignment, size_t size)
> {
>   // ...
> }
>
> extern(D) so that it won't conflict with extern(C) function of the same name.
>
> Though whether it is worth the effort, I'm not so sure.  As you've said that
> Solaris10 will be removed before.

Exactly: I've had a look at the open issues on Solaris 10.  The ones
above can certainly be worked around or avoided some way or another, but
there's a showstopper, I believe: the 64-bit x86 problem worked around
by ld -z relax=transtls also exists on Solaris 10, but the workaround
does not.  This means that we're either left with a 32-bit-only Solaris
10/x86 port or one that is only usable with gld.  While Solaris 10/SPARC
wouldn't be affected, SPARC is in considerably worse shape right now,
and I'm pretty certain our time would be far better spent fixing Solaris
11 issues: this will benefit way more users.  I doubt there are many
considering upgrading to gcc 9 on Solaris 10, let alone trying a new
language.

My suggestion would be to close the PR as WONTFIX.  Should there really
be demand, one could still apply Solaris 10 fixes to the GCC 9 branch
after the 9.1.0 release: there's considerable leeway for changes like
this and a new language.

[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #2 from Ramana Radhakrishnan  ---
I'll take a look.

[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #3 from Ramana Radhakrishnan  ---
Seems to have been "fixed" by the commit to fix PR87369,

Richard, is this something to backport ? Prima-facie , it appears not and we
will need an appropriate fix for the release branches.

[Bug c/90167] invalid example in GCC documentation wrt. effective type rules

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
But you are not accessing as the union type.  You do the access with the
type of one of its members.  And that is UB.

The part of the standard you quote is about things like

union a_union f(double *p) { return *(union a_union *)p; }

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||dmalcolm at gcc dot gnu.org
   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #5 from Jakub Jelinek  ---
I've been thinking about something like:
--- gcc/c/c-format.c.jj 2019-02-26 00:43:18.0 +0100
+++ gcc/c/c-format.c2019-04-23 16:44:54.552064471 +0200
@@ -1060,7 +1060,7 @@ static void check_format_types (const su
vec *arglocs);
 static void format_type_warning (const substring_loc &fmt_loc,
 location_t param_loc,
-format_wanted_type *, tree,
+format_wanted_type *, tree, tree,
 tree,
 const format_kind_info *fki,
 int offset_to_type_start,
@@ -3109,7 +3109,7 @@ check_format_types (const substring_loc
   if (!cur_param)
 {
  format_type_warning (fmt_loc, UNKNOWN_LOCATION, types, wanted_type,
-  NULL, fki, offset_to_type_start,
+  NULL, NULL, fki, offset_to_type_start,
   conversion_char);
   continue;
 }
@@ -3197,8 +3197,8 @@ check_format_types (const substring_loc
}
  else
{
- format_type_warning (fmt_loc, param_loc,
-  types, wanted_type, orig_cur_type, fki,
+ format_type_warning (fmt_loc, param_loc, types, wanted_type,
+  orig_cur_type, NULL, fki,
   offset_to_type_start, conversion_char);
  break;
}
@@ -3268,7 +3268,7 @@ check_format_types (const substring_loc
continue;
   /* Now we have a type mismatch.  */
   format_type_warning (fmt_loc, param_loc, types,
-  wanted_type, orig_cur_type, fki,
+  wanted_type, orig_cur_type, cur_param, fki,
   offset_to_type_start, conversion_char);
 }
 }
@@ -3339,7 +3339,7 @@ test_get_modifier_for_format_len ()
Wformat type errors where the argument has type ARG_TYPE.  */

 static bool
-matching_type_p (tree spec_type, tree arg_type)
+matching_type_p (tree spec_type, tree arg_type, tree cur_param)
 {
   gcc_assert (spec_type);
   gcc_assert (arg_type);
@@ -3353,14 +3353,29 @@ matching_type_p (tree spec_type, tree ar
   spec_type = TYPE_CANONICAL (spec_type);
   arg_type = TYPE_CANONICAL (arg_type);

+  if (spec_type == arg_type)
+return true;
+
   if (TREE_CODE (spec_type) == INTEGER_TYPE
   && TREE_CODE (arg_type) == INTEGER_TYPE
   && (TYPE_UNSIGNED (spec_type)
  ? spec_type == c_common_unsigned_type (arg_type)
  : spec_type == c_common_signed_type (arg_type)))
-return true;
+{
+  if (!warn_format_signedness)
+   return true;
+  if (TYPE_UNSIGNED (spec_type)
+ && cur_param != NULL_TREE
+ && TREE_CODE (cur_param) == NOP_EXPR)
+   {
+ tree t = TREE_TYPE (TREE_OPERAND (cur_param, 0));
+ if (TYPE_UNSIGNED (t)
+ && spec_type == lang_hooks.types.type_promotes_to (t))
+   return true;
+   }
+}

-  return spec_type == arg_type;
+  return false;
 }

 /* Subroutine of get_format_for_type.
@@ -3380,7 +3395,7 @@ matching_type_p (tree spec_type, tree ar

 static char *
 get_format_for_type_1 (const format_kind_info *fki, tree arg_type,
-  char conversion_char)
+  tree cur_param, char conversion_char)
 {
   gcc_assert (arg_type);

@@ -3402,7 +3417,7 @@ get_format_for_type_1 (const format_kind
  const format_type_detail *ftd = &spec->types[i];
  if (!ftd->type)
continue;
- if (matching_type_p (*ftd->type, effective_arg_type))
+ if (matching_type_p (*ftd->type, effective_arg_type, cur_param))
{
  const char *len_modifier
= get_modifier_for_format_len (fki->length_char_specs,
@@ -3439,7 +3454,7 @@ get_format_for_type_1 (const format_kind

 static char *
 get_format_for_type (const format_kind_info *fki, tree arg_type,
-char conversion_char)
+tree cur_param, char conversion_char)
 {
   gcc_assert (arg_type);
   gcc_assert (conversion_char);
@@ -3447,13 +3462,14 @@ get_format_for_type (const format_kind_i
   /* First pass: look for a format_char_info containing CONVERSION_CHAR
  If we find one, then presumably the length modifier was incorrect
  (or absent).  */
-  char *result = get_format_for_type_1 (fki, arg_type, conversion_char);
+ 

[Bug middle-end/90191] [9 regression] incorrect -Wformat-overflow with --param max-jump-thread-duplication-stmts=17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This particular warning is a late warning during optimizations, and as such has
the issues other late warnings have, various false positives, sometimes more,
sometimes less depending on how much jump threading is done; in some cases more
jump threading causes more false positives, in other cases fewer.

[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
(In reply to Ramana Radhakrishnan from comment #3)
> Seems to have been "fixed" by the commit to fix PR87369,
> 
> Richard, is this something to backport ? Prima-facie , it appears not and we
> will need an appropriate fix for the release branches.

Given that the patch for PR87369 eliminates the ICE, it's probably preferable
for backporting to a separate patch that is only used on the release branches. 
That patch has now been soaking on trunk for a while now, so is likely to be
pretty safe.

I am a bit worried however, that the patch papers over a likely trunk ICE that
isn't really fixed.  It would be nice to investigate further if some additional
mitigation is warranted.

[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This used to be accepted before r251433, which started rejecting it.
Before r257018, the diagnostics has been:
pr90172.C: In instantiation of ‘fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]:: [with
auto:1 = {fooV(Ts ...) [with Ts = {const char*, int, double, char, float, short
int, unsigned int}]::, const char*, int, double, char,
float, short int, unsigned int}]’:
pr90172.C:8:13:   required from ‘int fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]’
pr90172.C:13:65:   required from here
pr90172.C:3:10: error: use ‘...’ to expand argument pack
 auto M = [](decltype(a) ... b) -> void {
  ^
pr90172.C:5:12: error: unable to deduce lambda return type from ‘M’
 return M;
^
but in r257018 and onwards:
pr90172.C: In instantiation of ‘int fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]’:
pr90172.C:13:65:   required from here
pr90172.C:3:10: error: expansion pattern ‘decltype (#‘nontype_argument_pack’
not supported by dump_expr#)’ contains no argument packs
 auto M = [](decltype(a) ... b) -> void {
  ^
and finally starting with r268377 we also ICE during error recovery.

[Bug d/90130] gdc.test/runnable/test12.d FAILs

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
I think it should be done in r270485.

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

[ibuclaw at gcc dot gnu.org]

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

--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Tue Apr 23 15:19:55 2019
New Revision: 270514

URL: https://gcc.gnu.org/viewcvs?rev=270514&root=gcc&view=rev
Log:
PR d/90079
libphobos: Fix SEGV in _aaKeys, _aaValues on 32-bit SPARC

Merges upstream druntime b43203a1

Reviewed-on: https://github.com/dlang/druntime/pull/2572

Modified:
trunk/libphobos/libdruntime/MERGE
trunk/libphobos/libdruntime/object.d

[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor

[a...@cloudius-systems.com]

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

--- Comment #4 from Avi Kivity  ---
Since constexpr constructors do send the variable into the .data (or .tls)
section, perhaps gcc can attempt to evaluate the initializer as if it (and any
functions it calls) was marked constexpr. If it fails it can emit the guard and
initialization calls, but if it succeeds, we save some runtime to check those
guards.

[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So, I guess the rejects-valid part is a P2 8/9 regression (if the testcase is
really valid) and the ICE is error recovery regression for that (9 only).
For the latter, I guess something like:
--- gcc/cp/pt.c.jj  2019-04-22 16:03:23.0 +0200
+++ gcc/cp/pt.c 2019-04-23 17:21:01.898950417 +0200
@@ -18869,7 +18869,8 @@ tsubst_copy_and_build (tree t,
/* We aren't going to do normal overload resolution, so force the
   template-id to resolve.  */
function = resolve_nondeduced_context (function, complain);
-   for (unsigned i = 0; i < nargs; ++i)
+   unsigned int n_call_args = call_args->length ();
+   for (unsigned i = 0; i < n_call_args; ++i)
  {
/* In a thunk, pass through args directly, without any
   conversions.  */
@@ -18881,9 +18882,10 @@ tsubst_copy_and_build (tree t,
if (thisarg)
  {
/* Shift the other args over to make room.  */
-   vec_safe_push (call_args, (*call_args)[nargs-1]);
-   for (int i = nargs-1; i > 0; --i)
- (*call_args)[i] = (*call_args)[i-1];
+   tree last_arg = (*call_args)[n_call_args - 1];
+   vec_safe_push (call_args, last_arg);
+   for (int i = n_call_args - 1; i > 0; --i)
+ (*call_args)[i] = (*call_args)[i - 1];
(*call_args)[0] = thisarg;
  }
ret = build_call_a (function, call_args->length (),

could do the job, nargs doesn't take into account if there are more arguments
in call_args due to some pack expansion and also the vec_safe_push is broken
because (*call_args)[nargs-1] is just a reference and trying to push it if it
needs to reallocate is broken.
I have no idea if n_call_args could be 0 and thisarg non-NULL, if yes, we need
to just vec_safe_push (call_args, thisarg); in that case instead of moving
anything.

[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-23
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
  Component|c   |target
   Target Milestone|--- |8.4
Summary|[8 Regression] C code is|[8/9 Regression] C code is
   |optimized worse than C++|optimized worse than C++
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r257505.  A smaller regression happened already earlier with
r254855.  Before the latter, we emitted:
pushq   %rbp
movq%rdi, %rax
movq%rsp, %rbp
andq$-64, %rsp
vmovdqu32   16(%rbp), %zmm1
vpaddd  80(%rbp), %zmm1, %zmm0
vmovdqa64   %zmm0, -64(%rsp)
vmovdqa64   -64(%rsp), %xmm2
vmovdqa64   -48(%rsp), %xmm3
vmovdqa64   -32(%rsp), %xmm4
vmovdqa64   -16(%rsp), %xmm5
vmovups %xmm2, (%rdi)
vmovups %xmm3, 16(%rdi)
vmovups %xmm4, 32(%rdi)
vmovups %xmm5, 48(%rdi)
vzeroupper
leave
ret
r254855 then changed it into:
pushq   %rbp
movq%rsp, %rbp
andq$-32, %rsp
movq%rdi, %rax
vmovdqu32   16(%rbp), %ymm2
vpaddd  80(%rbp), %ymm2, %ymm0
vmovq   %xmm0, %rdx
vmovdqa64   %ymm0, -64(%rsp)
vmovdqu32   48(%rbp), %ymm3
vpaddd  112(%rbp), %ymm3, %ymm0
vmovdqa64   %ymm0, -32(%rsp)
movq%rdx, (%rdi)
movq-56(%rsp), %rdx
movq%rdx, 8(%rdi)
movq-48(%rsp), %rdx
movq%rdx, 16(%rdi)
movq-40(%rsp), %rdx
movq%rdx, 24(%rdi)
vmovq   %xmm0, 32(%rax)
movq-24(%rsp), %rdx
movq%rdx, 40(%rdi)
movq-16(%rsp), %rdx
movq%rdx, 48(%rdi)
movq-8(%rsp), %rdx
movq%rdx, 56(%rdi)
vzeroupper
leave
ret
After the r257505 we seem to be versioning for alignment or so, that can't be
right for a loop with just 16 iterations.

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

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to nfxjfg from comment #6)
> Yes, it's clear that that the constraint can't be _just_ the register name,
> since they'll clash with builtin constraints now or with future
> architectures (which may add arbitrary register names). The proposed
> "*registername" is pretty nice, though. Having this would be great.

Hrm, "*" already has a meaning with current GCC (it essentially is ignored
in inline asm)...  It might be better to have some new syntax that gives an
error with older GCC.

> I didn't find a RISC-V builtin for ecall (maybe I looked in the wrong
> place). That wouldbn't be sufficient anyway.

Right, you would need a builtin for every calling convention for syscalls.
The aren't too many of those though?

> Another situation where I
> wanted to specify many fixed register constraints was a piece of inline code
> that did some syscalls without touching the stack (it needed all inputs as
> registers, and in specific registers, and have some registers for free use
> by the asm code itself).

A biggish piece of asm like that might be better as actual assembler code
than as inline asm, you may want to consider that?

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This changed with r255569.
Using -gno-statement-frontiers helps here even with recent-ish trunk.

[Bug tree-optimization/90078] [7/8 Regression] ICE with deep templates caused by overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with
   |deep templates caused by|deep templates caused by
   |overflow [PATCH]|overflow
  Known to fail|9.0 |

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

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #20 from kelvin at gcc dot gnu.org ---
Patch has been committed to trunk and backported to gcc8 and gcc7.

[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-23
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #57 from Jeffrey A. Law  ---
So what's actually left to do with this BZ?  ie, what tests are still
regressing?

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[jg at jguk dot org]

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

--- Comment #6 from Jonny Grant  ---
Wondering if it is also worth the message making clear the type was promoted?

eg:

:5:14: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'float' automatically promoted to 'double', for which '%f'
is required [-Wformat=]

5 | printf("%d", i);
  | ~^   ~
  |  |   |
  |  int float
  | %f

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[jakub at gcc dot gnu.org]

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

--- Comment #58 from Jakub Jelinek  ---
If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be
still useful without it (does it ever trigger say on the kernel where it didn't
trigger before)?

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
For the for loop, we emit a DEBUG_BEGIN_STMT, which maps to DWARF:
is_stmt
'A boolean indicating that the current instruction is a recommended breakpoint
location. A recommended breakpoint location is intended to “represent” a line,
a statement and/or a semantically distinct subpart of a statement.'

I would think that for a C/C++ normal for loop we should emit a recommanded
breakpoint location not just at the start of the whole statement (== at the
start of the init expression), but also at the start of the increment
expression and maybe also at the start of the condition (though not sure about
that, perhaps it is enough to have just one on the increment expression and
cover the condition through the recommended breakpoint location at the start of
the whole for loop and before the increment expression.
Wonder about other loop constructs too.

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
  int i = 0;
  while (i < count)
dst[i++] = (base += 15);
}

int
main (void)
{
  unsigned int dst[100];
  test (dst, 0x4000, 100);
}

and

__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
  int i = 0;
  do
dst[i++] = (base += 15);
  while (i < count);
}

int
main (void)
{
  unsigned int dst[100];
  test (dst, 0x4000, 100);
}

show that too.  For the do while loop, not sure if we shouldn't have something
also one recommended location at the start of the do/while loop on do line,
then of course in the body and then on the while condition.  For while loop at
the start of the condition.  Also, in C++ we have range-for loops that need
some thinking too.

[Bug rtl-optimization/90209] codegen regression (x < 0 ? -x : x) results in branch instead of single instruction on x86_64

[vegard.nossum at oracle dot com]

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

Vegard Nossum  changed:

   What|Removed |Added

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

--- Comment #2 from Vegard Nossum  ---
x < 0 will be false for x == -0. and therefore the return value will be -0.,
which it won't be with just the "andpd". Closing as invalid

[Bug c++/90215] New: ICE with lambda in fold expression over comma and assignment

[vittorio.romeo at outlook dot com]

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

Bug ID: 90215
   Summary: ICE with lambda in fold expression over comma and
assignment
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

The following code

#include 

template 
struct X
{
template 
void f(F f)
{
f(0);
}
};

template 
void bug(X... xs)
{
std::tuple t;

std::apply([&](auto&... ys)
{   
(xs.f([&](auto y)
{
ys = y;
}), ...);
}, t);
}

int main()
{
bug(X{});
} 

produces an ICE with g++ trunk (version 9.0.1 20190422):

:22:16: internal compiler error: in tsubst_copy, at cp/pt.c:15551
 22 | ys = y;
| ~~~^~~

The bug can be reproduced on godbolt.org here:
https://gcc.godbolt.org/z/NNLI5p

[Bug c++/90215] ICE with lambda in fold expression over comma and assignment

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-23
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/90215] ICE with lambda in fold expression over comma and assignment

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||needs-reduction
   Target Milestone|--- |8.4

--- Comment #2 from Marek Polacek  ---
The ICE started with r251433.  Before:
90215.C: In lambda function:
90215.C:22:20: error: parameter packs not expanded with ‘...’:
90215.C:22:20: note: ‘__ys’

[Bug c++/86044] noexcept(false) of constexpr member function ignored

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
In C++14, this is conforming behavior per N4140 [expr.unary.noexcept]/3:
"""
3. The result of the noexcept operator is false if in a potentially-evaluated
   context the expression would contain
3.1 - a potentially-evaluated call to a function, member function, function
  pointer, or member function pointer that does not have a non-throwing
  exception-specification, unless the call is a constant expression,
[...]
"""

In C++17 and later, it is not conforming per [expr.unary.noexcept]/3:
"""
3 The result of the noexcept operator is true unless the expression is 
  potentially-throwing ([except.spec]).
""
and [except.spec]/6 which defines "potentially-throwing" and includes no
mention of constant expressions (I won't duplicate the full text here).

[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
What's confusing to me is that, as far as I know, GDB pays no attention to
is_stmt yet.


So I think we should focus on what, if any, changes to the line number program
are brought about by enabling or disabling the SFN option.


That said, markers at increments and conditions, besides loop headers, is
definitely something we should have.  I'm more than surprised they aren't
there.

[Bug c++/86044] noexcept(false) of constexpr member function ignored

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Resolved by my r270320.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #59 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #58)
> If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be
> still useful without it (does it ever trigger say on the kernel where it
> didn't trigger before)?

The patch in comment 44 is obviously good, it improves the size by 0.090%
as noted (this is a kernel build, multi_v5_defconfig iirc).

I'd say it is perfectly safe for GCC 9, but I'm not an Arm maintainer :-)

[Bug translation/90119] Merge translation msgids that only differ in placeholders

[roland.illig at gmx dot de]

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

--- Comment #6 from Roland Illig  ---
(In reply to Martin Liška from comment #5)
> Thank you Roland for working on that. Can you please integrate your script
> with:
> contrib/check-internal-format-escaping.py

No, I cannot. Integrating it doesn't make sense. In bug 90176 I posted the most
recent version of my work. Reading the gcc.pot file line by line doesn't make
sense anymore, since that prevents the more interesting linter checks (such as
the one checking for structurally equivalent msgids) from working.

I converted the existing program to using polib exactly for the purpose of
having more advanced checks than are possible with the current code base.

To the best of my knowledge I have preserved all current linter checks.

[Bug c++/68092] [C++1z] error: Two symbols with same comdat_group are not linked by the same_comdat_group list.

[herring at lanl dot gov]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #7 from S. Davis Herring  ---
Created attachment 46233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46233&action=edit
ICE output from variable template test

This simple test case produces a similar ICE (with current trunk at Compiler
Explorer):

  int i;
  template extern const int v=i++;

  void f();
  const int j=v;

  int g() {
void f();
return v;
  }

Making v have internal linkage makes it go away.  If this should be a separate
bug, please let me know.

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
It ended up being a little more work, as the proposed patch had a bug in it. 
But it's now done in r270514.

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Jonny Grant from comment #6)
> Wondering if it is also worth the message making clear the type was promoted?
> 
> eg:
> 
> :5:14: warning: format '%d' expects argument of type 'int', but
> argument 2 has type 'float' automatically promoted to 'double', for which
> '%f' is required [-Wformat=]
> 
> 5 | printf("%d", i);
>   | ~^   ~
>   |  |   |
>   |  int float
>   | %f

Maybe, but the message would be getting pretty long by that point...

[Bug translation/90176] diagnostics should generally contain underscore only inside quotes

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

  Attachment #46212|0   |1
is obsolete||

--- Comment #4 from Roland Illig  ---
Created attachment 46234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46234&action=edit
linter uses polib and checks for several new inconsistencies

[Bug translation/90119] Merge translation msgids that only differ in placeholders

[roland.illig at gmx dot de]

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

--- Comment #7 from Roland Illig  ---
I didn't want to sound that harsh in my previous comment.

What I wanted to say is: to make the linter reliable and be able to handle the
full syntax of .po files, it's better to use an exising library that is
well-tested instead of parsing .po files ad-hoc using regular expressions and
raw string functions.

That way the code of the linter becomes easy to read since it uses the standard
terminology of the .po structures, and it is easy to access all gettext
features (such as plurals or other formats) without modifying the parser code.

It also becomes easier to add new checks to the linter.

The diagnostics of the linter now follow more closely the GCC Guidelines for
Diagnostics, by offering guidance and saying what the actual possible problem
is, instead of only pointing to the problematic message.

This of course requires a bit more code than the current linter.

I have checked that my rewrite preserves all existing features of the linter. I
don't think adding new features to the current architecture of the linter makes
sense since it requires more work than absolutely necessary. To add a new
linter check, it shouldn't be necessary to modify any .po file format parser.
Therefore I think replacing the current linter with the latest suggested code
from bug 90176 actually makes sense.

[Bug c++/86044] noexcept(false) of constexpr member function ignored

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yes, this was a duplicate of PR 87603.

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #8 from Tavian Barnes  ---
Maybe "argument 2 has type 'double' (promoted from 'float')"?

[Bug c++/90216] New: Stack Pointer decrementing even when not loading extra data to stack.

[stevexiong98 at hotmail dot com]

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

Bug ID: 90216
   Summary: Stack Pointer decrementing even when not loading extra
data to stack.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevexiong98 at hotmail dot com
  Target Milestone: ---

Hi,

Using ARM GCC 8.2, when I instantiate an object the corresponding Assembly
instructions involve a decrementing, then incrementing of the stack pointer.
However, no values are being transferred between the registers and the empty
stack space. 

Please check out this link for details, lines 5 and 7 in the Assembly panel
show how the stack pointer is decremented/incremented unnecessarily.

https://godbolt.org/z/h-H7Ox

In the C++ panel when you comment out line 53 and uncomment the line below, the
Assembly instructions involving the stack pointer disappear. The same is true
if you uncomment just line 55.

Can you please explain why the stack pointer inc/dec operations are not
optimized out in the first line of code (line 53)? Can you please try to
release a patch where this unnecessary stack pointer inc/dec is no longer an
issue?

Thanks