[Bug middle-end/89303] [7 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.3 |7.5
Summary|[7/8 Regression] memory |[7 Regression] memory leak
   |leak with shared_ptr and|with shared_ptr and
   |enable_shared_from_this |enable_shared_from_this

--- Comment #27 from Jakub Jelinek  ---
Fixed for 8.3+ as well.

[Bug target/89290] [8 Regression] ICE in change_address_1, at emit-rtl.c:2286

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/89303] [7/8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 07:41:51 2019
New Revision: 268866

URL: https://gcc.gnu.org/viewcvs?rev=268866=gcc=rev
Log:
Backported from mainline
2019-02-13  Jakub Jelinek  

PR middle-end/89303
* tree-ssa-structalias.c (set_uids_in_ptset): Or in vi->is_heap_var
into pt->vars_contains_escaped_heap instead of setting
pt->vars_contains_escaped_heap to it.

2019-02-13  Jonathan Wakely  
Jakub Jelinek  

PR middle-end/89303
* g++.dg/torture/pr89303.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89303.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-structalias.c

[Bug middle-end/89281] [9 Regression] gcc/optabs.c:3901:30: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 07:40:33 2019
New Revision: 268865

URL: https://gcc.gnu.org/viewcvs?rev=268865=gcc=rev
Log:
Backported from mainline
2019-02-13  Jakub Jelinek  

PR middle-end/89281
* optabs.c (prepare_cmp_insn): Use UINTVAL (size) instead of
INTVAL (size), compare it to GET_MODE_MASK instead of
1 << GET_MODE_BITSIZE.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/optabs.c

[Bug middle-end/89246] LTO produces references to cloned symbols which the compiler failed to clone

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 07:38:52 2019
New Revision: 268863

URL: https://gcc.gnu.org/viewcvs?rev=268863=gcc=rev
Log:
Backported from mainline
2019-02-09  Jakub Jelinek  

PR middle-end/89246
* config/i386/i386.c (ix86_simd_clone_compute_vecsize_and_simdlen):
If !node->definition and TYPE_ARG_TYPES is non-NULL, use
TYPE_ARG_TYPES instead of DECL_ARGUMENTS.

* gcc.dg/gomp/pr89246-1.c: New test.
* gcc.dg/gomp/pr89246-2.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/gomp/pr89246-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/gomp/pr89246-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/89290] [8 Regression] ICE in change_address_1, at emit-rtl.c:2286

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 07:39:46 2019
New Revision: 268864

URL: https://gcc.gnu.org/viewcvs?rev=268864=gcc=rev
Log:
Backported from mainline
2019-02-13  Jakub Jelinek  

PR target/89290
* config/i386/predicates.md (x86_64_immediate_operand): Allow
TLS UNSPECs offsetted by signed 32-bit CONST_INT even with
-mcmodel=large.

* gcc.target/i386/pr89290.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89290.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/predicates.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 07:31:14 2019
New Revision: 268862

URL: https://gcc.gnu.org/viewcvs?rev=268862=gcc=rev
Log:
PR middle-end/89284
* passes.def: Swap pass_ubsan and pass_early_warn_uninitialized.

* gcc.dg/ubsan/pr89284.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr89284.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
Thanks very much for reducing the test case.

I sent out the fix for review at https://golang.org/cl/162618.  It should be
committed shortly.

[Bug other/89347] gc-sections doesn't remove unused bss section variables.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |other
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
You need -fno-common instead:
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Code-Gen-Options.html#index-fno-common

-fno-common
In C code, this option controls the placement of global variables defined
without an initializer, known as tentative definitions in the C standard.
Tentative definitions are distinct from declarations of a variable with the
extern keyword, which do not allocate storage.

Unix C compilers have traditionally allocated storage for uninitialized global
variables in a common block. This allows the linker to resolve all tentative
definitions of the same variable in different compilation units to the same
object, or to a non-tentative definition. This is the behavior specified by
-fcommon, and is the default for GCC on most targets. On the other hand, this
behavior is not required by ISO C, and on some targets may carry a speed or
code size penalty on variable references.

The -fno-common option specifies that the compiler should instead place
uninitialized global variables in the data section of the object file. This
inhibits the merging of tentative definitions by the linker so you get a
multiple-definition error if the same variable is defined in more than one
compilation unit. Compiling with -fno-common is useful on targets for which it
provides better performance, or if you wish to verify that the program will
work on other systems that always treat uninitialized variable definitions this
way.

[Bug c/89347] gc-sections doesn't remove unused bss section variables.

[maninder1.s at samsung dot com]

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

Maninder Singh  changed:

   What|Removed |Added

 CC||maninder1.s at samsung dot com

--- Comment #1 from Maninder Singh  ---
Fixing [#89347] gc-sections doesn't remove unused bss section variables.

gc-section works well only for bss section if global variables initialised
with 0 explicitly and not with uninitalised one.
Reason is -fdata-sections does not make separate section for bss symbols
which are not initialised with 0 explicitly.
due to which gc-section does not remove bss symbols which are not
getting used in binary.

Signed-off-by: Vaneet Narang 
Signed-off-by: Maninder Singh 
---
 gcc/varasm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 0be44f1..1f68c3a 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1164,7 +1164,7 @@ get_variable_section (tree decl, bool prefer_noswitch_p)
  && ADDR_SPACE_GENERIC_P (as));
   if (DECL_THREAD_LOCAL_P (decl))
return tls_comm_section;
-  else if (TREE_PUBLIC (decl) && bss_initializer_p (decl))
+  else if (TREE_PUBLIC (decl) && bss_initializer_p (decl) &&
!flag_data_sections)
return comm_section;
 }

--
1.9.1

[Bug c/89347] New: gc-sections doesn't remove unused bss section variables.

[maninder1.s at samsung dot com]

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

Bug ID: 89347
   Summary: gc-sections doesn't remove unused bss  section
variables.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maninder1.s at samsung dot com
  Target Milestone: ---

code snippet:-

int init_bss_unused[10] = {0}; // explicilty initialised with 0
int init_bss_used[10] = {0}; //  explicilty initialised with 0
int uninit_bss_unused[10];
int uninit_bss_used[10];

int main()
{
uninit_bss_used[5] = 6;
init_bss_used[5]  = 7;
return 0;
}

$gcc -fdata-sections -ffunction-sections -Wl,--gc-sections bss.c
$nm -a | grep _bss_
00020714 B init_bss_used  // removed init_bss_unused.
00020764 B uninit_bss_unused  // not removed.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337

   What|Removed |Added

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

[Bug testsuite/86153] [8 regression] test case g++.dg/pr83239.C fails starting with r261585

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||rafael at espindo dot la

