[Bug other/102550] libssp cannot find size_t. they do not include stddef.h

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Andrew Pinski from comment #2)
> How did you configure and invoke make?
> Was newlib installed already or you building a combined tree?

of course it is installed. no it is completely separate. Even libstdc++ was
successfully built.

if I remembered correctly I saw that issue months ago with picolibc too.

[Bug other/102550] libssp cannot find size_t. they do not include stddef.h

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Created attachment 51527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51527=edit
config file

[Bug other/102550] libssp cannot find size_t. they do not include stddef.h

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-10-01
 Ever confirmed|0   |1
   Keywords||build

--- Comment #2 from Andrew Pinski  ---
How did you configure and invoke make?
Was newlib installed already or you building a combined tree?

[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'

[miko at predsci dot com via Gcc-bugs]

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

miko at predsci dot com changed:

   What|Removed |Added

 CC||miko at predsci dot com

--- Comment #2 from miko at predsci dot com ---
GCN debug: HSA run-time initialized for GCN
GCN debug: HSA_SYSTEM_INFO_ENDIANNESS: LITTLE
GCN debug: HSA_SYSTEM_INFO_EXTENSIONS: IMAGES
GCN debug: There are 1 GCN GPU devices.
GCN debug: HSA_AGENT_INFO_NAME: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
GCN debug: HSA_AGENT_INFO_VENDOR_NAME: CPU
GCN debug: HSA_AGENT_INFO_MACHINE_MODEL: LARGE
GCN debug: HSA_AGENT_INFO_PROFILE: FULL
GCN debug: HSA_AGENT_INFO_DEVICE: CPU
GCN debug: HSA_AMD_AGENT_INFO_COMPUTE_UNIT_COUNT: 24
GCN debug: HSA_AGENT_INFO_WAVEFRONT_SIZE: 0
GCN debug: HSA_AGENT_INFO_WORKGROUP_MAX_DIM: 0
GCN debug: HSA_AGENT_INFO_WORKGROUP_MAX_SIZE: 0
GCN debug: HSA_AGENT_INFO_GRID_MAX_DIM: 0
GCN debug: HSA_AGENT_INFO_GRID_MAX_SIZE: 0
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33595305984
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: KERNARG
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33595305984
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33816289280
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: KERNARG
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33816289280
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: COARSE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33595305984
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: COARSE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33816289280
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_AGENT_INFO_NAME: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
GCN debug: HSA_AGENT_INFO_VENDOR_NAME: CPU
GCN debug: HSA_AGENT_INFO_MACHINE_MODEL: LARGE
GCN debug: HSA_AGENT_INFO_PROFILE: FULL
GCN debug: HSA_AGENT_INFO_DEVICE: CPU
GCN debug: HSA_AMD_AGENT_INFO_COMPUTE_UNIT_COUNT: 24
GCN debug: HSA_AGENT_INFO_WAVEFRONT_SIZE: 0
GCN debug: HSA_AGENT_INFO_WORKGROUP_MAX_DIM: 0
GCN debug: HSA_AGENT_INFO_WORKGROUP_MAX_SIZE: 0
GCN debug: HSA_AGENT_INFO_GRID_MAX_DIM: 0
GCN debug: HSA_AGENT_INFO_GRID_MAX_SIZE: 0
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33595305984
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: KERNARG
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33595305984
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: HSA_REGION_INFO_SEGMENT: GLOBAL
GCN debug: HSA_REGION_INFO_GLOBAL_FLAGS: FINE_GRAINED
GCN debug: HSA_REGION_INFO_SIZE: 33816289280
GCN debug: HSA_REGION_INFO_ALLOC_MAX_SIZE: 134823190528
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALLOWED: 1
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_GRANULE: 4096
GCN debug: HSA_REGION_INFO_RUNTIME_ALLOC_ALIGNMENT: 4096
GCN debug: 

[Bug other/102550] libssp cannot find size_t. they do not include stddef.h

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
libc is newlib-cygwin

[Bug other/102550] New: libssp cannot find size_t. they do not include stddef.h

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 102550
   Summary: libssp cannot find size_t. they do not include
stddef.h
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51526=edit
error log

stddef.h is missing. do not know what's wrong with the build script of libssp

[Bug tree-optimization/102539] [11/12 regression] -Wmaybe-uninitialized false positive, invalid location

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

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

--- Comment #4 from Sergei Trofimovich  ---
Ah, that's very clever! Thank you!

[Bug tree-optimization/71520] Missing cross-jumping of switch cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug c/35501] Wrong value returned from const int

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |c

--- Comment #6 from Andrew Pinski  ---
The front-end is doing this, not anything to do with the tree optimizers.

[Bug tree-optimization/52611] ia64-hp-hpux11.31, internal compiler error: verify_gimple failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 4.7.0 by r0-114570 (which removes the special case for void*).

[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|Missed Dead Code|[12 Regregression] Missed
   |Elimination regression  |Dead Code Elimination
   |(trunk vs 11.2.0) at -O3|regression (trunk vs
   ||11.2.0) at -O3
   Keywords||missed-optimization

[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|gcc segmentation fault in   |[9/10/11/12 Regression] ICE
   |cc1plus (with repro case)   |with cdecl attribute on a
   ||builtin function
   Target Milestone|--- |9.5

--- Comment #4 from Andrew Pinski  ---
sometime between GCC 6 and GCC 7, the ICE was introduced before this was
rejected:
: In function 'void f()':
:12:35: error: invalid conversion from 'size_t
(__attribute__((__cdecl__)) *)(char*, size_t, const char*, const tm*) {aka
unsigned int (__attribute__((__cdecl__)) *)(char*, unsigned int, const char*,
const tm*)}' to 'T {aka unsigned int (__attribute__((__stdcall__)) *)(char*,
unsigned int, const char*, const tm*)}' [-fpermissive]
   static T strftime = loadStrftime();
   ^~


Note using auto instead of the type T, the ICE shows up still:

typedef decltype(sizeof(0)) size_t;
struct tm;
extern "C"
size_t __attribute__((__cdecl__)) strftime(char *  _Buf,size_t
_SizeInBytes,const char *  _Format,const struct tm *  _Tm);
void f(void)
{
  auto g = strftime;
}

And was accepted in GCC 6.
So this is a regression from GCC6.

Looks like it has to do with builtin functions too.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 102539 Summary: [11/12 regression] -Wmaybe-uninitialized false positive, 
invalid  location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102539

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/102539] [11/12 regression] -Wmaybe-uninitialized false positive, invalid location

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #3 from Martin Sebor  ---
-Wmaybe-uninitialized was enhanced to warn when a pointer to uninitialized
memory is passed to a function taking a const-qualified pointer:

  ... In addition, passing a pointer (or in C++, a reference) to an
uninitialized object to a const-qualified function argument is also diagnosed
by this warning.

That's also what seems to happen in the test case.  I get slightly different
output but the essence of the warning seems the same:

$ gcc -O2 -S -Wall -fdump-tree-uninit -fno-strict-aliasing pr102539.c
fabric/clustering.c: In function ‘msg_succession_list_field_set.constprop’:
fabric/clustering.c:3750:2: warning: ‘’ may be used uninitialized
[-Wmaybe-uninitialized]
In file included from fabric/clustering.c:36:
/home/slyfox/dev/git/nixpkgs/source/cf/include/msg.h:195:6: note: by argument 3
of type ‘const uint8_t *’ {aka ‘const unsigned char *’} to ‘msg_set_buf’
declared here
tmp$ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -S -Wall
-fdump-tree-uninit -fno-strict-aliasing -std=gnu99 pr102539.c
fabric/clustering.c: In function ‘msg_succession_list_field_set.constprop’:
fabric/clustering.c:3750:2: warning: ‘’ may be used uninitialized
[-Wmaybe-uninitialized]
In file included from fabric/clustering.c:36:
/home/slyfox/dev/git/nixpkgs/source/cf/include/msg.h:195:6: note: by argument 3
of type ‘const uint8_t *’ {aka ‘const unsigned char *’} to ‘msg_set_buf’
declared here


The  is a known cosmetic flaw with some middle end warnings.  It
should be fixed but we don't need to keep track of it here.

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

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

[Bug tree-optimization/101580] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

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

[Bug tree-optimization/102387] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Andrew Pinski  ---
Dup of bug 102385.

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

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/102387] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||suochenyao at 163 dot com

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

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/102387] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

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