--- Comment #15 from Martin Sebor  ---
*** Bug 89337 has been marked as a duplicate of this bug. ***

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Thank you for the updated test case.  The original looked similar to bug 86153
to me at first but then I decided it was different.  The new test case is very
close to the one in that bug, and is not diagnosed with the top of trunk
anymore thanks to the fix in r267252.  I think it's safe to resolve this as a
duplicate of that bug.  Let me add your test case to the test suite.  (If the
warning persists in your code even with the latest GCC 9.0 please reopen the
bug with an updated test case.)

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

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
I kindasorta thought that's what I want. ;-)  But now that I understand what
you're saying, I believe I agree with you that this is probably a problem in
our gimple folding.  I am going to shut up now and stay out of your way, as I
believe you have a much better grasp on this than I do at the moment...

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-14
 CC||amodra at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra  ---
I believe this is a bug in rs6000_register_move_cost. Testing a fix.

[Bug c++/89244] __builtin_is_constant_evaluated not documented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01000.html

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[rafael at espindo dot la]

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

Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337

   What|Removed |Added

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

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

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

--- Comment #5 from Rafael Avila de Espindola  ---
Reopening with an expanded testcase.

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #45704|0   |1
is obsolete||

--- Comment #4 from Rafael Avila de Espindola  ---
Created attachment 45710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45710=edit
testcase where the string size should still be visible to the compiler

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[sean.wang at wdc dot com]

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

--- Comment #5 from sean.wang at wdc dot com ---
Created attachment 45709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45709=edit
code sample for reproducing reported error

code sample for reproducing reported error is attached.

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Thanks for the analysis!