[Bug tree-optimization/101897] [12 Regression] ICE: crash since r12-2429-g62acc72a957b5614

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Aldy Hernandez from comment #2) 
> I think this is a problem elsewhere.

Right which is why I said this is most likely the same issue as reported on the
earlier bug 102385 (and its many dups).

[Bug c++/102548] gcc segmentation fault in cc1plus (with repro case)

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

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

--- Comment #3 from Andrew Pinski  ---
reduced almost all the way:
typedef decltype(sizeof(0)) size_t;
struct tm;
extern "C"
size_t __attribute__((__cdecl__)) strftime(char * __restrict__ _Buf,size_t
_SizeInBytes,const char * __restrict__ _Format,const struct tm * __restrict__
_Tm);
void f(void)
{
  using T = size_t(__attribute__((__stdcall__))*)(char*, size_t, const char*,
const struct tm*);
  auto loadStrftime = [] {
return strftime;
  };
  static T strftime = loadStrftime();
}

[Bug c++/102548] gcc segmentation fault in cc1plus (with repro case)

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-30
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Marek Polacek  ---
Confirmed with

./cc1plus -quiet cmTimestamp.ii -march=x86-64 -mtune=generic  -fpermissive -m32

on x86_64-redhat-linux.

[Bug c++/102548] gcc segmentation fault in cc1plus (with repro case)

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

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