(In reply to Vladimir Makarov from comment #1)
> The very first ira-costs pass runs in sched1 and it generates the following
> costs
>   r125 costs: BASE_REGS:1 GENERAL_REGS:1 LINK_REGS:2
> CTR_REGS:2 LINK_OR_CTR_REGS:2 SPEC_OR_GEN_REGS:2 MEM:8000

> Why does IRA calculate such costs?  We have 2 insns involving p125
>15: r125:DI=%3:DI
>  REG_DEAD %3:DI
> 7: {r123:SI=asm_operands/*r125 with constraint 'v'*/;clobber ca:SI;}
> 
> Cost of moving r3 into p125 is 2 for base regs and 4 for memory
> Cost of moving p125 into a v reg is 8 for base regs and 4 for memory

Ah, so we we need to improve that.

This is power8, where mtvsr insns are still a bit expensive, but not more
expensive than memory.

> Therefore cost of p125 is 10 for base reg and 8 for memory (multiplied by BB
> frequency 1).
> 
> Therefore IRA chooses memory for p125.
> 
> In this particular case insn 15 can go away when we assign r3 to p125.  It
> means the cost for base reg could be 8 as for memory but IRA can not say in
> general case that it can assign r3 to p125.
> 
> I think increasing memory move cost at least to 5 could solve the problem. 
> But probably it needs benchmarking SPEC, besides running GCC testsuite, to
> see that the performance is not worse after such change.

Agreed.

[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
Patch submitted:

https://gcc.gnu.org/ml/fortran/2019-02/msg00112.html

[Bug target/89346] New: Unnecessary EVEX encoding

[hjl.tools at gmail dot com]

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

Bug ID: 89346
   Summary: Unnecessary EVEX encoding
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-skx-1 gcc]$ cat x.c
#include 

long long *p;
volatile __m256i yy;

void
foo (void)
{
   _mm256_store_epi64 (p, yy);
}
[hjl@gnu-skx-1 gcc]$ gcc -S -O2 x.c -march=skylake-avx512
[hjl@gnu-skx-1 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB5168:
.cfi_startproc
vmovdqa64   yy(%rip), %ymm0   <<< No need for EVEX.
movqp(%rip), %rax
vmovdqa64   %ymm0, (%rax) <<< No need for EVEX.
vzeroupper
ret
.cfi_endproc
.LFE5168:
.size   foo, .-foo
.comm   yy,32,32
.comm   p,8,8
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[mib.bugzilla at gmail dot com]

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

--- Comment #4 from mib.bugzilla at gmail dot com ---
thank you!

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Feb 13 22:13:45 2019
New Revision: 268856

URL: https://gcc.gnu.org/viewcvs?rev=268856=gcc=rev
Log:
PR libstdc++/89345 Only define std::destroying_delete for C++2a

Clang defines the __cpp_impl_destroying_delete macro unconditionally, so
that the feature is supported whenever the library type is defined. This
is incompatible with the current definition in libstdc++ because we use
constexpr and inline variables, which will give an error for older -std
modes.

This patch defines the destroying_delete_t type and destroying_delete
variable independently of the __cpp_impl_destroying_delete macro, but
only for C++2a (because the names aren't reserved for previous
standards). The __cpp_lib_destroying_delete macro is only defined when
both the library type and compiler macro are defined (i.e. when the type
can actually be used as intended).

PR libstdc++/89345
* include/std/version [__cpp_impl_destroying_delete]
(__cpp_lib_destroying_delete): Only define for C++2a and later.
* libsupc++/new [__cpp_impl_destroying_delete]
(__cpp_lib_destroying_delete): Likewise.
(destroying_delete_t, destroying_delete): Likewise, but define even
when __cpp_impl_destroying_delete is not defined.
* testsuite/18_support/destroying_delete.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/18_support/destroying_delete.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/version
trunk/libstdc++-v3/libsupc++/new

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Done

[Bug c++/67491] [meta-bug] concepts issues

[redi at gcc dot gnu.org]

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

Bug 89300 Summary: C++ requires statement does not fail silently for const void 
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300

   What|Removed |Added

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

[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 Ever confirmed|0   |1

[Bug c++/89300] C++ requires statement does not fail silently for const void *

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
It certainly does, thanks.

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

[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||svenja.mehringer at gmail dot 
com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 89300 has been marked as a duplicate of this bug. ***

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 45708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45708=edit
Patch that detects and issues an error.

Patch that detects and issues an error.  Trunk is in stage 4, so the patch will
likely get committed after 9.1 is released.

[Bug target/89343] Some MMX instructions aren't properly marked

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
There is nothing wrong with MMX alternatives in SSE patterns. MMX registers can
carry V2SI/V2SF values as well, and these alternatives will be correctly
disabled with -mno-mmx.

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
My version of gfortran gives

% gfcx -c a.f90
a.f90:8:35:

8 |type is (integer);  value=10
  |   1
Error: Dummy argument 'value' with INTENT(IN) in variable definition context
(assignment) at (1)
a.f90:9:35:

9 |type is (real); value=10.20
  |   1
Error: Dummy argument 'value' with INTENT(IN) in variable definition context
(assignment) at (1)

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I already started fixing this after your update to the phabricator update
pinged me an email. I'm just going to make it conditional on __cplusplus >
201703L.

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-13
  Component|c++ |libstdc++
Version|unknown |9.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #45705|0   |1
is obsolete||

--- Comment #21 from H.J. Lu  ---
Created attachment 45707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45707=edit
A new patch

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Feb 13 21:39:18 2019
New Revision: 268854

URL: https://gcc.gnu.org/viewcvs?rev=268854=gcc=rev
Log:
PR c++/89297 - ICE with OVERLOAD in template.
* semantics.c (finish_compound_literal): Call
instantiate_non_dependent_expr_sfinae.

* g++.dg/cpp0x/initlist113.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist113.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---

> This is because IRA does
> 
>  r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS
> 
>a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004-
>LINK_REGS:24010,24010 CTR_REGS:24010,24010 LINK_OR_CTR_REGS:24010,24010-
>SPEC_OR_GEN_REGS:24010,24010 MEM:12000,12000
> 
> and it then chooses disposition mem for r125.
> 
> In GCC 8 and before combine already has decided to use GPR3 (the first
> argument register) for this, so there was no RA here before.

The very first ira-costs pass runs in sched1 and it generates the following
costs
  r125 costs: BASE_REGS:1 GENERAL_REGS:1 LINK_REGS:2 CTR_REGS:2
LINK_OR_CTR_REGS:2 SPEC_OR_GEN_REGS:2 MEM:8000

The costs in IRA are bit different because we calculate costs knowing our
preference for p125 as NO_REGS.

Why does IRA calculate such costs?  We have 2 insns involving p125
   15: r125:DI=%3:DI
 REG_DEAD %3:DI
7: {r123:SI=asm_operands/*r125 with constraint 'v'*/;clobber ca:SI;}

Cost of moving r3 into p125 is 2 for base regs and 4 for memory
Cost of moving p125 into a v reg is 8 for base regs and 4 for memory

Therefore cost of p125 is 10 for base reg and 8 for memory (multiplied by BB
frequency 1).

Therefore IRA chooses memory for p125.

In this particular case insn 15 can go away when we assign r3 to p125.  It
means the cost for base reg could be 8 as for memory but IRA can not say in
general case that it can assign r3 to p125.

I think increasing memory move cost at least to 5 could solve the problem.  But
probably it needs benchmarking SPEC, besides running GCC testsuite, to see that
the performance is not worse after such change.

[Bug c++/89300] C++ requires statement does not fail silently for const void *

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
This seems to be a duplicate of #78173.

[Bug tree-optimization/89283] [8/9 Regression] ICE: Segmentation fault (in stmt_could_throw_1_p)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
At 008t.lower we have:

sz (int i0)
{
  int D.1911;

  D.1911 = zn ();
  goto ;
  _1 = i0 + 1;
  _2 = zn ();
  _3 = _1 >= _2;
  D.1911 = (int) _3;
  goto ;
  :
  return D.1911;
}

It then tried to build the CFG, but dies verifying it, accessing a freed
SSA_NAME:

(gdb) call debug_tree (t)
 

The SSA_NAME is freed because the BB is deleted during CFG creation, in
cleanup_control_flow_pre here:
780   basic_block bb = BASIC_BLOCK_FOR_FN (cfun, i);
781   if (bb && !bitmap_bit_p (visited, bb->index))
782 {
783   if (!retval)
784 free_dominance_info (CDI_DOMINATORS);
785   delete_basic_block (bb);
786   retval = true;
787 }

Presumably that code needs to handle whatever it is that "returns_twice" does
to the function.

[Bug c++/89336] internal compiler error when compiling a constexpr function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 45706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45706=edit
gcc9-pr89336.patch

Untested fix.  Pointing a pointer into a middle of vector that might be
reallocated or where new elements might be added before the one to which we
store (and that addition memmoves all the rest upwards) is dangerous.

This patch should fix that, except that it doesn't fix union handling.  I think
e.g.
constexpr int foo () {
  union U { int a; long b; };
  union V { union U u; short v; };
  V w {};
  w.u.a = w.v = w.u.b = 5L;
  return w.u.a;
}
static_assert (foo () == 5, "");

ICEs with it (previously it would fail).  Is the testcase valid C++?
clang++ rejects it.  The question is when exactly becomes a union member active
on the assignment, if only after evaluating the rhs, or it first becomes active
member, then rhs is evaluated.

[Bug c/89341] ICE in get, at cgraph.h:1332

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Fails here in cgraph_node::get:

1332gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL);

639   if (alias)
640 resolve_alias (cgraph_node::get (alias_target), transparent_alias);

where "decl" == "alias_target" == the IDENTIFIER_NODE "bar", not a
FUNCTION_DECL.

[Bug c++/89345] New: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

[mib.bugzilla at gmail dot com]

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

Bug ID: 89345
   Summary: gcc9  uses constexpr token, can you change to
_GLIBCXX_CONSTEXPR ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com
  Target Milestone: ---

In the patch to add destroying_delete, (Implement P0722R3, destroying operator
delete.) the constexpr token is used directly, can you modify this to use the
macro e.g. _GLIBCXX_CONSTEXPR. For example, recently the clang compiler
predefines __cpp_impl_destroying_delete and this causes the  header to
fail compilation if compiling with option -std=c++98.  

This issue is discussed here, https://reviews.llvm.org/D55741

Thanks and regards
--Melanie Blower
(I work on the Intel C++ compiler)

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

[urbanjost at comcast dot net]

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

urbanjost at comcast dot net changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|intent  |uncaught programmer error:
   ||polymorphic variable is
   ||INTENT(IN) but assigned to
   ||without error

--- Comment #1 from urbanjost at comcast dot net ---
program demo_setval
   call setval(value)
   write(*,*)'VALUE=',value
CONTAINS
   subroutine setval(value)
  class(*),intent(in)  :: value
  select type(value)
   type is (integer);  value=10
   type is (real); value=10.20
  end select
   end subroutine setval
end program demo_setval
! expect to get something like
!Error: Dummy argument 'value' with INTENT(IN) in variable definition
context (assignment) at (1)
! but do not even though VALUE is INTENT(IN) and changed the value


There is a programmer error in the example program. The variable VALUE has been
declared to be INTENT(IN) but the routine assigns a value to the variable. This
should be caught at compile time.

[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

--- Comment #14 from kelvin at gcc dot gnu.org ---
To reconcile comments 12 and 13, the subtle issue is that we don't even get
into the altivec_resolve_overloaded_builtin function for the following code:

  vec_extract (vi, 10);

The gimple expander replaces this code with BIT_FIELD_REF <> before even
attempting to expand this overloaded builtin.

However, in the case that the "identical" code is represented by inlined
function X, we do come through altivec_resolve_overloaded_builtin.

int X (vector int vi, int index) {
  return vec_extract (vi, index);
}
...
X (vi, 10)


There are "two" ways to fix this problem.  Either we can make the gimple
expansion of in-lined functions match the non-inlined functions, or we can
insert code into altivec_resolve_overloaded_builtin to accommodate the
inconsistencies.

I gather you prefer I address this within altivec_resolve_overloaded_builtin.

I'll pursue this unless directed otherwise.

[Bug fortran/89344] New: intent

[urbanjost at comcast dot net]

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

Bug ID: 89344
   Summary: intent
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

--- Comment #3 from Rafael Avila de Espindola  ---

> GCC can't see that drop3() cannot be called with name.size() < 3, and in
> resize, the condition (n > size()) can only be true only when name.size() <
> 3 so n - size() is unavoidably too large.

That is why gcc should not warn about it :-)

The original testcase had

  if (boost::algorithm::ends_with(name, "%2A")) {
  name.resize(name.length() - 3);

I think it is fair to say that:

* The code is valid, if something ends with "%2A" the size is >= 3.
* GCC should not be required to figure out the above implication.
* The developer should not be required to add a __builtin_unreachable() to
avoid a warning in the above code.

I will re reduce the testcase keeping the ends_with and attach.

[Bug c++/86379] [8 Regression] Class member access of |using|'d field goes horribly awry in presence of templates

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] Class  |[8 Regression] Class member
   |member access of |using|'d  |access of |using|'d field
   |field goes horribly awry in |goes horribly awry in
   |presence of templates   |presence of templates
  Known to fail|9.0 |

--- Comment #6 from Alexandre Oliva  ---
Fixed for GCC 9.

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Blocks||88443
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
In the test case from attachment 45704:

  struct sstring {
size_t _size;
sstring(size_t size) : _size(size) { memset(begin(), '\n', size); }
size_t size() const noexcept { return _size; }
void resize(size_t n) {
  if (n > size()) {
sstring x(n - size());
  }
}
char *begin();
  };
  void drop3(sstring ) { name.resize(name.size() - 3); }

GCC can't see that drop3() cannot be called with name.size() < 3, and in
resize, the condition (n > size()) can only be true only when name.size() < 3
so n - size() is unavoidably too large.

To avoid the warning make the precondition explicit:

  void drop3(sstring )
  {
if (name.size () < 3)
__builtin_unreachable ();

name.resize(name.size() - 3);
  }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337

   What|Removed |Added

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

[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Feb 13 19:08:52 2019
New Revision: 268851

URL: https://gcc.gnu.org/viewcvs?rev=268851=gcc=rev
Log:
[PR86379] do not use TREE_TYPE for USING_DECL_SCOPE

It's too risky to reuse the type field for USING_DECL_SCOPE.
Language-independent parts of the compiler, such as location and
non-lvalue wrappers, happily take the TREE_TYPE of a USING_DECL as if
it was a type rather than an unrelated scope.

For better or worse, USING_DECLs use the non-common struct so we can
use the otherwise unused result field.  Adjust fallout, from uses of
TREE_TYPE that were supposed to be USING_DECL_SCOPE, to other
accidental uses of TREE_TYPE of a USING_DECL.


for  gcc/cp/ChangeLog

PR c++/86379
* cp-tree.h (USING_DECL_SCOPE): Use result rather than type.
* name-lookup.c (strip_using_decl): Use USING_DECL_SCOPE.
* search.c (protected_accessible_p): Follow USING_DECL_DECLS.
(shared_member_p): Likewise.
(lookup_member): Likewise.
* decl.c (grok_special_member_properties): Skip USING_DECLs.
* semantics.c (finish_omp_declare_simd_methods): Likewise.
(finish_qualified_id_expr): Do not call shared_member_p with
a dependent expr.

for  gcc/testsuite/ChangeLog

PR c++/86379
* g++.dg/cpp0x/pr86379.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr86379.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/search.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89343] New: Some MMX instructions aren't properly marked

[hjl.tools at gmail dot com]

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

Bug ID: 89343
   Summary: Some MMX instructions aren't properly marked
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

(define_insn "*vec_concatv2sf_sse4_1"
  [(set (match_operand:V2SF 0 "register_operand"
          "=Yr,*x, v,Yr,*x,v,v,*y ,*y")
        (vec_concat:V2SF
          (match_operand:SF 1 "nonimmediate_operand"
          "  0, 0,Yv, 0,0, v,m, 0 , m")
          (match_operand:SF 2 "nonimm_or_0_operand"
          " Yr,*x,Yv, m,m, m,C,*ym, C")))]
  "TARGET_SSE4_1 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
  "@
   unpcklps\t{%2, %0|%0, %2}
   unpcklps\t{%2, %0|%0, %2}
   vunpcklps\t{%2, %1, %0|%0, %1, %2}
   insertps\t{$0x10, %2, %0|%0, %2, 0x10}
   insertps\t{$0x10, %2, %0|%0, %2, 0x10}
   vinsertps\t{$0x10, %2, %1, %0|%0, %1, %2, 0x10}
   %vmovss\t{%1, %0|%0, %1}
   punpckldq\t{%2, %0|%0, %2}
   movd\t{%1, %0|%0, %1}"
  [(set (attr "isa")
     (cond [(eq_attr "alternative" "0,1,3,4")
              (const_string "noavx")
            (eq_attr "alternative" "2,5")
              (const_string "avx")
           ]
           (const_string "*")))


(define_insn "*vec_concatv2sf_sse"
  [(set (match_operand:V2SF 0 "register_operand"     "=x,x,*y,*y")
        (vec_concat:V2SF
          (match_operand:SF 1 "nonimmediate_operand" " 0,m, 0, m")
          (match_operand:SF 2 "reg_or_0_operand"     " x,C,*y, C")))]
  "TARGET_SSE"
  "@
   unpcklps\t{%2, %0|%0, %2}
   movss\t{%1, %0|%0, %1}
   punpckldq\t{%2, %0|%0, %2}
   movd\t{%1, %0|%0, %1}"
  [(set_attr "type" "sselog,ssemov,mmxcvt,mmxmov")
   (set_attr "mode" "V4SF,SF,DI,DI")])

The movd alternatives only require MMX.

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
After some more digging, it appears that the problem is
move_insn_for_shrink_wrap() is deleting and re-creating insns to move them from
one BB to another. The label reference count gets decremented in delete_insn()
but does not get re-incremented when the new insn is created in a different BB.

If you add -fno-shrink-wrap, the ICE does not occur.

[Bug c++/87322] [8 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] GCC fails  |[8 Regression] GCC fails to
   |to parse captured lambda of |parse captured lambda of
   |2nd inner lambda if the |2nd inner lambda if the
   |captured lambda has "," |captured lambda has ","
   |(having 2 arguments)|(having 2 arguments)
  Known to fail|9.0 |

--- Comment #8 from Alexandre Oliva  ---
Fixed for GCC 9.

[Bug c/89342] New: ICE in maybe_default_option, at opts.c:347

[gs...@t-online.de]

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

Bug ID: 89342
   Summary: ICE in maybe_default_option, at opts.c:347
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affected by options -O[gs012] down to at least gcc-5,
compiles of course with -O3 or -Ofast (not sure if legal)  :



$ cat z1.c
__attribute__((optimize("Ofast")))
void foo ()
{
  __attribute__((optimize("align-functions=16")))
  void bar () {}
}


$ gcc-9-20190210 -c z1.c -O3
$
$ gcc-9-20190210 -c z1.c
z1.c: In function 'foo':
z1.c:5:3: internal compiler error: in maybe_default_option, at opts.c:347
5 |   void bar () {}
  |   ^~~~
0x127e18f maybe_default_option
../../gcc/opts.c:347
0x127fcfb maybe_default_options
../../gcc/opts.c:433
0x127fcfb default_options_optimization(gcc_options*, gcc_options*,
cl_decoded_option*, unsigned int, unsigned int, unsigned int,
cl_option_handlers const*, diagnostic_context*)
../../gcc/opts.c:652
0x9c0cf9 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
../../gcc/opts-global.c:308
0x668256 parse_optimize_options(tree_node*, bool)
../../gcc/c-family/c-common.c:5731
0x68fd87 handle_optimize_attribute
../../gcc/c-family/c-attribs.c:3893
0x5d5e57 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:719
0x5ed501 start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:8907
0x6300d8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2258
0x62f46a c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5070
0x62f556 c_parser_compound_statement
../../gcc/c/c-parser.c:4982
0x630cca c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2354
0x635d73 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x636839 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x636839 c_parse_file()
../../gcc/c/c-parser.c:19842
0x67cca0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[sean.wang at wdc dot com]

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

--- Comment #4 from sean.wang at wdc dot com ---
The assert it reached was this I think:
 gcc_assert(field == NULL_TREE);

Thanks, Ian. It is helpful. I think I found a way to reproduce this issue on a
smaller set of code. Will provide an example once I have everything stubbed
out.

[Bug inline-asm/89334] unsupported size for integer register

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #7 from Alexander Monakov  ---
Isolated testcase for diagnostic enhancement (-O2 -m32, want error on line 6
rather than line 12):

static inline
void f(void)
{
int si;
asm("" : "=S"(si));
asm("# %0" :: "r"((char)si));
}

void wrapper(void)
{
f();
}

[Bug c/89341] New: ICE in get, at cgraph.h:1332

[gs...@t-online.de]

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

Bug ID: 89341
   Summary: ICE in get, at cgraph.h:1332
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -O0 down to at least gcc-5 :


$ cat z1.c
__attribute__((weakref("bar")))
static void foo () { }
void foo ();


$ gcc-9-20190210 -c z1.c -O1
$
$ gcc-9-20190210 -c z1.c -O0
z1.c:2:13: internal compiler error: Segmentation fault
2 | static void foo () { }
  | ^~~
0xa8aa9f crash_signal
../../gcc/toplev.c:326
0x70c90a cgraph_node* dyn_cast(symtab_node*)
../../gcc/is-a.h:227
0x70c90a cgraph_node::get(tree_node const*)
../../gcc/cgraph.h:1333
0x70c90a cgraph_node::analyze()
../../gcc/cgraphunit.c:640
0x70f457 analyze_functions
../../gcc/cgraphunit.c:1126
0x70fd92 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2834

[Bug c/89340] New: ICE in function_and_variable_visibility, at ipa-visibility.c:707

[gs...@t-online.de]

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

Bug ID: 89340
   Summary: ICE in function_and_variable_visibility, at
ipa-visibility.c:707
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-5 :


$ cat z1.c
void foo ()
{
  __attribute__((weak))
  void bar () { }
  bar();
}


$ gcc-9-20190210 -c z1.c
during IPA pass: visibility
z1.c:6:1: internal compiler error: in function_and_variable_visibility, at
ipa-visibility.c:707
6 | }
  | ^
0x1200e11 function_and_variable_visibility
../../gcc/ipa-visibility.c:703

[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
It looks more like the kind of thing that combine make_extraction,
make_compound_operation, expand_compound_operation comes up with.
This is not a new problem.

[Bug c/89312] snprintf warning is unparsable and not confusing

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
In the future, the warnings for problems unrelated to truncation should be
moved under their own options (e.g., null pointer arguments to %s should be
controlled by either -Wnonnull or -Wnull-dereference).

Your solution/workaround will work but GCC will only eliminate the test when it
can prove the condition cannot be true.  For example, below the test and the
assignment are eliminated because given the sizes of the two input arrays the
snprintf result cannot be greater than 40 (compile with
-fdump-tree-optimized=/dev/stdout to see the result):

  char a[20], b[20];
  char d[40];

  void f (void)
  {
int r = snprintf (d, sizeof d, "%s %s", a, b);
if (r >= sizeof d)
  d[sizeof d - 1] = 0;
  }

But if you change a to have, say, 30 elements (or make it a pointer) the test
is not eliminated anymore because GCC can no longer prove that it won't cause
truncation (the possible truncation can then be detected by using
-Wformat-truncation=2).

The same effect can be achieved without the overhead by introducing a volatile
temporary variable for the destination size, but it's also ugly.  Another
option is to introduce a wrapper function or macro for deliberately truncating
snprintf calls and have it hide the ugliness:

  #define snprintf_trunc(dst, size, ...) \
do { \
  volatile size_t n = size;  \
  snprintf (dst, n, __VA_ARGS__);\
} while (0)

I agree that clunky workarounds shouldn't be necessary.  Ideally, there would
be an elegant or at least intuitive way to indicate the truncation is expected
without jumping through these hoops.  A few people have suggested a cast to
void as that annotation.  We had considered it but didn't implement it because
legacy code routinely uses casts to void as a (superfluous) convention to
indicate that the result of a function call is deliberately unused, but not
necessarily with an appreciation of the consequences of what it might mean for
snprintf.  Perhaps we should revisit that decision.

[Bug target/89339] New: sse-movmskb-1.c fails for PPC Big Endian

[dje at gcc dot gnu.org]

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

Bug ID: 89339
   Summary: sse-movmskb-1.c fails for PPC Big Endian
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: pc at us dot ibm.com
  Target Milestone: ---

sse-movmskb-1.c fails at runtime on AIX and powerpc64-linux big endian.

[Bug target/89338] New: sse-cvtss2si-[12].c fails on PPC Big Endian

[dje at gcc dot gnu.org]

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

Bug ID: 89338
   Summary: sse-cvtss2si-[12].c fails on PPC Big Endian
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: pc at us dot ibm.com
  Target Milestone: ---

sse-cvtss2si-[12].c fails at runtime on AIX and powerpc64-linux big endian.

[Bug inline-asm/89334] unsupported size for integer register

[stsp at users dot sourceforge.net]

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

Stas Sergeev  changed:

   What|Removed |Added

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

--- Comment #6 from Stas Sergeev  ---
Thanks Andrew!
Please, make gcc better, not worse.
Prev versions generated "%sil", which,
while silly, was at least traceable.
And now the things are completely cryptic.

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #45685|0   |1
is obsolete||

--- Comment #20 from H.J. Lu  ---
Created attachment 45705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45705=edit
An updated patch

[Bug c++/87322] [8/9 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Feb 13 17:42:39 2019
New Revision: 268850

URL: https://gcc.gnu.org/viewcvs?rev=268850=gcc=rev
Log:
[PR87322] move cp_evaluated up to tsubst all lambda parms

A lambda capture variable initialized with a lambda expr taking more
than one parameter got us confused.

The first problem was that the parameter list was cut short during
tsubsting because we tsubsted it with cp_unevaluated_operand.  We
reset it right after, to tsubst the function body, so I've moved the
reset up so that it's in effect while processing the parameters as
well.

The second problem was that the lambda expr appeared twice, once in a
decltype that gave the capture variable its type, and once in its
initializer.  This caused us to instantiate two separate lambda exprs
and closure types, and then to flag that the lambda expr in the
initializer could not be converted to the unrelated closure type
determined for the capture variable.  Recording the tsubsted expr in
the local specialization map, and retrieving it for reuse fixed it.
However, that required some care to avoid reusing the lambda expr
across different indices in pack expansions.


for  gcc/cp/ChangeLog

PR c++/87322
* pt.c (tsubst_lambda_expr): Avoid duplicate tsubsting.
Move cp_evaluated resetting before signature tsubsting.
(gen_elem_of_pack_expansion_instantiation): Separate local
specializations per index.

for  gcc/testsuite/ChangeLog

PR c++/87322
* g++.dg/cpp1y/pr87322.C: New.
* g++.dg/cpp0x/lambda/lambda-variadic5.C: Test that we
instantiate the expected number of lambda functions.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr87322.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic5.C

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Yes, please look at my previous comment.  I believe the problem is in the
VEC_EXTRACT processing in rs6000-c.c until proven otherwise... can you please
try my debugging suggestion?

[Bug inline-asm/89334] unsupported size for integer register

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Stas Sergeev from comment #4)
> Would it be possible to at least show the
> correct line number where the register allocation
> actually failed? gcc points to a rather "random"
> line

Hmm, getting a "correct" location is doable.
Something like:
diff --git a/gcc/final.c b/gcc/final.c
index f6edd6a1dfc..ab85f7dce91 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -2690,6 +2690,7 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p ATTRIBUTE_UNUSED,
rtx *ops = XALLOCAVEC (rtx, noperands);
const char *string;
location_t loc;
+   location_t saved_loc;
expanded_location expanded;

/* There's no telling what that did to the condition codes.  */
@@ -2702,6 +2703,10 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p ATTRIBUTE_UNUSED,
this_is_asm_operands = insn;
expanded = expand_location (loc);

+   saved_loc = input_location;
+   input_location = loc;
+
+
 #ifdef FINAL_PRESCAN_INSN
FINAL_PRESCAN_INSN (insn, ops, insn_noperands);
 #endif
@@ -2725,6 +2730,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p ATTRIBUTE_UNUSED,
   insn_noperands);

this_is_asm_operands = 0;
+
+   input_location = saved_loc;
break;
  }


Untested (both building and running).

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

--- Comment #1 from Rafael Avila de Espindola  ---
The original testcase is from https://github.com/scylladb/seastar/issues/598

[Bug middle-end/89337] New: Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

Bug ID: 89337
   Summary: Bogus "exceeds maximum object size" on unreachable
code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

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

In the attached testcase the function drop3 has the precondition that the
provided string has a size of at least 3.

Given that, the body of the resize function is dead, but gcc doesn't realize it
and warns that we are passing -3 to memcpy.

[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #7)
> truncate:SI of ashift:DI looks wrong already; I'd expect ashift:SI of a
> subreg?

But then it would be a simplify-rtx.c issue.  Though, not sure if it isn't too
late to change simplify-rtx.c to simplify that differently now.

[Bug rtl-optimization/89275] [9 Regression] Slowdown in mcperf on POWER

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 Ever confirmed|0   |1

--- Comment #4 from Bill Schmidt  ---
Either way, confirmed that we have an issue here.  But I don't yet have
information to support this as a 9 regression.

[Bug rtl-optimization/89275] [9 Regression] Slowdown in mcperf on POWER

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
I just heard back from the performance lead.  He indicates that they can
reproduce the numbers from 9.0 trunk (compiled Feb 8, versus Feb 3 as reported
by Phoronix), but the numbers from 8.2 as tagged do not reproduce.  GCC 9
degrades a little on Add, but is in the noise range for Set/Append.

If we accept this (and I see no reason not to at the moment), we still have the
question of why GCC lags LLVM on this benchmark for *both* 8 and 9.  So we will
continue to work on root-cause analysis.

[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
truncate:SI of ashift:DI looks wrong already; I'd expect ashift:SI of a subreg?

[Bug rtl-optimization/89295] [9 regression] compilation of gcc.dg-struct-layout-1/t001_x.c takes 30 times as long after r268404

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I just tried it and r268597 does fix it.

[Bug c++/89336] internal compiler error when compiling a constexpr function

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The ICE actually isn't when processing the loop, but later on when processing
the
VIEW_CONVERT_EXPR({.a={0, 1, 2, 3, 4, 5, [8]=1, 2, 3, 4, 5, }});
expression.
When using
{
  r[i] = i;
  r[i + 8] = i;
}
as the loop body, I instead get:
{.a={0, 1, 2, 3, 4, 5, [8]=0, 1, 2, 3, 4, 5}}

In the bogus one, [8] doesn't have the value 0 but 1 and all the values are
shifted by 1, with [13] having NULL value, just non-NULL purpose.

[Bug c++/89336] internal compiler error when compiling a constexpr function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:
template  struct A {
  T a[N];
  constexpr T [] (int x) { return a[x]; }
};

constexpr A
foo ()
{
  A r{};
  for (int i = 0; i < 6; ++i)
r[i + 8] = r[i] = i;
  return r;
}

auto x = foo ();

Started to ICE with r217670, before that it has been accepted for a couple of
revisions and before that rejected.

[Bug rtl-optimization/89275] [9 Regression] Slowdown in mcperf on POWER

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
I asked our performance team to root-cause this when the report came out.  If
they can reproduce we can try to bisect it.

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00919.html

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Done.

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Feb 13 16:35:44 2019
New Revision: 268849

URL: https://gcc.gnu.org/viewcvs?rev=268849=gcc=rev
Log:
PR c++/77304
* g++.dg/cpp2a/nontype-class13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class13.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
sse.md has

(define_insn "mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"
 "=v,v ,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
 " C,BC,vm,v"))]

  /* There is no evex-encoded vmov* for sizes smaller than 64-bytes
 in avx512f, so we need to use workarounds, to access sse registers
 16-31, which are evex-only. In avx512vl we don't need workarounds.  */
  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))
{
  if (memory_operand (operands[0], mode))
{
  if ( == 32)
return "vextract64x4\t{$0x0, %g1, %0|%0, %g1,
0x0}";
  else if ( == 16)
return "vextract32x4\t{$0x0, %g1, %0|%0, %g1,
0x0}";
  else
gcc_unreachable ();
}
...

However, ix86_hard_regno_mode_ok has

 /* TODO check for QI/HI scalars.  */
  /* AVX512VL allows sse regs16+ for 128/256 bit modes.  */
  if (TARGET_AVX512VL
  && (mode == OImode
  || mode == TImode
  || VALID_AVX256_REG_MODE (mode)
  || VALID_AVX512VL_128_REG_MODE (mode)))
return true;

  /* xmm16-xmm31 are only available for AVX-512.  */
  if (EXT_REX_SSE_REGNO_P (regno))
return false;

  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))

is a dead code:

[hjl@gnu-4 gcc]$ cat /tmp/z.c 
#include 

extern __m128 i;

__m128
foo1 (void)
{
  register __m128 xmm16 __asm ("xmm16") = i;
  asm volatile ("" : "+v" (xmm16));
  register __m128 xmm17 __asm ("xmm17") = xmm16;
  asm volatile ("" : "+v" (xmm17));
  return xmm17;
}
[hjl@gnu-4 gcc]$ /usr/gcc-5.4.1-x32/bin/gcc  -S -O2 -march=knl /tmp/z.c 
/tmp/z.c: In function ‘foo1’:
/tmp/z.c:8:19: error: register specified for ‘xmm16’ isn’t suitable for data
type
   register __m128 xmm16 __asm ("xmm16") = i;
   ^
/tmp/z.c:10:19: error: register specified for ‘xmm17’ isn’t suitable for data
type
   register __m128 xmm17 __asm ("xmm17") = xmm16;
   ^
[hjl@gnu-4 gcc]$

[Bug inline-asm/89334] unsupported size for integer register

[stsp at users dot sourceforge.net]

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

--- Comment #4 from Stas Sergeev  ---
Would it be possible to at least show the
correct line number where the register allocation
actually failed? gcc points to a rather "random"
line, and it required many hours of an engineer
work to find the problematic spot in a large project.
It really is not the good handling of this problem.