--- Comment #1 from Andrew Pinski  ---
apinski@xeond:~/src$ ~/upstream-gcc/bin/gcc cmTimestamp.ii  -m32 -S
E:/Programming/Source/msys2/MINGW-packages/mingw-w64-cmake/src/cmake-3.21.2/Source/cmTimestamp.cxx:
In lambda function:
E:/Programming/Source/msys2/MINGW-packages/mingw-w64-cmake/src/cmake-3.21.2/Source/cmTimestamp.cxx:208:12:
internal compiler error: tree check: expected tree_list, have error_mark in
apply_identity_attributes, at cp/tree.c:1499
0x8e5b60 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.c:8689
0x7a8647 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.h:3427
0x7a8647 apply_identity_attributes
/home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.c:1499
0x7a8647 strip_typedefs(tree_node*, bool*, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.c:1816
0xc0761d strip_typedefs(tree_node*, bool*, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.c:1548
0xc0761d strip_typedefs(tree_node*, bool*, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.c:1583
0xb70012 canonicalize_type_argument(tree_node*, int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:8176
0xb70012 canonicalize_type_argument(tree_node*, int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:8171
0xb9ee42 unify
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:23817
0xb9b288 unify_one_argument
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:22271
0xba877a type_unification_real
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:22390
0xb7f4e0 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:29805
0xc2454f check_return_expr(tree_node*, bool*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/typeck.c:10315
0xbd1eaf finish_return_stmt(tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/semantics.c:1193
0xb34bc5 cp_parser_jump_statement
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14162
0xb34bc5 cp_parser_statement
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:12172
0xb3583d cp_parser_statement_seq_opt
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:12713
0xb35918 cp_parser_compound_statement
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:12662
0xb36647 cp_parser_function_body
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:24893
0xb36647 cp_parser_lambda_body
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:11654
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

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

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
with the following change, I can resolve the ICE:

[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 70ce6a4d5b8d..b07026165075 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -2655,6 +2655,7 @@ fold_builtin_alloca_with_align (gimple *stmt)
 SET_DECL_PT_UID (var, uid);

   /* Fold alloca to the address of the array.  */
+  mark_addressable (var);
   return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var));
 }

diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c
index 0fba404babe9..e06609861bf1 100644
--- a/gcc/tree-ssa.c
+++ b/gcc/tree-ssa.c
@@ -1657,7 +1657,7 @@ maybe_optimize_var (tree var, bitmap addresses_taken,
bitmap not_reg_needs,
   bool maybe_reg = false;
   if (TREE_ADDRESSABLE (var))
 {
-  TREE_ADDRESSABLE (var) = 0;
+  //TREE_ADDRESSABLE (var) = 0;
   maybe_reg = true;
   if (dump_file)
{


However, I am not very sure the change in tree-ssa.c. why TREE_ADDRESSABLE
(var) is reverted in this routine?

[Bug c++/102535] __is_trivially_constructible rejects some trivial cases in aggregate initializations

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

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

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

https://gcc.gnu.org/g:9845c52db38f15740861435f38f7e5ad8a8de2ec

commit r12-3997-g9845c52db38f15740861435f38f7e5ad8a8de2ec
Author: Patrick Palka 
Date:   Thu Sep 30 17:34:23 2021 -0400

c++: __is_trivially_xible and multi-arg aggr paren init [PR102535]

is_xible_helper assumes only 0- and 1-argument ctors can be trivial, but
C++20 aggregate paren init means multi-arg ctors can now be trivial too.
This patch relaxes the relevant early exit check accordingly.

PR c++/102535

gcc/cp/ChangeLog:

* method.c (is_xible_helper): Don't exit early for multi-arg
ctors in C++20.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_trivially_constructible7.C: New test.

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

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

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

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

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

commit r12-3995-gb6bca2e631b54f992c058ca8e445b45e9816690b
Author: Patrick Palka 
Date:   Thu Sep 30 17:29:05 2021 -0400

c++: defaulted comparisons and vptr fields [PR95567]

We need to explicitly skip over vptr fields when synthesizing a
defaulted comparison operator, because next_initializable_field
doesn't do so for us.

PR c++/95567

gcc/cp/ChangeLog:

* method.c (build_comparison_op): Skip DECL_VIRTUAL_P fields.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-virtual1.C: New test.

[Bug debug/102534] RFE epilog is not reliably a statement with inlining

[woodard at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Ben Woodard  ---
There continues to be an instruction after the completion of the inlining, the
next instruction in the sequence, At the time when the inlining occurs why
can’t the .loc 1 6 1 be placed there as part of the process of folding the
instructions for the inlined code into the calling function. This is analogous
to the placement of loc 1 5 4 for the first first line inside the function in
every location where the the function is called. It just gets attached to the
next instruction after the function’s completion.

In other words we argue that .loc 1 6 1 should be attached to the instructions
at: 401081 401094 4010a4

Another case that we would like to see work even though it optimizes to no
machine instructions which we tried to include in this fragment of source is
the case where we call a function that gets completely optimized away to a call
for another function. Even when that happens, we would like the residue of its
former existence to be in the line map matrix. That is why we included both a
static and a potentially external function, were this to be compiled as PIE
then the unused function could still be called. We thought that the two
situations while highly related, were different.

Also you didn’t explain why the main() function at line 25 did not get a
breakpoint associated with the closing brace for it. It does have a ret
instruction and it is not inlined. If that needs to be a separate PR, I do not
mind splitting it off.

[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization

[bob.steagall.cpp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Bob Steagall  ---
I have applied this tentative change to line 23436 of gcc/cp/pt.c from the
gcc-11.2.0 source tarball, and can confirm that the test case compiles for me.

The code I was working on also compiles, links, and appears to run correctly.

I don't know if this is the final fix, but it is progress.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from David Binderman  ---
(In reply to qinzhao from comment #10)

> 2734 /* The heuristic of fold_builtin_alloca_with_align differs

git blame says:


13e49da934e9 (Tom de Vries   2011-10-07 12:49:49 + 2732) /*
The heuristic of fold_builtin_alloca_with_align differs before and
13e49da934e9 (Tom de Vries   2011-10-07 12:49:49 + 2733)  
after inlining, so we don't require the arg to be changed into a
13e49da934e9 (Tom de Vries   2011-10-07 12:49:49 + 2734)  
constant for folding, but just to be constant.  */
9e878cf1bae7 (Eric Botcazou  2017-10-19 15:58:05 + 2735) if
(gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
9e878cf1bae7 (Eric Botcazou  2017-10-19 15:58:05 + 2736)||
gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
1fed1006552c (Tom de Vries   2011-08-31 07:04:25 + 2737)  
{
13e49da934e9 (Tom de Vries   2011-10-07 12:49:49 + 2738)   
 tree new_rhs = fold_builtin_alloca_with_align (stmt);
5d882cc1dafe (Richard Guenther   2011-09-02 11:53:55 + 2739)   
 if (new_rhs)
5d882cc1dafe (Richard Guenther   2011-09-02 11:53:55 + 2740)  {
52a5515ed661 (Richard Biener 2021-04-14 13:40:58 +0200 2741)   
gimplify_and_update_call_from_tree (gsi, new_rhs);
2f31f742a693 (Tom de Vries   2011-12-17 11:39:43 + 2742)   
tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2f31f742a693 (Tom de Vries   2011-12-17 11:39:43 + 2743)   
insert_clobbers_for_var (*gsi, var);
5d882cc1dafe (Richard Guenther   2011-09-02 11:53:55 + 2744)   
return true;
5d882cc1dafe (Richard Guenther   2011-09-02 11:53:55 + 2745)  }
1fed1006552c (Tom de Vries   2011-08-31 07:04:25 + 2746)  
}

so at least Tom, Eric and Richard have been in there.

[Bug middle-end/102549] Incorrect optimization if argument is SNAN

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Yes you need to use -fsignaling-nans.

[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #2 from Iain Sandoe  ---
the preprocessed file compiles for me using current gcc-10, 11 and master -
could you provide a little more info? (does it still fail for your case?)

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

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

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
commented the following transformation in tree-ssa-ccp.c:

2733 #if 0
2734 /* The heuristic of fold_builtin_alloca_with_align differs before
and
2735after inlining, so we don't require the arg to be changed into
a
2736constant for folding, but just to be constant.  */
2737 if (gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
2738 || gimple_call_builtin_p (stmt,
BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
2739   {
2740 tree new_rhs = fold_builtin_alloca_with_align (stmt);
2741 if (new_rhs)
2742   {
2743 gimplify_and_update_call_from_tree (gsi, new_rhs);
2744 tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2745 insert_clobbers_for_var (*gsi, var);
2746 return true;
2747   }
2748   }
2749 #endif

cures the ICE.  "fb.3" is a new temp variable that is created inside
"fold_builtin_alloca_with_align".

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||victor.burckel at gmail dot com

--- Comment #12 from Iain Sandoe  ---
*** Bug 101144 has been marked as a duplicate of this bug. ***

[Bug c++/101144] Coroutine compiler error

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Iain Sandoe  ---
duplicate of 98056

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

[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
I think I have a potential fix -- replace the problematic call to
uses_template_parms with dependent_template_arg_p:

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23587,7 +23587,7 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
  even if ARG == PARM, since we won't record unifications for the
  template parameters.  We might need them if we're trying to
  figure out which of two things is more specialized.  */
-  if (arg == parm && !uses_template_parms (parm))
+  if (arg == parm && !dependent_template_arg_p (parm))
 return unify_success (explain_p);

   /* Handle init lists early, so the rest of the function can assume

So mine I suppose.

[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-30
 CC||iains at gcc dot gnu.org

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> So instead of doing *((T[0:] *)[ubound])[-idx] for accesses do
> a[ubound - idx]?

I think this assumption is correct.

Of course 'a' could have a non-trivial stride (i.e. being /= 1), which is
provided by the array descriptor.  That should hopefully been respected by
the suggested change.

[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work||10.3.0
 CC||mpolacek at gcc dot gnu.org
Summary|g++ 11. ICE with NTTPs and  |[11/12 Regression] g++ 11.
   |partial specialization  |ICE with NTTPs and partial
   ||specialization
   Keywords||rejects-valid
  Known to fail||11.2.0, 12.0
   Target Milestone|--- |11.3

--- Comment #2 from Patrick Palka  ---
Started with r11-4671.

[Bug c++/102547] g++ 11. ICE with NTTPs and partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/93320] internal compiler error: in is_base_type, at dwarf2out.c:12987

[ldalessandro at gmail dot com via Gcc-bugs]

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

Luke Dalessandro  changed:

   What|Removed |Added

 CC||ldalessandro at gmail dot com

--- Comment #8 from Luke Dalessandro  ---
I'm still seeing failures on this line in 12/trunk with the following invalid
code with std=c++17, **but not with -std=c++20**. Don't think architecture is
important.

```
struct A {
A(decltype(auto)... xs) {}
};
```

https://godbolt.org/z/neKc1M6sd

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
the direct cause of the ICE is because:

MEM[(int[0:D.1993] *)] = .DEFERRED_INIT (16, 2, 1);

in the above, the fb.3 is in REG instead MEM:

8451  gcc_assert (MEM_P (result));
(gdb) call debug_tree(exp)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9463348 precision:8 min  max >
TI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9463498
domain 
DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe94633f0 precision:64 min  max >
pointer_to_this >
used ignored TI pr82421.c:10:7 size 
unit-size 
align:128 warn_if_not_align:0 context 
(reg:TI 84 [ fb.3 ])>

fb.3 is introduced by CCP transformation, disabling tree-ccp cures the failure
by adding -fno-tree-ccp.

I suspect that ccp might have a bug that does not mark TREE_ADDRESSABLE
correctly for fb.3.

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.5
 Status|NEW |RESOLVED

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-9751-ge3ad4c45d128c1f4a69f86116a36312aa593554c
Author: Harald Anlauf 
Date:   Tue Sep 7 20:51:49 2021 +0200

Fortran - improve error recovery determining array element from constructor

gcc/fortran/ChangeLog:

PR fortran/101327
* expr.c (find_array_element): When bounds cannot be determined as
constant, return error instead of aborting.

gcc/testsuite/ChangeLog:

PR fortran/101327
* gfortran.dg/pr101327.f90: New test.

(cherry picked from commit 2a1537a19cb2fa85823cfa18ed40baa4b259b4e3)

[Bug c/102549] Incorrect optimization if argument is SNAN

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

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

--- Comment #2 from Andrew Pinski  ---
Note also from the docs:
This option is experimental and does not currently guarantee to disable all GCC
optimizations that affect signaling NaN behavior.

[Bug libstdc++/59769] please add ios_base::__noreplace

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I have started a discussion about getting this into the standard.

[Bug c/102549] Incorrect optimization if argument is SNAN

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

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

--- Comment #1 from Andrew Pinski  ---
I think you need -fsignaling-nans

[Bug c++/102547] g++ 11. ICE with NTTPs and partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-30
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context

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

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

--- Comment #2 from Iain Sandoe  ---
#include 

struct task {
struct promise_type {
std::suspend_always initial_suspend();
std::suspend_always final_suspend() noexcept;
task get_return_object();
void return_void();
void unhandled_exception();
};
};

task
my_coro ()
{
  try
{ }
  catch (...)
{
  // [expr.await]
  co_await std::suspend_always{}; // { dg-error "We should have an error
here" }
}
}

[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-30
 CC||iains at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Iain Sandoe  ---
indeed we should reject this

[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:97a5a41dbfef1722fdaf4dc979e8b9c274b4404d

commit r9-9750-g97a5a41dbfef1722fdaf4dc979e8b9c274b4404d
Author: Harald Anlauf 
Date:   Thu Sep 9 21:34:01 2021 +0200

Fortran - out of bounds in array constructor with implied do loop

gcc/fortran/ChangeLog:

PR fortran/98490
* trans-expr.c (gfc_conv_substring): Do not generate substring
bounds check for implied do loop index variable before it actually
becomes defined.

gcc/testsuite/ChangeLog:

PR fortran/98490
* gfortran.dg/bounds_check_23.f90: New test.

(cherry picked from commit 5fe0865ab788bdc387b284a3ad57e5a95a767b18)

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:3a70195d7da49fe793ce3eb0e839b9ceea96c97a

commit r9-9749-g3a70195d7da49fe793ce3eb0e839b9ceea96c97a
Author: Harald Anlauf 
Date:   Mon Sep 13 19:28:10 2021 +0200

Fortran - ensure simplification of bounds of array-valued named constants

gcc/fortran/ChangeLog:

PR fortran/82314
* decl.c (add_init_expr_to_sym): For proper initialization of
array-valued named constants the array bounds need to be
simplified before adding the initializer.

gcc/testsuite/ChangeLog:

PR fortran/82314
* gfortran.dg/pr82314.f90: New test.

(cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:39b948a8f404aa0bfb632d7b26bb0692b18f60c9

commit r10-10156-g39b948a8f404aa0bfb632d7b26bb0692b18f60c9
Author: Harald Anlauf 
Date:   Mon Sep 13 19:28:10 2021 +0200

Fortran - ensure simplification of bounds of array-valued named constants

gcc/fortran/ChangeLog:

PR fortran/82314
* decl.c (add_init_expr_to_sym): For proper initialization of
array-valued named constants the array bounds need to be
simplified before adding the initializer.

gcc/testsuite/ChangeLog:

PR fortran/82314
* gfortran.dg/pr82314.f90: New test.

(cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)

[Bug c/102549] New: Incorrect optimization if argument is SNAN

[Serge.Pavlov.at.gnu at gmail dot com via Gcc-bugs]

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

Bug ID: 102549
   Summary: Incorrect optimization if argument is SNAN
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Serge.Pavlov.at.gnu at gmail dot com
  Target Milestone: ---

GCC was taken at https://godbolt.org, the reported version is:

gcc
(Compiler-Explorer-Build-gcc-d6a87d96d7473cbd2404d5dcc7eef36a7f53b2b2-binutils-2.36.1)
12.0.0 20210929 (experimental)

The program is:

extern int printf(const char *fmt, ...);
union {
double f;
long long i;
} val;
double add_zero(double x) {
return x + -0.0;
}
int main(int arc, char *argv[]) {
val.i = 0x7ff4LL; // SNaN
val.f = add_zero(val.f);
printf("%llx\n", val.i);
return 0;
}

Compiled with options "-O2" this program prints
(https://godbolt.org/z/YE13qEhf9):
7ff4

This is incorrect as this is SNaN, but according to IEEE 754-2008, 6.2:

Under default exception handling, any operation signaling an invalid operation
exception and for which a
floating-point result is to be delivered shall deliver a quiet NaN.
Signaling NaNs shall be reserved operands that, under default exception
handling, signal the invalid
operation exception (see 7.2) for every general-computational and
signaling-computational operation except
for the conversions described in 5.12.

And according to the latest standard draft
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf), F.3p1:

C operators, functions, and function-like macros provide operations specified
by IEC 60559 as shown
in the following table. ... The C specifications are
intended to match IEC 60559, unless stated otherwise.

So a QNaN is expected here.

If "-0.0" is replaced with the positive zero:

double add_zero(double x) {
return x + 0.0;
}

the behavior is as expected, the program prints:
7ffc

which is QNaN.

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-3993-gb19bbfb1482505367dd19ae4ab1ea19e36802b6a
Author: Harald Anlauf 
Date:   Thu Sep 30 20:29:31 2021 +0200

Fortran: resolve expressions during SIZE simplification

gcc/fortran/ChangeLog:

PR fortran/102458
* simplify.c (simplify_size): Resolve expressions used in array
specifications so that SIZE can be simplified.

gcc/testsuite/ChangeLog:

PR fortran/102458
* gfortran.dg/pr102458b.f90: New test.

[Bug c++/102548] New: gcc segmentation fault in cc1plus (with repro case)

[ulatekh at yahoo dot com via Gcc-bugs]

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

Bug ID: 102548
   Summary: gcc segmentation fault in cc1plus (with repro case)
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ulatekh at yahoo dot com
  Target Milestone: ---

Created attachment 51525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51525=edit
Preprocessed source

Found this with the current MSYS2 MinGW compiler (building a bleeding-edge
version of cmake), but it also crashes on my Fedora 33 machine when running
"g++ -march=x86-64 -m32 cmTimestamp.ii".

[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on affected branches.  Closing.

Thanks for the report!

[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

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

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

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

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

commit r10-10155-gf653f612a95ab9d54e005fba7ac6bb40ec14ffb9
Author: Harald Anlauf 
Date:   Wed Sep 29 20:11:53 2021 +0200

Fortran: fix error recovery for invalid constructor

gcc/fortran/ChangeLog:

PR fortran/102520
* array.c (expand_constructor): Do not dereference NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/102520
* gfortran.dg/pr102520.f90: New test.

(cherry picked from commit 5e2adfeed21ee584a82cdcdfa7eed41202eb67cd)

[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

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

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

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

https://gcc.gnu.org/g:0212bcfc31a938d4b2f247dc42f75b1d523bb1ef

commit r11-9047-g0212bcfc31a938d4b2f247dc42f75b1d523bb1ef
Author: Harald Anlauf 
Date:   Wed Sep 29 20:11:53 2021 +0200

Fortran: fix error recovery for invalid constructor

gcc/fortran/ChangeLog:

PR fortran/102520
* array.c (expand_constructor): Do not dereference NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/102520
* gfortran.dg/pr102520.f90: New test.

(cherry picked from commit 5e2adfeed21ee584a82cdcdfa7eed41202eb67cd)

[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3

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

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

--- Comment #3 from Aldy Hernandez  ---

> What I fail to see is how "a" got removed entirely from the IL, making this
> scenario possible:
> 
>  if (!(a >= d || f))
> foo();

What I meant to say is that I don't understand how "a" got removed from the IL
representing this:

 if (!(a >= d || f))
 foo();

Because it's the missing "a" which opens the door for the un-folded expression
here:

(f_8 << f_8) && (f_8 == 0)

[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885

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

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

--- Comment #3 from Aldy Hernandez  ---
To elide the foo(), _2 must be non-zero on the 2->3 edge dominating the call.

Interestingly, a.0_1 is non-zero on the 2->3 edge, and we have:

_2 = (unsigned int) a.0_1

but somehow we have no knowledge of _2.

Andrew, wanna take a stab at this?

=== BB 2 
Imports: a.0_1  
Exports: a.0_1  _6  c_10  
 _2 : a.0_1(I)  
 _6 : a.0_1(I)  
 c_10 : a.0_1(I)  _6  
Equivalence set : []
Equivalence set : [_6, c_10]
 :
a.0_1 = a;
_2 = (unsigned int) a.0_1;
b = _2;
_6 = a.0_1 & 4294967295;
c_10 = _6;
if (c_10 != 0)
  goto ; [INV]
else
  goto ; [INV]

_6 : long int [0, 4294967295]
c_10 : long int [0, 4294967295]
2->3  (T) a.0_1 :   long int [-INF, -1][1, +INF]
2->3  (T) _6 :  long int [1, 4294967295]
2->3  (T) c_10 :long int [1, 4294967295]
2->6  (F) a.0_1 :   long int [-INF, -4294967296][0, +INF]
2->6  (F) _6 :  long int [0, 0]
2->6  (F) c_10 :long int [0, 0]

[Bug target/89954] missed optimization for signed extension for x86-64

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #12 from Uroš Bizjak  ---
Implemented for gcc-12.

[Bug target/89954] missed optimization for signed extension for x86-64

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:6f4459c478b1c09e4b5e7d629fbf46d2a4fe4560

commit r12-3991-g6f4459c478b1c09e4b5e7d629fbf46d2a4fe4560
Author: Uros Bizjak 
Date:   Thu Sep 30 19:33:49 2021 +0200

i386: Eliminate sign extension after logic operation [PR89954]

Convert (sign_extend:WIDE (any_logic:NARROW (memory, immediate)))
to (any_logic:WIDE (sign_extend (memory)), (sign_extend (immediate))).
This eliminates sign extension after logic operation.

2021-09-30  Uroš Bizjak  

gcc/
PR target/89954
* config/i386/i386.md
(sign_extend:WIDE (any_logic:NARROW (memory, immediate))
splitters):
New splitters.

gcc/testsuite/
PR target/89954
* gcc.target/i386/pr89954.c: New test.

[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com

--- Comment #2 from Aldy Hernandez  ---
By VRP1 we seem to be calculating the following:

(f_8 << f_8) && (f_8 == 0)

This would fold to false, which would elide the foo():

  [local count: 59055800]:
  b = 0;
  _3 = f_8 << f_8;
  _4 = (char) _3;
  _5 = (int) _4;
  if (_4 > 0)
goto ; [64.06%]
  else
goto ; [35.94%]

   [local count: 34842922]:
  if (f_8 == 0)
goto ; [71.10%]
  else
goto ; [28.90%]

   [local count: 12809203]:
  foo ();

So from the outset, it seems like this is a missing relation in range-ops. 
That is if we know f_8 << f_8 is non-zero, then we know f_8 cannot be 0.  This
looks like an easy fix, however...

What I fail to see is how "a" got removed entirely from the IL, making this
scenario possible:

 if (!(a >= d || f))
foo();

Am I missing something obvious here?

[Bug fortran/71703] [9/10/11/12 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383

commit r12-3990-g643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383
Author: Tobias Burnus 
Date:   Thu Sep 30 19:08:25 2021 +0200

Fortran: Fix same_type_as

A test for CLASS(*) + assumed rank was missing; adding a test to
unlimited_polymorphic_1.f03 showed an ICE as backend_decl wasn't
set. While gfc_get_symbol_decl would fix it, the code also assumed
that the class(*) was a variable and could not be a subobject of
a derived type.

PR fortran/71703
PR fortran/84007

gcc/fortran/ChangeLog:

* trans-intrinsic.c (gfc_conv_same_type_as): Fix handling
of UNLIMITED_POLY.
* trans.h (gfc_vtpr_hash_get): Renamed prototype to ...
(gfc_vptr_hash_get): ... this to match function name.

gcc/testsuite/ChangeLog:

* gfortran.dg/c-interop/c535b-1.f90: Remove wrong comment.
* gfortran.dg/unlimited_polymorphic_1.f03: Extend.
* gfortran.dg/unlimited_polymorphic_32.f90: New test.

[Bug fortran/84007] [OOP] ICE with SAME_TYPE_AS and CLASS(*) entity

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383

commit r12-3990-g643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383
Author: Tobias Burnus 
Date:   Thu Sep 30 19:08:25 2021 +0200

Fortran: Fix same_type_as

A test for CLASS(*) + assumed rank was missing; adding a test to
unlimited_polymorphic_1.f03 showed an ICE as backend_decl wasn't
set. While gfc_get_symbol_decl would fix it, the code also assumed
that the class(*) was a variable and could not be a subobject of
a derived type.

PR fortran/71703
PR fortran/84007

gcc/fortran/ChangeLog:

* trans-intrinsic.c (gfc_conv_same_type_as): Fix handling
of UNLIMITED_POLY.
* trans.h (gfc_vtpr_hash_get): Renamed prototype to ...
(gfc_vptr_hash_get): ... this to match function name.

gcc/testsuite/ChangeLog:

* gfortran.dg/c-interop/c535b-1.f90: Remove wrong comment.
* gfortran.dg/unlimited_polymorphic_1.f03: Extend.
* gfortran.dg/unlimited_polymorphic_32.f90: New test.

[Bug d/102476] d: Options -fmain and -fno-druntime do not work together

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fix committed.

[Bug d/102476] d: Options -fmain and -fno-druntime do not work together

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r12-3985-gd46a29d919058fb383d19fe35c234fab58286f71
Author: Iain Buclaw 
Date:   Fri Sep 24 10:59:47 2021 +0200

libphobos: Define main function as extern(C) when compiling without D
runtime (PR102476)

The default supplied main function as read when compiling with `-fmain'
has extern(D) linkage.  However this does not work when mixing this
option together with `-fno-druntime'.

PR d/102476

gcc/testsuite/ChangeLog:

* gdc.dg/pr102476.d: New test.

libphobos/ChangeLog:

* libdruntime/__main.di: Define main function as extern(C) when
compiling without D runtime.

[Bug c++/102547] New: g++ 11. ICE with NTTPs and partial specialization

[bob.steagall.cpp at gmail dot com via Gcc-bugs]

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

Bug ID: 102547
   Summary: g++ 11. ICE with NTTPs and partial specialization
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bob.steagall.cpp at gmail dot com
  Target Milestone: ---

The following C++ source code:

---

template
struct vals {};


template
struct vals_client {};

template
struct vals_client, A> {};

template
struct vals_client, void> {};


void testfn()
{
vals_client, int>   ci;  //- OK
vals_client, void>  cv;  //- "sorry, unimplemented..., ICE" 
}

---

When compiled with gcc 11.X generates this error:


nttp_test.cpp: In function 'void testfn()':
nttp_test.cpp:18:36: sorry, unimplemented: unexpected AST of kind
nontype_argument_pack
   18 | vals_client, void>  cv;  //- "sorry, unimplemented..."
  |^~
nttp_test.cpp:18: confused by earlier errors, bailing out

---

When compiled with gcc trunk on godbolt.org, it elicits an ICE:

: In function 'void testfn()':
:23:36: sorry, unimplemented: unexpected AST of kind
nontype_argument_pack
   23 | vals_client, void>  cv;  //- "sorry, unimplemented...,
ICE"
  |^~
:23:36: internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:9051
0x1fe73f9 internal_error(char const*, ...)
???:0
0x7d40a7 fancy_abort(char const*, int, char const*)
???:0
0x8475ff potential_constant_expression(tree_node*)
???:0
0xa21bd7 instantiation_dependent_expression_p(tree_node*)
???:0
0xa21c46 uses_template_parms(tree_node*)
???:0
0xa72888 most_specialized_partial_spec(tree_node*, int)
???:0
0xa7f834 instantiate_class_template(tree_node*)
???:0
0x89e107 start_decl_1(tree_node*, bool)
???:0
0x8c552f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xa08395 c_parse_file()
???:0
0xb8f562 c_common_parse_file()
???:0
Please submit a full bug report, ...

---

Testing with various version on godbolt.org reveals that the ICE does not 
occur with 10.X, 9.X, 8.X, or 7.X  (that's as far back as I went).

[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
A little -fdbg-cnt bisecting magic shows that the first jump thread causes some
sort of reaction downstream in unrolljam:

./cc1 a.c -quiet -O3 -fno-tree-ch -fdbg-cnt=registered_jump_thread:1-1
***dbgcnt: lower limit 1 reached for registered_jump_thread.***
***dbgcnt: upper limit 1 reached for registered_jump_thread.***
during GIMPLE pass: unrolljam
a.c: In function ‘b’:
a.c:5:6: internal compiler error: Segmentation fault

So it's the first threading path that is causing an issue.  Setting a
breakpoint at path registering yields this:

Breakpoint 5, jt_path_registry::register_jump_thread (this=0x391f150, Python
Exception  There is no member or method named m_vecpfx.: 
path=0x3a09430)
at /home/aldyh/src/gcc/gcc/tree-ssa-threadupdate.c:2838
(gdb) p ::debug(path)
  [1] Registering jump thread: (8, 4) incoming edge;  (4, 3) normal; 

It's threading 8->4->3, which looks perfectly reasonable:

   [local count: 1073741824]:
  # i_5 = PHI <0(8), i_12(3)>
  if (i_5 != 200)
goto ; [99.00%]
  else
goto ; [1.00%]

Note that i_5 is known to be 0 on the 8->4 edge.

The loop info says that bb8 is the pre-header to loop 2 which starts at bb4. 
So this technically crosses loops into bb4, but is allowed as there's an
exception when the first BB is in another block:

  // The first entry represents the block with an outgoing edge
  // that we will redirect to the jump threading path.  Thus we
  // don't care about that block's loop father.

Similarly in the back threader profitability code:

 /* Remember, blocks in the path are stored in opposite order
 in the PATH array.  The last entry in the array represents
 the block with an outgoing edge that we will redirect to the
 jump threading path.  Thus we don't care about that block's
 loop father, nor how many statements are in that block because
 it will not be copied or whether or not it ends in a multiway
 branch.  */

For reference, here is the full IL:

  int i;
  int _1;
  int _2;
  int _3;
  int b_j.3_4;

   [local count: 1327096]:
  b_j = 1;
  goto ; [100.00%]

   [local count: 1063004409]:
  _1 = b_j.3_4 + -1;
  _2 = a[i_5][_1];
  a[i_5][b_j.3_4] = _2;
  i_12 = i_5 + 1;

   [local count: 1073741824]:
  # i_5 = PHI <0(8), i_12(3)>
  if (i_5 != 200)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 10737416]:
  _3 = b_j.3_4 + 1;
  b_j = _3;

   [local count: 12064512]:
  b_j.3_4 = b_j;
  if (b_j.3_4 <= 199)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 10737416]:
  goto ; [100.00%]

   [local count: 1327096]:
  return;

I think this is a problem elsewhere.

[Bug c++/96517] ICE in is_this_parameter when accessing constexpr method of a field inside coroutine lambda (with optimization)

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2021-09-30
   Target Milestone|--- |10.4
 Status|UNCONFIRMED |NEW
 CC||iains at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/102363] source_location in await_transform has function_name referring to internal coroutine funclet rather than source-level function

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-30
 Status|UNCONFIRMED |NEW
 CC||iains at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
source location information needs some work in the synthesis - the defaults are
not the most useful.

[Bug c++/93642] [Coroutines] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070 using co_return

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org
 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Iain Sandoe  ---
works OK on gcc-10 gcc-11 and gcc-12 branches as of today.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

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

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

Bug 94197 Summary: __is_constructible gives an access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197

   What|Removed |Added

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

[Bug c++/94197] __is_constructible gives an access error

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |10.0
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10+

[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

--- Comment #7 from Iain Sandoe  ---
(In reply to Marek Polacek from comment #6)
> Would it be possible to backport this to gcc 11 too?

it's on my TODO to back port the correctness fixes to 11 (and where feasible
10).

[Bug c++/102535] __is_trivially_constructible rejects some trivial cases in aggregate initializations

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-30
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
Would it be possible to backport this to gcc 11 too?

[Bug c++/102545] [modules] inlining constexpr is required yet it should not be.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
But the above is not a static data member, so it is not inline by default.

[Bug c++/102545] [modules] inlining constexpr is required yet it should not be.

[e9leyland at outlook dot com via Gcc-bugs]

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

--- Comment #1 from Emily Leyland  ---
Good question, there seems to be some debate. From
en.cppreference.com/w/cpp/language/constexpr, A constexpr specifier used in a
function or static data member (since C++17) declaration implies inline.

[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3

[theodort at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #1 from Theodoros Theodoridis  ---
It bisects to 2e96b5f14e4025691b57d2301d71aa6092ed44bc

[Bug tree-optimization/102546] New: Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 102546
   Summary: Missed Dead Code Elimination regression (trunk vs
11.2.0) at -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

cat missed_case.c
static int a;
static char b, c, d;
void bar(void);
void foo(void);

int main() {
int f = 0;
for (; f <= 5; f++) {
bar();
b = b && f;
d = f << f;
if (!(a >= d || f))
foo();
c = 1;
for (; c; c = 0)
;
}
}


11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:

gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ 
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210930 (experimental) (GCC)

gcc-trunk -O3 -S missed_case.c

main:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
xorl%ebx, %ebx
.L6:
callbar
cmpb$0, b(%rip)
je  .L2
testl   %ebx, %ebx
jne .L5
movb$0, b(%rip)
movl$1, %ebx
movb$0, c(%rip)
callbar
cmpb$0, b(%rip)
je  .L4
.L5:
movb$1, b(%rip)
.L4:
addl$1, %ebx
movb$0, c(%rip)
cmpl$6, %ebx
jne .L6
xorl%eax, %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L2:
.cfi_restore_state
movl%ebx, %eax
movl%ebx, %ecx
sall%cl, %eax
testb   %al, %al
jle .L4
testl   %ebx, %ebx
jne .L4
callfoo
movb$0, c(%rip)
movl$1, %ebx
callbar
cmpb$0, b(%rip)
jne .L5
jmp .L2
.cfi_endproc


gcc-11 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ 
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

cat missed_case.s

main:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$5, %ebx
callbar
movb$0, b(%rip)
movb$0, c(%rip)
.p2align 4,,10
.p2align 3
.L2:
callbar
cmpb$0, b(%rip)
movb$0, c(%rip)
setne   b(%rip)
subl$1, %ebx
jne .L2
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

[Bug middle-end/102518] [11/12 regression] ICE during GIMPLE pass: einline in gimplify_modify_expr at -O2 since r11-165-geb72dc663e9070b2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will have a look.  We're getting

# VUSE <.MEM>
_2 = MEM[(struct A *)&].x;

when mapping  into

   [local count: 1073741824]:
  _1 = MEM[(struct A *)].x;
  _2 = _1 != 0B;
  _4 = (int) _2;
  return _4;

here what's the difference is that 'c' is no longer TREE_ADDRESSABLE because
we can now mark it with DECL_NOT_GIMPLE_REG.

That means the "obvious" fix would be to amend the !TREE_ADDRESSABLE check in

  if (TREE_READONLY (p)
  && !TREE_ADDRESSABLE (p)
  && value
  && !TREE_SIDE_EFFECTS (value)
  && !def)

with a !DECL_NOT_GIMPLE_REG check.

[Bug c++/102530] Warn about non-extended temporary passed to a function returning a reference in temp-extending context

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Would this warning go under a new flag, or an existing one?

[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
 Blocks||85316
Version|unknown |12.0

--- Comment #2 from Richard Biener  ---
FRE1 has the following difference, simplifying the (unsigned int) truncation.

:
   a.0_1 = a;
   _2 = (unsigned int) a.0_1;
   b = _2;
-  c_10 = (long int) _2;
+  _6 = a.0_1 & 4294967295;
+  c_10 = _6;
   if (c_10 != 0)
 goto ; [INV]
   else

where the EVRP which now uses ranger retains (diff from GCC 11 to trunk):

:
   a.0_1 = a;
   _2 = (unsigned int) a.0_1;
   b = _2;
-  c_10 = (long int) _2;
+  _6 = a.0_1 & 4294967295;
+  c_10 = _6;
   if (c_10 != 0)
 goto ; [INV]
   else
-goto ; [INV]
+goto ; [INV]

:
   _4 = c_10 + 1;
   iftmp.2_12 = 2 / _4;
+  if (iftmp.2_12 != 0)
+goto ; [INV]
+  else
+goto ; [INV]

:
+  if (_2 == 0)
+goto ; [INV]
+  else
+goto ; [INV]
+
+   :
+  foo ();
+
+   :
   a = 0;
   return 0;


after EVRP we have

+  # RANGE [0, 4294967295] NONZERO 4294967295
   c_10 = _6;
...
+  # RANGE [2, 4294967296] NONZERO 8589934591
   _4 = c_10 + 1;
+  # RANGE [0, 1] NONZERO 1
   iftmp.2_12 = 2 / _4;
   if (iftmp.2_12 != 0)

what we did in GCC 11 is simplified the following check

   :
  if (_2 == 0)
goto ; [INV]
  else
goto ; [INV]

based on iftmp.2_12 == [1, 1] via ranger and

evrp visiting BB4
Visiting controlling predicate if (iftmp.2_12 != 0)
Adding assert for iftmp.2_12 from iftmp.2_12 != 0
Intersecting
  long int ~[0, 0]  EQUIVALENCES: { iftmp.2_12 } (1 elements)
and
  long int [0, 1]
to
  long int [1, 1]  EQUIVALENCES: { iftmp.2_12 } (1 elements)
Intersecting
  long int [0, 1]
and
  long int [1, 1]
to
  long int [1, 1]
pushing new range for iftmp.2_12: long int [1, 1]  EQUIVALENCES: { iftmp.2_12 }
(1 elements)
evrp visiting stmt if (_2 == 0)
Folding statement: if (_2 == 0)

Visiting conditional with predicate: if (_2 == 0)

With known ranges
_2: unsigned int [1, +INF]  EQUIVALENCES: { _2 } (1 elements)

Predicate evaluates to: 0
Folded into: if (0 != 0)

that's now missing, somehow due to the folded IL if the bisect is correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug c++/102104] parameter packs not expanded with '...' for operator conversions

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'

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

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

--- Comment #1 from Andrew Stubbs  ---
Please set "export GCN_DEBUG=1", try it again, and post the output.

[Bug testsuite/102509] [12 regression] new test case gcc.c-torture/compile/attr-complex-method.c is unresolved after r12-3901

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed.

[Bug testsuite/102509] [12 regression] new test case gcc.c-torture/compile/attr-complex-method.c is unresolved after r12-3901

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r12-3982-gc3d11a1e9528b6140c65a66d47225a0b6a8814e0
Author: Martin Liska 
Date:   Thu Sep 30 14:12:35 2021 +0200

testsuite: Skip a test-case when LTO is used [PR102509]

PR testsuite/102509

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/attr-complex-method.c: Skip if LTO is
  used.
* gcc.c-torture/compile/attr-complex-method-2.c: Likewise.

[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2021-09-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Iain Sandoe  ---
(In reply to Matt Jacobson from comment #0)
> I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin
> platform (AVR micros).  I'd like my Objective-C code to make use of the most
> modern ABI features, namely those guarded in the code by `flag_next_runtime
> >= USE_FIXUP_BEFORE`.
> 
> However, there appears to be no way to control `flag_next_runtime` (short of
> modifying the compiler source).  I can set it to zero with `-fgnu-runtime`
> or one with `-fnext-runtime`, but `USE_FIXUP_BEFORE` is an encoded Mac OS X
> version (namely 100600, referring to Snow Leopard).

by current design, there are enough bits in the value so that ne can have N
MSBs representing the platform and N representing the version.

> There is Darwin-specific option parsing code (`darwin_override_options()`)
> that appears to set `flag_next_runtime` based on `-mmacosx-version-min`, but
> obviously that doesn't run for non-Darwin targets.

Most targets have an equivalent "override options" section where they could
make a similar selection.

A simplistic case would be to say any value >99 is not Darwin (i.e we make
the Darwin platform part of the runtime value == 0 and then any other platform
that wants to take an encoding takes a value higher; this would default to the
next runtime just using "latest and greatest" - but that might not be what you
want in say 2 years time...

... however, it would be better to use bit boundaries rather than arbitrary
decimal.

maybe ...
0xff00 masks the platform 
0x00ff masks the version selector

and Darwin is platform 0 for this purpose.

so as a quick fix you could just say AVR is platform 1 and set it to 
0x0100 in your platform flags override ...

> I could imagine a few approaches to fixing this:
> 
> 1. Parse `-mmacosx-version-min` even when the target is not Darwin, whenever
> we're compiling Objective-C.  On non-Darwin, this would be interpreted as
> requesting Objective-C codegen compatible with the Objective-C ABI of the
> specified release of Mac OS X.

I do not think that is going to fly ;)

> 2. Allow an argument to `-fnext-runtime`, with the meaning approximately the
> same as in #1.
> 
> 3. Instead of using `flag_next_runtime` as a version number, switch it back
> to being zero or one, and use a separate flag (perhaps the existing
> `-fobjc-abi-version`?) to differentiate ABIs.

These two were both thoughts during the development but I suspect that the
mapping to values is a build-time decision and ought to be done in the flags
override code.

thoughts?

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #14 from Aldy Hernandez  ---
fixed

[Bug c++/102545] New: inlining constexpr is required yet it should not be.

[e9leyland at outlook dot com via Gcc-bugs]

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

Bug ID: 102545
   Summary: inlining constexpr is required yet it should not be.
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e9leyland at outlook dot com
  Target Milestone: ---

I module file rev.cpp there is the following,

module;

export import ;
export import ;

export module rev;

namespace rev {

export inline constexpr auto FAV_TEST_VAL = u8'9';

}

In the consumer file, main.cpp there is this,

import rev;
import ;

int
main(int, char**)
{
auto TEST_VAL = rev::FAV_TEST_VAL;
std::cout << std::hex << int(TEST_VAL) << std::endl;
}

The makefile has,

$ cat Makefile
.PHONY: default
default: main ;

gcmcache:
g++ -fmodules-ts -std=c++20 -x c++-system-header concepts
g++ -fmodules-ts -std=c++20 -x c++-system-header limits
g++ -fmodules-ts -std=c++20 -x c++-system-header iostream

rev.o: rev.cpp
g++ -c -std=c++20 -fmodules-ts rev.cpp

main: main.cpp rev.o
g++ -fmodules-ts -std=c++20 -o main main.cpp rev.o

clean:
rm rev.o main.exe rm -rf gcm.cache

The constexpr must be given the inline specifier to work, because if it is not
there the following error occurs.

$ make
g++ -c -std=c++20 -fmodules-ts rev.cpp
g++ -fmodules-ts -std=c++20 -o main main.cpp rev.o
main.cpp: In function ‘int main(int, char**)’:
main.cpp:7:26: error: ‘FAV_TEST_VAL’ is not a member of ‘rev’
7 | auto TEST_VAL = rev::FAV_TEST_VAL;
  |  ^~~~
make: *** [Makefile:13: main] Error 1

Shouldn't the constexpr be sufficient to inline the function from the standard?
In comparison to VS2022 the inline is not required, nor should it be.

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Aldy Hernandez  ---
> (In reply to Aldy Hernandez from comment #11)
>> This looks mighty suspicious ;-)
>> 
>> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
>> index 69a3ab0ea9d..c24c67f8874 100644
>> --- a/gcc/tree-vrp.c
>> +++ b/gcc/tree-vrp.c
>> @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader ()
>>delete m_threader;
>>delete m_state;
>>delete m_ranger;
>> +  delete m_query;
>> 
>>scev_finalize ();
>>loop_optimizer_finalize ();
>
> FWIW, all the patches so far proposed have been pushed to trunk, if you want 
> to
> try again.

This has done the trick: current master bootstraps again on
i386-pc-solaris2.11.

Thanks.