And I don't understand why it is impossible to add
error or warning if gcc emits 8bit reference for "r"
and knows it is not supposed to work.

[Bug target/89190] [8/9 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #2 from Wilco  ---
Author: wilco
Date: Wed Feb 13 16:22:25 2019
New Revision: 268848

URL: https://gcc.gnu.org/viewcvs?rev=268848=gcc=rev
Log:
[ARM] Fix Thumb-1 ldm (PR89190)

This patch fixes an ICE in the Thumb-1 LDM peepholer.  Thumb-1 LDMs
always update the base register except if the base is loaded.
The current implementation rejects LDMs where the base is not dead,
however this doesn't exclude the case where the base is loaded as
well as dead.  Fix this by explicitly checking whether the base is
loaded.  Also enable LDMs which load the first register.

gcc/
PR target/89190
* config/arm/arm.c (ldm_stm_operation_p) Set
addr_reg_in_reglist correctly for first register.
(load_multiple_sequence): Remove dead base check.
(gen_ldm_seq): Correctly set write_back for Thumb-1.

testsuite/
PR target/89190
* gcc.target/arm/pr89190.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> r265896 might have affected this

Update: apparently not; I still had to deactivate libunwind-headers again on my
latest build of gcc

[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

--- Comment #12 from kelvin at gcc dot gnu.org ---
After further digging, I have uncovered some additional clues:

after initial gimple expansion (i.e. the 005t.gimple trace file):

  vec_extract (vi, 3) is represented by __builtin_vec_ext_v4si (vi, 3)

But vec_extract (vi, 10) is represented by __BIT_FIELD_REF 

Apparently, the difference in handling of these two cases is that the selector
argument of the latter is known to be a constant greater than the number of
elements in the vector.

However, when the same code is expanded after in-lining the doextractbybuiltin
function of comment #4, the two expressions expand into

  __builtin_vec_ext_v4si (vi, 3) and
  __builtin_vec_ext_v4si (vi, 10) respectively.

This behavior is first manifest in the .047t.local-fnsummary2 trace file.

Later, when we "process" __builtin_vec_ext_v4si with a constant selector whose
value exceeds the vector length, we issue the erroneous error message.  With
non-constant selector values for __builtin_vec_ext_v4si, we do not issue the
error message.

I think the place to fix this is in the processing of the
__builtin_vec_ext_v4si function (and all of its lookalikes).  Rather than issue
the error message, we may have to emit slightly different implementations of
the code or maybe not even that.  Maybe i can just remove the error message.  I
need to study this a little more.

At the same time, I'm wondering if the "real problem" is in the
local-fnsummary2 pass.  During in-lining, it could be argued that it should
have produced the same intermediate form as the original gimple expansion:
BIT_FIELD_REF instead of __builtin_vec_ext_v4si.

Does anyone have further suggestions before I begin implementing a "solution"?

Thanks.

[Bug c++/89336] internal compiler error when compiling a constexpr function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
r[i + 'a'] = i + 10;
r[i + 'A'] = i + 10;
or
r[i + 'a'] = i + 10;
r[i + 'A'] = r[i + 'a'];
doesn't ICE.

[Bug c++/89336] internal compiler error when compiling a constexpr function

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The current ICE started with r267253:

89336.C: In function ‘int main()’:
89336.C:16:20: internal compiler error: Segmentation fault
0x13ae0c0 crash_signal
../../gcc/toplev.c:326
0x89a0e1 initialized_type
../../gcc/cp/constexpr.c:2830
0x89a2eb init_subob_ctx
../../gcc/cp/constexpr.c:2864
0x89a8dc cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:2951
0x8a205e cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4692
0x89a94d cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:2956
0x8a205e cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4692
0x8a38ea cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5077
0x8a454c maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:5309
0x8c2776 cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:2161
0xb73a19 split_nonconstant_init(tree_node*, tree_node*)
../../gcc/cp/typeck2.c:753
0xb7421d store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:876
0x9041c4 check_initializer
../../gcc/cp/decl.c:6491
0x90766d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7167
0xa0faa8 cp_parser_init_declarator
../../gcc/cp/parser.c:20327
0xa02a14 cp_parser_simple_declaration
../../gcc/cp/parser.c:13414
0xa025a5 cp_parser_block_declaration
../../gcc/cp/parser.c:13239
0xa01a00 cp_parser_declaration_statement
../../gcc/cp/parser.c:12844
0x9fdb1a cp_parser_statement
../../gcc/cp/parser.c:11169
0x9fe815 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

but before that it ICEd also:

89336.C: In function ‘int main()’:
89336.C:16:20: internal compiler error: Segmentation fault
0x13ae0a2 crash_signal
../../gcc/toplev.c:326
0xb7348a split_nonconstant_init_1
../../gcc/cp/typeck2.c:641
0xb7350c split_nonconstant_init_1
../../gcc/cp/typeck2.c:652
0xb73a1b split_nonconstant_init(tree_node*, tree_node*)
../../gcc/cp/typeck2.c:755
0xb741ff store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:876
0x9041a6 check_initializer
../../gcc/cp/decl.c:6491
0x90764f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7167
0xa0fa8a cp_parser_init_declarator
../../gcc/cp/parser.c:20327
0xa029f6 cp_parser_simple_declaration
../../gcc/cp/parser.c:13414
0xa02587 cp_parser_block_declaration
../../gcc/cp/parser.c:13239
0xa019e2 cp_parser_declaration_statement
../../gcc/cp/parser.c:12844
0x9fdafc cp_parser_statement
../../gcc/cp/parser.c:11169
0x9fe7f7 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11531
0x9fe6ed cp_parser_compound_statement
../../gcc/cp/parser.c:11485
0xa13879 cp_parser_function_body
../../gcc/cp/parser.c:22405
0xa13a3d cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22442
0xa1d7ec cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:27495
0xa1d619 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:27411
0xa0f2a1 cp_parser_init_declarator
../../gcc/cp/parser.c:20097
0xa029f6 cp_parser_simple_declaration
../../gcc/cp/parser.c:13414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ada/89333] [9 Regression] FAIL: gnat.dg/vect*.adb on darwin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
> I was supposed to post: Between revisions r268704 and r268809.

You're also more or less supposed to check whether this hasn't been reported
already.  This has been reported already, and twice.

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

[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #5 from Eric Botcazou  ---
*** Bug 89333 has been marked as a duplicate of this bug. ***

[Bug c++/89336] internal compiler error when compiling a constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug inline-asm/89334] unsupported size for integer register

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
If you are using inline asm, you need to know what you are doing.
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Simple-Constraints.html#Simple-Constraints
‘r’
A register operand is allowed provided that it is in a general register. 
while q is:
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Machine-Constraints.html#Machine-Constraints
‘q’
Any register accessible as rl. In 32-bit mode, a, b, c, and d; in 64-bit
mode, any integer register.
By using r constraint, you tell the compiler it is ok to allocate that value in
any gpr register, so for 32-bit mode eax, ebx, ecx, edx, esi, edi, ebp (or, in
theory esp, though that is fixed register).
That would be ok if the assembly pattern used e.g. %k1 instead of %1.  But as
you want to use the %?l in there, you need to tell the compiler that it may
only use the selected registers, otherwise it is a lottery.  It can compile
fine, if you are lucky and the compiler chooses the eax/ebx/ecx/edx registers,
or it can fail the way it failed for you.

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Eric Gallager from comment #5)
> > actually since all the bugs seem to be about different targets triggering
> > that assert in different ways, would it be possible to replace it with an
> > internal_error() that provides a bit more information as to how exactly the
> > compiler got there?
> 
> That is why there is a backtrace.  The assert is just asserting we can't
> create any new psedu registers as the register allocator has happened
> already.  Basically the backend can't directly use
> copy_to_mode_reg/gen_reg_rtx after register allocation.  How do you print
> where you can from when it is two layers deep?  Also this is why there is a
> backtrace printed out to help out.

Unfortunately there's no backtrace on Darwin (where I test) due to bug 88745 
(unless you manually attach a debugger)

[Bug inline-asm/89334] unsupported size for integer register

[stsp at users dot sourceforge.net]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #1)
> the same for -m64, but only al/bl/cl/dl for -m32, because there is no
> sil/dil/bpl for -m32.

But why does this matter?
I am perfectly fine with al/bl/cl/dl, never asked
to use sil/dil/bpl. What is the rationale? If "r"
is plain invalid for 8bit values, then shouldn't
the error be different and not to depend on an opt
level? Could you please explain a bit more what
exactly the error is and why it works with -O1?
Why invalid registers (sil/dil/bpl) even matter
at all?

[Bug c++/89036] [8 Regression] ICE if destructor has a requires

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE if |[8 Regression] ICE if
   |destructor has a requires   |destructor has a requires

--- Comment #6 from David Malcolm  ---
Fixed on trunk by r268847.

[Bug c++/89336] New: internal compiler error when compiling a constexpr function

[marek at telnyx dot com]

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

Bug ID: 89336
   Summary: internal compiler error when compiling a constexpr
function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marek at telnyx dot com
  Target Milestone: ---

g++ version: 8.2.0

Trying to compile the following source causes internal compiler error:
---
#include 

constexpr std::array prepare()
{
  std::array r = {0};
  for ( int i = 0; i < 6; ++i )
  {
r[i + 'a'] = r[i + 'A'] = i + 10;
  }
  return r;
}


int main()
{
  auto v = prepare();
  return 0;
}
---

g++ -std=c++17 xx.cpp 
xx.cpp: In function ‘int main()’:
xx.cpp:16:20: internal compiler error: Segmentation fault
   auto v = prepare();