[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #6 from Aldy Hernandez --- (In reply to Richard Biener from comment #5) > + int_range<2> invalid_range (build_int_cst (size_type_node, 0), > + build_int_cst (size_type_node, max_size), > >r.intersect (invalid_range); > > is there no way to .intersect with a wide_int instead? Patch is posted upstream, so you can respond there. But no, the intersect() method is from irange to irange. I suppose when we get rid of trees and go back to faster wide-ints for the internal representation, we could add such a method.
[Bug tree-optimization/102585] New: [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102585
Bug ID: 102585
Summary: [12 Regression] ICE in final_scan_insn_1, at
final.c:2629 since r12-4038-g6de9f0c13b27c343
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat uninit.c
#pragma GCC optimize 0
void d_demangle_callback_Og() { int c = 0; }
$ gcc uninit.c -fvar-tracking-assignments-toggle -fno-var-tracking -c
during RTL pass: final
uninit.c: In function ‘d_demangle_callback_Og’:
uninit.c:2:44: internal compiler error: in final_scan_insn_1, at final.c:2629
2 | void d_demangle_callback_Og() { int c = 0; }
|^
0x6da26f final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.c:2629
0xb7216f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.c:2940
0xb72266 final_1
/home/marxin/Programming/gcc/gcc/final.c:1997
0xb72ed5 rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.c:4285
0xb72ed5 execute
/home/marxin/Programming/gcc/gcc/final.c:4363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102585 Martin Liška changed: What|Removed |Added Known to work||11.2.0 Known to fail||12.0 Last reconfirmed||2021-10-04 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug tree-optimization/102564] Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-04 Version|unknown |12.0 --- Comment #2 from Richard Biener --- The issue is that t can point anywhere into p[], Andrew is correct in that we could in theory do a runtime check but unfortunately vectorization relies on reductions being done on registers and thus store-motion to have taken place. But store-motion does not do any runtime alias checks. The fix is at the source level to add __restrict__ to p for example or to perform the store-motion yourself as you've done in test3. In principle the vectorizer could do reduction vectorization on stride zero memory accesses as well, but currently we give up on such stores completely.
[Bug ipa/102554] [10/11 Regression] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-04 Summary|[10/11/12 Regression] |[10/11 Regression] Inlining |Inlining missed at -O3 with |missed at -O3 with |non-default |non-default |--param=early-inlining-insn |--param=early-inlining-insn |s and pragma optimize |s and pragma optimize Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > I suspect that the optimize() attribute resets the param value to its > default. Yes, it's fixed on master with g:r12-4038-g6de9f0c13b27c343. > > Martin - can you investigate / bisect? Sure, it started with r10-4944-g1e83bd7003e03160. I tend closing that as fixed, what do you think Richi?
[Bug tree-optimization/102569] Missed redudant add with add_overflow on the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102569 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords|TREE| --- Comment #1 from Richard Biener --- Confirmed. VN could indeed add alternate expression variants for the overflow IFNs. But note we have to care for the IMAGPART eventually getting unused and fold the IFN back to a bare PLUS (I guess we already to that part). It will also get tricky when we see _1 = _2 + _3; _4 = .ADD_OVERFLOW (_2, _3); _5 = REALPART_EXPR <_4>; _6 = IMAGPART_EXPR <_4>; where we don't want to replace _5 with _1 and we cannot generally replace _1 with _5 ... So it would be interesting to see real-world cases where we miss opportunities.
[Bug tree-optimization/102570] missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-10-04 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- FRE doesn't handle internal function calls at all (I think it ICEs, so originally we just short-cut them). Let me take a look.
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 since r11-3070-g783dc66f9ccb0019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|[11/12 Regression] ICE for |[11/12 Regression] ICE for |skx in |skx in |vect_build_gather_load_call |vect_build_gather_load_call |s, at |s, at |tree-vect-stmts.c:2835 |tree-vect-stmts.c:2835 ||since ||r11-3070-g783dc66f9ccb0019 --- Comment #3 from Martin Liška --- Confirmed, started with r11-3070-g783dc66f9ccb0019.
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 since r11-3070-g783dc66f9ccb0019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I can take a look.
[Bug tree-optimization/102575] Failure to optimize double _Complex stores to use largest loads/stores possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102575 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||53947 --- Comment #2 from Richard Biener --- The vectorizer doesn't like vector or complex typed loads and stores (and it starts before SLP). There are duplicate bugreports and it's unfortunately not as easy as it looks like. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Summary|[12 Regression] ice in |[12 Regression] ice in |forced_merge, at|forced_merge, at |ipa-modref-tree.h:352 with |ipa-modref-tree.h:352 with |-fno-strict-aliasing and|-fno-strict-aliasing and |-O2 |-O2 since ||r12-3202-gf5ff3a8ed4ca9173 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102557 Status|UNCONFIRMED |NEW --- Comment #3 from Martin Liška --- Confirmed, similar to PR102557.
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Martin Liška changed: What|Removed |Added Target Milestone|7.3 |12.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug tree-optimization/102586] New: [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
Bug ID: 102586
Summary: [12 Regression] ICE in clear_padding_type, at
gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
Target Milestone: ---
The following fails:
$ cat vbase.cc
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C4 : virtual C2, C1 {};
struct C5 : virtual C4, C1 {};
struct C9 : C5 {};
int main() { C9 c9; }
$ g++ vbase.cc -ftrivial-auto-var-init=pattern -c
vbase.cc:4:8: warning: direct base ‘C1’ inaccessible in ‘C4’ due to ambiguity
[-Winaccessible-base]
4 | struct C4 : virtual C2, C1 {};
|^~
vbase.cc:5:8: warning: direct base ‘C1’ inaccessible in ‘C5’ due to ambiguity
[-Winaccessible-base]
5 | struct C5 : virtual C4, C1 {};
|^~
during GIMPLE pass: lower
vbase.cc: In function ‘int main()’:
vbase.cc:8:5: internal compiler error: in clear_padding_type, at
gimple-fold.c:4803
8 | int main() { C9 c9; }
| ^~~~
0x7e794a clear_padding_type
/home/marxin/Programming/gcc/gcc/gimple-fold.c:4803
0xee52e4 clear_padding_type
/home/marxin/Programming/gcc/gcc/gimple-fold.c:4798
0xee6063 gimple_fold_builtin_clear_padding
/home/marxin/Programming/gcc/gcc/gimple-fold.c:5005
0xef6178 gimple_fold_builtin
/home/marxin/Programming/gcc/gcc/gimple-fold.c:5179
0xef6178 gimple_fold_call
/home/marxin/Programming/gcc/gcc/gimple-fold.c:5587
0xef752b fold_stmt_1
/home/marxin/Programming/gcc/gcc/gimple-fold.c:6289
0x1e69a8f lower_stmt
/home/marxin/Programming/gcc/gcc/gimple-low.c:390
0x1e69bb2 lower_sequence
/home/marxin/Programming/gcc/gcc/gimple-low.c:217
0x1e69bb2 lower_stmt
/home/marxin/Programming/gcc/gcc/gimple-low.c:286
0x1e693ca lower_sequence
/home/marxin/Programming/gcc/gcc/gimple-low.c:217
0x1e693ca lower_gimple_bind
/home/marxin/Programming/gcc/gcc/gimple-low.c:475
0x1e693ca lower_sequence
/home/marxin/Programming/gcc/gcc/gimple-low.c:217
0x1e693ca lower_gimple_bind
/home/marxin/Programming/gcc/gcc/gimple-low.c:475
0x1e6a6cb lower_function_body
/home/marxin/Programming/gcc/gcc/gimple-low.c:110
0x1e6a6cb execute
/home/marxin/Programming/gcc/gcc/gimple-low.c:195
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Last reconfirmed||2021-10-04 CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102587] New: ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587
Bug ID: 102587
Summary: ICE in tree_to_uhwi, at tree.h:4668
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-linux-gnu
The following fails:
$ cat sve.c
void foo() { __SVFloat64_t f64; }
$ aarch64-linux-gnu-gcc sve.c -ftrivial-auto-var-init=zero -c
during RTL pass: expand
sve.c: In function ‘foo’:
sve.c:1:28: internal compiler error: in tree_to_uhwi, at tree.h:4668
1 | void foo() { __SVFloat64_t f64; }
|^~~
0x69b87a tree_to_uhwi(tree_node const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree.h:4668
0x69b87a expand_DEFERRED_INIT
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/internal-fn.c:3044
0x7f2957 expand_call_stmt
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:2749
0x7f2957 expand_gimple_stmt_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3876
0x7f2957 expand_gimple_stmt
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:4040
0x7f74b2 expand_gimple_basic_block
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6082
0x7f9306 execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||rguenth at gcc dot gnu.org
[Bug tree-optimization/102579] Failure to optimize out allocation if volatile read to a local is present in the middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102579 --- Comment #3 from Richard Biener --- Well, the issue is simply that we don't remove the volatile load and the call to 'new' is thought to possibly be a definition of 'd' via stmt_may_clobber_ref_p_1 which is because there's a volatile_p check before the may_be_aliased check: /* A call that is not without side-effects might involve volatile accesses and thus conflicts with all other volatile accesses. */ if (ref->volatile_p) return true; /* If the reference is based on a decl that is not aliased the call cannot possibly clobber it. */ if (DECL_P (base) && !may_be_aliased (base) /* But local non-readonly statics can be modified through recursion or the call may implement a threading barrier which we must treat as may-def. */ && (TREE_READONLY (base) || !is_global_var (base))) return false; so it indeed seems we're overly cautionous about this here and we could relax the volatile checks.
[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:51d9ef7747b2dc439f7456303f0784faf5cdb1d3 commit r12-4107-g51d9ef7747b2dc439f7456303f0784faf5cdb1d3 Author: Tobias Burnus Date: Mon Oct 4 09:38:43 2021 +0200 Fortran: Avoid var initialization in interfaces [PR54753] Intent(out) implies deallocation/default initialization; however, it is pointless to do this for dummy-arguments symbols of procedures which are inside an INTERFACE block. â This also fixes a bogus error for the attached included testcase, but fixing the non-interface version still has to be done. PR fortran/54753 gcc/fortran/ChangeLog: * resolve.c (can_generate_init, resolve_fl_variable_derived, resolve_symbol): Only do initialization with intent(out) if not inside of an interface block.
[Bug tree-optimization/102579] Failure to optimize out allocation if volatile read to a local is present in the middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102579
--- Comment #4 from Richard Biener ---
Ah, so the idea is that we want to avoid re-ordering volatile accesses even if
they do not alias. Note the global var case is handled because we're going the
mark_all_reaching_defs_necessary way here but the
mark_all_reaching_defs_necessary_1 worker has the special-case
/* We want to skip statments that do not constitute stores but have
a virtual definition. */
if (gcall *call = dyn_cast (def_stmt))
{
...
if (callee != NULL_TREE
&& (DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee)
|| DECL_IS_OPERATOR_DELETE_P (callee))
&& gimple_call_from_new_or_delete (call))
return false;
which the mark_aliased_reaching_defs_necessary_1 worker has not.
[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580 --- Comment #1 from Richard Biener --- It's "worse" on GIMPLE though.
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/102583] [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-04
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We're lacking stripping of a load that's only used partially I guess.
forwprop1
generates
_1 = *srcp_11(D);
_2 = BIT_FIELD_REF <_1, 32, 128>;
_3 = (float) _2;
_4 = BIT_FIELD_REF <_1, 32, 160>;
_5 = (float) _4;
_6 = BIT_FIELD_REF <_1, 32, 192>;
_7 = (float) _6;
_8 = BIT_FIELD_REF <_1, 32, 224>;
_9 = (float) _8;
_12 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
_15 = BIT_FIELD_REF <_12, 128, 0>;
_16 = (vector(4) float) _15;
and the second forwprop then sees
_1 = *srcp_3(D);
_4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
_5 = BIT_FIELD_REF <_4, 128, 0>;
_6 = (vector(4) float) _5;
in a single-use chain we probably want to try swapping the
BIT_FIELD_REF and the VEC_PERM_EXPR so that we expose the
BIT_FIELD_REF directly to the load which we'd already handle.
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I'll fix the ICE but leave VLA regs uninitialized.
[Bug tree-optimization/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102585 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581
--- Comment #4 from David Binderman ---
Reduced C++ source code, after a pretty hefty four hours of reduction, is
enum VkStructureType {
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR
} typedef VkPhysicalDeviceSparseProperties;
struct VkPhysicalDeviceProperties {
int apiVersion;
VkPhysicalDeviceSparseProperties sparseProperties;
};
typedef struct {
VkStructureType sType;
int *pPhysicalDevices;
} VkPhysicalDeviceFeatures2;
typedef struct VkPhysicalDeviceProperties2 {
VkStructureType sType;
void *pNext;
} VkPhysicalDeviceMemoryProperties2;
struct VulkanVersion {
int major;
int minor;
int patch;
};
int make_vulkan_version_version;
VulkanVersion make_vulkan_version() {
return {make_vulkan_version_version, make_vulkan_version_version,
make_vulkan_version_version};
}
struct AppGpu {
int &inst;
int id;
int *phys_device = nullptr;
VulkanVersion api_version{};
VkPhysicalDeviceProperties props{};
VkPhysicalDeviceProperties2 props2{};
int memory_props{};
VkPhysicalDeviceMemoryProperties2 memory_props2{};
int features{};
VkPhysicalDeviceFeatures2 features2{};
int *dev = nullptr;
int enabled_features{};
int AppGpu_phys_device;
int AppGpu_inst;
AppGpu() : inst(AppGpu_inst), id() {
api_version = make_vulkan_version();
props2.sType = memory_props2.sType = features2.sType =
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR;
}
};
main() { AppGpu(); }
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 --- Comment #5 from Martin Liška --- (In reply to David Binderman from comment #4) > Reduced C++ source code, after a pretty hefty four hours of reduction, is Heh, my reduction has just finished as well, resulting in the same source code as yours.
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C4 : virtual C2, C1 {};
struct C5 : virtual C4, C1 {};
struct C9 : C5 {};
void
foo (C9 *p)
{
__builtin_clear_padding (p);
}
ICEs too, so it isn't -ftrivial-auto-var-init= bug but __builtin_clear_padding
bug that started likely with r11-5196-g1bea0d0aa5936cb36b6f86f721ca03c1a1bb601d
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 --- Comment #2 from Martin Liška --- > ICEs too, so it isn't -ftrivial-auto-var-init= bug but > __builtin_clear_padding bug that started likely with > r11-5196-g1bea0d0aa5936cb36b6f86f721ca03c1a1bb601d Oh, interesting..
[Bug ipa/102557] [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access) since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102557 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- I'm not familiar enough with the code, leaving to Honza.
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #6 from Martin Liška --- I'm not familiar enough with the code, leaving to Honza.
[Bug tree-optimization/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102585 --- Comment #2 from Martin Liška --- Happens also with -fno-var-tracking-assignments -fno-var-tracking -c.
[Bug tree-optimization/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102585 --- Comment #3 from Martin Liška --- (In reply to Martin Liška from comment #2) > Happens also with -fno-var-tracking-assignments -fno-var-tracking -c. Err. With -fvar-tracking-assignments -fno-var-tracking.
[Bug ada/102073] gcc/ada/socket.c: 2 * missing return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 --- Comment #2 from CVS Commits --- The master branch has been updated by Pierre-Marie de Rodat : https://gcc.gnu.org/g:43a59d4dc88db02b7e19a1edf73db1b1f9d890b1 commit r12-4115-g43a59d4dc88db02b7e19a1edf73db1b1f9d890b1 Author: Arnaud Charlet Date: Thu Aug 26 09:21:22 2021 -0400 [Ada] PR ada/102073 gcc/ada/ PR ada/102073 * socket.c (__gnat_gethostbyaddr, __gnat_inet_pton): Add missing return statements.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #3 from Zdenek Sojka --- (In reply to Gabriel Ravier from comment #2) > Seems like they've all got identical code generation over here since GCC 7, > and the GCC 6 code generation is just very bad for bar (although GCC 7 also > changed bar and baz's code generation, which previously was as bar's is in > the description) I've got a different observation (using the branch HEADs, at -O3): gcc-6 - ICEs gcc-7, gcc-8, gcc-9 - the same code generated as in comment #1 gcc-10, gcc-11, gcc-12 - all functions are the same, bar() now has the same assembly as foo() and baz() - but is that the optimal form?
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad4a3c047f67d628b607bb6cf4791005affd1d83 commit r12-4138-gad4a3c047f67d628b607bb6cf4791005affd1d83 Author: Richard Biener Date: Mon Oct 4 10:02:39 2021 +0200 middle-end/102587 - avoid auto-init for VLA vectors This avoids ICEing for VLA vector auto-init by not initializing. 2021-10-04 Richard Biener PR middle-end/102587 * internal-fn.c (expand_DEFERRED_INIT): Guard register initialization path an avoid initializing VLA registers with it. * gcc.target/aarch64/sve/pr102587-1.c: New testcase. * gcc.target/aarch64/sve/pr102587-2.c: Likewise.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #4 from Gabriel Ravier --- That's a bit odd, really - I'm just using the latest released sub-versions of each of these (except for GCC 6 since I only have access to it through Godbolt which doesn't have GCC 6.5), i.e. GCC 6.4, 7.5, 8.5, 9.4, 10.3, 11.2 and trunk, I wouldn't expect it to impact this stuff that much. Though I do realize now I had messed up my comment slightly: when saying "GCC 7 also changed bar and baz's code generation" I meant "foo and baz's code generation".
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 --- Comment #3 from Richard Biener --- The ICE is fixed, but VLA registers are uninitialized.
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- .
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #21 from Richard Biener ---
Reduced testcase:
int
qy (void)
{
int tw = 4;
int fb[tw];
return fb[2];
}
[Bug target/102588] New: ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588
Bug ID: 102588
Summary: ICE: in smallest_mode_for_size, at stor-layout.c:356
when building openorienteering-mapper
Product: gcc
Version: 10.3.0
URL: https://buildd.debian.org/status/fetch.php?pkg=openori
enteering-mapper&arch=sparc64&ver=0.9.5-1&stamp=163312
0814&raw=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
Target Milestone: ---
Target: sparc64-*-*-*
Trying to build openorienteering-mapper on sparc64 fails on Debian unstable
with:
[ 68%] Building CXX object
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o
cd /<>/obj-sparc64-linux-gnu/src && /usr/bin/c++
-DMAPPER_BIG_ENDIAN -DMAPPER_COMMON_LIB -DMAPPER_USE_GDAL
-DMAPPER_USE_NMEA_POSITION_PLUGIN -DMAPPER_USE_POWERSHELL_POSITION_PLUGIN
-DMAPPER_USE_SENSORS -DNDEBUG -DQT_CONCURRENT_LIB -DQT_CORE_LIB
-DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG
-DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT -DQT_PRINTSUPPORT_LIB
-DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DSCALING_ICON_ENGINE_PLUGIN -DUNICODE
-DWITH_COVE -D_USE_MATH_DEFINES
-I/<>/obj-sparc64-linux-gnu/src/Mapper_Common_autogen/include
-I/<>/src -I/<>/3rd-party/cove
-I/<>/obj-sparc64-linux-gnu/src -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2/QtCore -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2/QtGui -isystem
/usr/include/polyclipping -isystem /usr/include/sparc64-linux-gnu/qt5 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore -isystem
/usr/lib/sparc64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/sparc64-linux-gnu/qt5/QtConcurrent -isystem
/<>/src/printsupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtNetwork -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wpedantic
-Wextra -O3 -DNDEBUG -fPIC -std=gnu++14 -MD -MT
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -MF
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o.d -o
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -c
/<>/src/tools/edit_line_tool.cpp
during RTL pass: expand
In file included from /<>/src/tools/cut_tool.h:34,
from /<>/src/tools/cut_tool.cpp:22:
/<>/src/core/objects/object.h: In member function
‘OpenOrienteering::ObjectPathCoord
OpenOrienteering::CutTool::findEditPoint(const OpenOrienteering::MapCoordF&,
int, int) const’:
/<>/src/core/objects/object.h:1275:50: internal compiler error: in
smallest_mode_for_size, at stor-layout.c:356
1275 | : PathCoord { object->findPathCoordForIndex(index) }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Attaching preprocessed source.
Full log in:
https://buildd.debian.org/status/fetch.php?pkg=openorienteering-mapper&arch=sparc64&ver=0.9.5-1&stamp=1633120814&raw=0
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 51545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51545&action=edit Preprocessed source.
[Bug ada/102073] gcc/ada/socket.c: 2 * missing return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 Arnaud Charlet changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Arnaud Charlet --- .
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 102073, which changed state. Bug 102073 Summary: gcc/ada/socket.c: 2 * missing return https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102073 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #22 from Richard Biener --- Hmm, my proposed patch seems to work. I've adjusted it to not regress previously correctly handled cases and will test it fully.
[Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589 Bug ID: 102589 Summary: spaceship: std::map does not use specialised operator< for value Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gjasny at googlemail dot com Target Milestone: --- Created attachment 51546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51546&action=edit Testcase Hello, I stumbled over this issue when porting a code base from C++17 to C++20. Both: GNU libstdc++ as well as MSVC STL show the unexpected behaviour. Libc++ seems to do the right thing. Describe the bug Compiling the test case with C++17 works as expected whereas compiling it with C++20 makes the test assumption fail. The reason is that for C++ 20 builds the specialised operator<(const FooPtr& left, const FooPtr& right) is not picked up. Instead the default operator<=> for std::shared_ptr is used which only compares the raw pointers and not the content they point to. Expected behavior I'd expect that with C++17 and C++20 the STL would prefer the specialised operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=> one. That would also align with the strong backwards compatibilities C++ strives for. GCC version g++-11 (Debian 11.2.0-8) 11.2.0 Links Microsoft STL Issue: https://github.com/microsoft/STL/issues/2234 Debian Sid based reproducer: https://github.com/gjasny/map-spaceship-testcase Godbolt: https://godbolt.org/z/objPnjo84 Thanks, Gregor
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Confirmed, reducing that right now..
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
The GIMPLE IL is now using BIT_INSERT_EXPRs consistently for all cases and
combine does
Trying 8 -> 11:
8: {r90:SI=r89:SI<<0x1;clobber flags:CC;}
REG_DEAD r89:SI
REG_UNUSED flags:CC
11: strict_low_part(r92:V4QI#0)=r90:SI#0
REG_DEAD r90:SI
Failed to match this instruction:
(set (strict_low_part (subreg:QI (reg:V4QI 92 [ v ]) 0))
(ashift:QI (subreg:QI (reg:SI 89 [ v ]) 0)
(const_int 1 [0x1])))
where it fails to try (add:QI (subreg...) (subreg...)) instead of the shift by
1.
Not sure whether targets should have a special-case pattern here or whether
that's for combine to un-canonicalize it?
[Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- (In reply to Gregor Jasny from comment #0) > I stumbled over this issue when porting a code base from C++17 to C++20. > Both: GNU libstdc++ as well as MSVC STL show the unexpected behaviour. > Libc++ seems to do the right thing. Probably because it doesn't implement <=> support in the standard library at all. Libstdc++ and MSVC do. > Describe the bug > > Compiling the test case with C++17 works as expected whereas compiling it > with C++20 makes the test assumption fail. The assumption is wrong. > The reason is that for C++ 20 builds the specialised operator<(const FooPtr& > left, const FooPtr& right) is not picked up. Instead the default operator<=> > for std::shared_ptr is used which only compares the raw pointers and not the > content they point to. This is the correct behaviour. > Expected behavior > > I'd expect that with C++17 and C++20 the STL would prefer the specialised > operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=> > one. That would also align with the strong backwards compatibilities C++ > strives for. No. Comparing the two std::map objects has to use <=> because there is no < for std::map in C++20, so you get a synthesized < from the <=> for std::map. And obviously <=> for std::map is going to try to use <=> for its elements. So it uses <=> for std::pair which uses <=> for its members, so it uses <=> for std::shared_ptr. The only < comparison that happens is the one for std::map, after that everything is a three-way comparison.
[Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589
--- Comment #2 from Jonathan Wakely ---
Overloading < for shared_ptr like that is a bit questionable anyway.
You can use std::lexicographical_compare with a custom comparison function if
you want the custom less-than behaviour:
if (std::lexicographical_compare(largerMap.begin(), largerMap.end(),
smallerMap.begin(), smallerMap.end(), [](const auto& l, const auto& r) { return
l.first < r.first || (l.first == r.first && *l.second < *r.second); }))
This does the same thing in C++17 and C++20.
[Bug c++/102590] New: Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590
Bug ID: 102590
Summary: Templated operations on variables in structured
binding don't work when templated functions/lambdas
require type deduction
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1997.rajatjain at gmail dot com
Target Milestone: ---
Foreach loops written with a structured-binding declaration error out if any of
the captured types contains a template member-function which is used inside the
loop.
This only happens if such a loop is placed inside a templated lambda/function.
A minimal example of the above is:
struct Foo
{
template
T get() const
{
return static_cast(0);
}
};
template
void error_func(T elem)
{
std::array, 1> arr;
for(const auto& [_, val] : arr)
{
val.get(); // Error here
}
}
The error disappears if T is replaced with any concrete type. It also
disappears if instead of structured bindings, a tuple is used with auto type
specifier.
The above code also works if one writes:
const auto& [_, val] = arr[0];
val.get();
Compilation flags: -std=c++17
Reported error:
test.cpp:19:17: error: expected primary-expression before 'int'
val.get();
^~~
test.cpp:19:17: error: expected ';' before 'int'
val.get();
^~~
;
[Bug c++/102590] Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590 --- Comment #1 from Andrew Pinski --- My bet is gcc mistaken it for being a dependent type which meaning you can use the template keyword to workaround the issue. Also gcc 8.x series is over 3 years old so this might be fixed already in a newer version of gcc.
[Bug c++/102319] ICE in cpp_atomic_builtins, at c-family/c-cppbuiltin.c:746 since r12-3495-g76b75018b3d053a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102319 --- Comment #3 from Martin Liška --- @Jason: May I please ping this issue. It's still not addressed after g:4320a4b717dcccddf230d0b944bfc5a7ae282508.
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #7 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:fa3ccf8bfe9940b439d6cc2c38ee8da134b0ff2d commit r12-4139-gfa3ccf8bfe9940b439d6cc2c38ee8da134b0ff2d Author: Aldy Hernandez Date: Sun Oct 3 19:42:10 2021 +0200 Remove static marker for range in alloca pass. The m_ranges[] field in int_range are trees, so they live in GC space. Since invalid_range is static, it must be marked with GTY magic. However, calculating invalid_range is not particularly slow, or on a critical path, so we can just put it in local scope and recalculate every time. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/102560 * gimple-ssa-warn-alloca.c (alloca_call_type): Remove static marker for invalid_range. gcc/testsuite/ChangeLog: * g++.dg/Walloca2.C: New test.
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez --- fixed
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> The GIMPLE IL is now using BIT_INSERT_EXPRs consistently for all cases and
> combine does
>
> Trying 8 -> 11:
> 8: {r90:SI=r89:SI<<0x1;clobber flags:CC;}
> REG_DEAD r89:SI
> REG_UNUSED flags:CC
>11: strict_low_part(r92:V4QI#0)=r90:SI#0
> REG_DEAD r90:SI
> Failed to match this instruction:
> (set (strict_low_part (subreg:QI (reg:V4QI 92 [ v ]) 0))
> (ashift:QI (subreg:QI (reg:SI 89 [ v ]) 0)
> (const_int 1 [0x1])))
>
> where it fails to try (add:QI (subreg...) (subreg...)) instead of the shift
> by 1.
>
> Not sure whether targets should have a special-case pattern here or whether
> that's for combine to un-canonicalize it?
We do have this pattern in i386.md, but please see the FIXME:
(define_insn "*ashl3_1_slp"
[(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+"))
(ashift:SWI12 (match_operand:SWI12 1 "register_operand" "0")
(match_operand:QI 2 "nonmemory_operand" "cI")))
(clobber (reg:CC FLAGS_REG))]
"(!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun))
/* FIXME: without this LRA can't reload this pattern, see PR82524. */
&& rtx_equal_p (operands[0], operands[1])"
[Bug c++/102590] Templated operations on variables in structured binding don't work when templated functions/lambdas require type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102590 --- Comment #2 from Rajat Jain <1997.rajatjain at gmail dot com> --- Yeah .template works as well. This is in the latest release too. I wasn't sure whether I should write the oldest version that this is in (since other 8.x releases would need a patch as well), or the latest. Let me change that.
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, seems the C9 type is 32-byte, with 8-byte virtual table pointers at offset 0 and 16 bytes (and the rest is padding), C5 is 24-byte with virtual table pointers at offsets 0 and 8 bytes (and the rest is padding), C4 is 16-byte with virtual table pointers at offset 0 (and the rest is padding). But what the middle-end sees is that there is a FIELD_DECL with C5 type at offset 0 with size 9 bytes and then a FIELD_DECL with C4 type at offset 16 with size 9 bytes. The __builtin_clear_padding handling code when called on a FIELD_DECL with smaller DECL_SIZE_UNIT than TYPE_SIZE_UNIT is able to ignore fields that are wholy beyond the size and also the default behavior is that everything is padding until proven otherwise, so for padding bytes nothing changes. The reason for the ICE is that the first FIELD_DECL with C5 type says 9 bytes and the type has 8 byte, 8 byte and 1 byte fields (2 virtual table pointers and one padding byte). So, in that case it is unclear what the code should do. Shall it treat the fields that partially fall into the range and partially don't as padding (ignore them), or is there no way to do this using the TREE_TYPE of FIELD_DECLs that the middle-end sees and one needs to use some other types (I vaguely remember the C++ FE has some variant RECORD_TYPEs for the virtual bases that actually reflect what is present and where, but I have no idea if that is visible to the middle-end somewhere)?
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > We get:
> > .L3:
> > ld1bz0.b, p0/z, [x1, x3]
> > movprfx z2, z0
> > and z2.b, z2.b, #0xc0
> > neg z1.b, p1/m, z0.b ;;; THIS
> > cmpeq p2.b, p1/z, z2.b, #0
> > sel z0.b, p2, z0.b, z1.b AND THIS
> > st1bz0.b, p0, [x0, x3]
> > incbx3
> > whilelo p0.b, w3, w2
> > b.any .L3
> >
> > The two instructions marked should be combined.
>
> The problem is that it isn't a straight combination of the
> NEG and SEL, because the condition is the inverse of the one
> that we want for predication.
IIUC, sel is redundant and we could generate following code
instead for the inner loop ?
ld1bz0.b, p0/z, [x1, x2]
movprfx z2, z0
and z2.b, z2.b, #0xc0
cmpne p2.b, p1/z, z2.b, #0
neg z0.b, p2/m, z0.b
st1bz0.b, p0, [x0, x3]
incbx3
whilelo p0.b, w3, w2
b.any .L3
>
> This is one of the things that the IFN_COND_* functions were
> designed to fix. We should probably add unary versions of those.
The input to isel pass is:
vect__3.11_39 = .MASK_LOAD (_22, 8B, loop_mask_38);
vect_t1_15.12_41 = vect__3.11_39 & { 192, ... };
vect_t_12.13_42 = -vect__3.11_39;
_44 = vect_t1_15.12_41 == { 0, ... };
vect_iftmp.14_45 = VEC_COND_EXPR <_44, vect__3.11_39, vect_t_12.13_42>;
where vect__3.11_39 and vect_t_12.13_42 are negatives of each other.
I suppose in isel pass if we come across vec_cond_expr of the form:
op2 = vec_cond_expr
then we could lower it to a new internal function say IFN_COND_NEG.
IFN_COND_NEG could use a new optab say cond_neg_optab to expand it to:
movprfx op2, op1
set predicate according to inverted cond
op2 = predicate/m neg op2
Does this look reasonable ?
Thanks,
Prathamesh
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #23 from Richard Biener --- I do have to check the result before this fix attempt but at least with it the overall testsuite state isn't so great. You can do make check RUNTESTFLAGS="--target_board=unix/-ftrivial-auto-var-init=zer" to check all of the testsuite (besides Ada ACATS which doesn't honor RUNTESTFLAGS, you have to edit gcc/testsuite/ada/acats/run_all.sh and amend the toplevel 'gccflags' variable there. I see ICEs and runfails there. I'll file a separate bug about these (some may be due to the DECL_VALUE_EXPR thing).
[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 --- Comment #4 from Jakub Jelinek --- Seems in the C++ FE it is CLASSTYPE_AS_BASE, so shall clear_padding_type for FIELD_DECLs where DECL_SIZE_UNIT (fld) is smaller than TYPE_SIZE_UNIT (TREE_TYPE (fld)) call some new langhook which for C++ would return CLASSTYPE_AS_BASE? All gimple_fold_builtin calls for BUILT_IN_CLEAR_PADDING should fold the call away, so I'd hope that all the folding happens before IPA.
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #8 from Andrew Stubbs --- Did you get the C version to return anything other than "-1"? (The expected result is "2".) I'm still trying to determine if the device is compatible, but the mapping problem looks like a different issue. Your code works fine on my device using a somewhat more recent GCC build. (I can't install that exact toolchain right now.)
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Resolution|FIXED |--- Status|RESOLVED|ASSIGNED Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- Reopening because I don't think we can simply ignore the option like this, at least not without a warning. Hope to fix sometime in stage 3.
[Bug target/102591] New: Failure to optimize search for value in vector-sized area to use SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591
Bug ID: 102591
Summary: Failure to optimize search for value in vector-sized
area to use SIMD
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool match8(char *tpl)
{
int found = 0;
for (int at = 0; at < 16; at++)
if (tpl[at] == 0)
found = 1;
return found;
}
This function can be greatly optimized by using SIMD. It can be optimized to
something like this:
typedef char v16i8 __attribute__((vector_size(16)));
bool match8v2(char *tpl)
{
v16i8 values;
__builtin_memcpy(&values, tpl, 16);
v16i8 compared = (values == 0);
return _mm_movemask_epi8((__m128i)compared) != 0;
}
This optimization is done by LLVM, but not by GCC.
PS: I've marked this as an x86 bug, but only because I could not find a
portable way of expressing `_mm_movemask_epi8((__m128i)compared)`, I would
assume other architectures have similar ways of expressing the same thing
cheaply.
(For example, Altivec should be able to implement that operation with a
`vec_extract(vec_vbpermq((__vector unsigned char)compared, perm), 1)` with
`perm` looking like this: `{120, 112, 104, 96, 88, 80, 72, 64, 56, 48, 40, 32,
24, 16, 8, 0}` and the 1 replaced with 14 on big-endian)
[Bug libstdc++/100444] std::random_device isn't random on AMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444 --- Comment #14 from Jonathan Wakely --- Created attachment 51547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51547&action=edit Proposed patch
[Bug c++/102482] Winit-list-lifetime false positive for temporaries with std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #8 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580771.html
[Bug libstdc++/102592] New: heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
Bug ID: 102592
Summary: heap-use-after-free when constructing
std::filesystem::path from iterator pair
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dean.gcc.bugzilla at gmail dot com
Target Milestone: ---
The std::filesystem::path constructor that takes an iterator pair produces a
heap-use-after-free error (address sanitizer) in case the iterators are
non-contiguous and value_type != char.
Full self-contained reproducible example on Compiler Explorer:
https://godbolt.org/z/3nxqq5Ef8 I've also included the reproduction code and
error below for completeness.
Affected versions: 11.x, trunk
Not affected: 10.x
As far as I've been able to track this in the std::filesystem::path
constructor, for the case of non-contiguous, non-char iterators, a temporary
container is created and then assigned to a std::string_view. However that temp
container has a shorter lifetime than the std::string_view.
The code:
#include
namespace fs = std::filesystem;
fs::path to_path(std::string_view sv) {
struct AsU8 {
std::string_view::const_iterator it;
using iterator_category = std::forward_iterator_tag;
using difference_type = std::ptrdiff_t;
using value_type = char8_t;
using reference = const value_type&;
using pointer = const value_type*;
char8_t operator*() const { return static_cast(*it); }
AsU8& operator++() { return ++it, *this; }
bool operator==(const AsU8&) const = default;
};
return {AsU8{sv.begin()}, AsU8{sv.end()}};
}
int main() {
return
to_path("/long/path/to/a/file/to/avoid/small/string/opt").string().size();
}
=1==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400010 at
pc 0x7fed85f999c0 bp 0x7ffdddc9ccc0 sp 0x7ffdddc9c470
READ of size 46 at 0x60400010 thread T0
#0 0x7fed85f999bf in __interceptor_memcpy
(/opt/compiler-explorer/gcc-11.2.0/lib64/libasan.so.6+0x3c9bf)
#1 0x4039e5 in std::char_traits::copy(char*, char const*, unsigned
long)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/char_traits.h:409
#2 0x405214 in std::__cxx11::basic_string,
std::allocator >::_S_copy(char*, char const*, unsigned long)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:359
#3 0x4058f1 in std::__cxx11::basic_string,
std::allocator >::_S_copy_chars(char*, char const*, char const*)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:406
#4 0x405109 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*, std::forward_iterator_tag)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.tcc:225
#5 0x40578b in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:255
#6 0x404a8e in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:274
#7 0x404119 in std::__cxx11::basic_string,
std::allocator >::basic_string(char const*, unsigned long,
std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:521
#8 0x404e66 in std::__cxx11::basic_string,
std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >::__sv_wrapper,
std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:154
#9 0x404373 in std::__cxx11::basic_string,
std::allocator >::basic_string >, void>(std::basic_string_view > const&, std::allocator const&)
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/basic_string.h:664
#10 0x402c63 in path
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/fs_path.h:292
#11 0x4024ae in to_path[abi:cxx11](std::basic_string_view >) /app/example.cpp:19
#12 0x40265c in main /app/example.cpp:23
#13 0x7fed85a140b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#14 0x40226d in _start (/app/output.s+0x40226d)
[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
Jonathan Wakely changed:
What|Removed |Added
Summary|heap-use-after-free when|[11/12 Regression]
|constructing|heap-use-after-free when
|std::filesystem::path from |constructing
|iterator pair |std::filesystem::path from
||iterator pair
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords||wrong-code
Last reconfirmed||2021-10-04
Known to work||10.3.1
Status|UNCONFIRMED |ASSIGNED
Known to fail||11.2.1, 12.0
--- Comment #1 from Jonathan Wakely ---
The problem is the last line of this function:
template
static auto
_S_convert(const _Tp& __str)
{
if constexpr (is_same_v<_Tp, string_type>)
return __str;
else if constexpr (is_same_v<_Tp, basic_string_view>)
return __str;
else if constexpr (is_same_v)
return basic_string_view(__str.data(), __str.size());
else
return _S_convert(__str.data(), __str.data() + __str.size());
}
That returns a basic_string_view referring to the contents of __str,
but that is an rvalue basic_string that goes out of scope before the
result is used.
[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592 Jonathan Wakely changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3
[Bug ipa/102554] [10/11 Regression] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554 John S changed: What|Removed |Added Known to fail|12.0| --- Comment #3 from John S --- (In reply to Martin Liška from comment #2) > (In reply to Richard Biener from comment #1) > > I suspect that the optimize() attribute resets the param value to its > > default. > > Yes, it's fixed on master with g:r12-4038-g6de9f0c13b27c343. > > > > > Martin - can you investigate / bisect? > > Sure, it started with r10-4944-g1e83bd7003e03160. > > I tend closing that as fixed, what do you think Richi? I can confirm I am seeing g:r12-4038-g6de9f0c13b27c343 resolve the issue. Is it possible to get this applied into the upcoming 10.4, 11.3 releases? It's making upgrading to 10.x / 11.x versions challenging in certain latency sensitive production environments.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #24 from Jakub Jelinek --- I wanted to look at #c20, but at least my i9-7960X for e.g. lock; btsl $65, var acts the same as lock; btsl $1, var rather than lock; btsl $1, var+8, so maybe #c20 is not possible.
[Bug tree-optimization/102570] missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:55a3be2f5255d69e740d61b2c5aaba1ccbc643b8 commit r12-4143-g55a3be2f5255d69e740d61b2c5aaba1ccbc643b8 Author: Richard Biener Date: Mon Oct 4 10:57:45 2021 +0200 tree-optimization/102570 - teach VN about internal functions We're now using internal functions for a lot of stuff but there's still missing VN support out of laziness. The following instantiates support and adds testcases for FRE and PRE (hoisting). 2021-10-04 Richard Biener PR tree-optimization/102570 * tree-ssa-sccvn.h (vn_reference_op_struct): Document we are using clique for the internal function code. * tree-ssa-sccvn.c (vn_reference_op_eq): Compare the internal function code. (print_vn_reference_ops): Print the internal function code. (vn_reference_op_compute_hash): Hash it. (copy_reference_ops_from_call): Record it. (visit_stmt): Remove the restriction around internal function calls. (fully_constant_vn_reference_p): Use fold_const_call and handle internal functions. (vn_reference_eq): Compare call return types. * tree-ssa-pre.c (create_expression_by_pieces): Handle generating calls to internal functions. (compute_avail): Remove the restriction around internal function calls. * gcc.dg/tree-ssa/ssa-fre-96.c: New testcase. * gcc.dg/tree-ssa/ssa-pre-33.c: Likewise.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Richard Biener --- commit 7e0c0500808d58bca5b8e23cbd474022c32234e4 (origin/master, origin/HEAD) Author: Richard Biener Date: Mon Oct 4 11:34:27 2021 +0200 middle-end/102285 - refine .DEFERRED_INIT expansion This refines the way we figure whether we are facing a register that cannot be initialized by emitting a memset away from inspecting expanded RTL of the LHS to using the predicates expand_assignment is using to detect decls or MEM_REFs with non-memory DECL_RTL. 2021-10-04 Richard Biener * expr.h (non_mem_decl_p): Declare. (mem_ref_refers_to_non_mem_p): Likewise. * expr.c (non_mem_decl_p): Export. (mem_ref_refers_to_non_mem_p): Likewise. * internal-fn.c (expand_DEFERRED_INIT): Do not expand the LHS but check the base with mem_ref_refers_to_non_mem_p and non_mem_decl_p. * c-c++-common/pr102285.c: New testcase.
[Bug tree-optimization/102570] missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588
--- Comment #3 from Martin Liška ---
Reduced test-case:
namespace std {
typedef int size_t;
template class vector {
public:
typedef size_t size_type;
};
} // namespace std
typedef int quint32;
typedef double qreal;
class QPointF {
qreal yp;
};
namespace OpenOrienteering {
class MapCoord;
class MapCoordF : QPointF {};
typedef std::vector MapCoordVector;
class PathCoord {
public:
using size_type = quint32;
using length_type = float;
using param_type = MapCoordF;
size_type index;
param_type param;
length_type clen;
};
class PathObject {
public:
PathCoord findPathCoordForIndex(MapCoordVector::size_type);
};
struct ObjectPathCoord : PathCoord {
ObjectPathCoord(PathObject *, size_type);
};
ObjectPathCoord::ObjectPathCoord(PathObject *object, size_type)
: PathCoord{object->findPathCoordForIndex(index)} {}
} // namespace OpenOrienteering
[Bug ipa/102554] [10/11 Regression] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554 --- Comment #4 from Martin Liška --- > I can confirm I am seeing g:r12-4038-g6de9f0c13b27c343 resolve the issue. > > Is it possible to get this applied into the upcoming 10.4, 11.3 releases? Sorry, but it won't be possible. It's a pretty significant change that can potentially break some software build. That's why it will target 12.1 release only. > It's making upgrading to 10.x / 11.x versions challenging in certain latency > sensitive production environments.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 --- Comment #7 from Thiago Macieira --- (In reply to H.J. Lu from comment #5) > Created attachment 51536 [details] > A patch > > Please try this. Give me an hour (will try v2).
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c86a16b07b76604a8e3d556f135babab80e2b747 commit r12-4146-gc86a16b07b76604a8e3d556f135babab80e2b747 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line.
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #9 from Richard Biener --- Fixed now.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #8 from Thiago Macieira ---
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic &i)
{
return i.fetch_or(1, std::memory_order_relaxed) & 1;
}
$ ~/dev/gcc/bin/gcc -S -o - -O2 /tmp/test.cpp
.file "test.cpp"
.text
.p2align 4
.globl _Z4tbitRSt6atomicIiE
.type _Z4tbitRSt6atomicIiE, @function
_Z4tbitRSt6atomicIiE:
.LFB339:
.cfi_startproc
lock btsl $0, (%rdi)
setc%al
ret
.cfi_endproc
.LFE339:
.size _Z4tbitRSt6atomicIiE, .-_Z4tbitRSt6atomicIiE
.ident "GCC: (GNU) 12.0.0 20211004 (experimental)"
.section.note.GNU-stack,"",@progbits
+1
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #7 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> Not sure whether targets should have a special-case pattern here or whether
> that's for combine to un-canonicalize it?
Is the shift defined anywhere as the canonical form?
We already get a shift at expand time, for e.g.
long f(long a) { return a+a; }
I cannot find the code that does this easily, it is quite a maze :-) There
is code for changing a multiplication by a power of two (which we have in
Gimple already) into a shift, but then there should be something changing
the addition with self into a multiplication, and I cannot find that either.
Combine should absolutely not un-canonicalise it. It could try multiple
ways of writing this, but is it important enough to allow this, to justify
the (potential) combinatorial explosion this causes?
If we want combine to try many ways of writing something (not a bad idea an
sich btw, I support it), we need ways to battle such an explosion, and esp.
to make the amount of garbage RTL created manageable (it is not, currently).
Currently combine has to create GC'ed RTL to recog() it. Maybe we could
have some "GC stuff created between points X and Y" interface?
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #9 from Thiago Macieira ---
Looks like it doesn't work for the sign bit.
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic &i)
{
return i.fetch_or(CONSTANT, std::memory_order_relaxed) & CONSTANT;
}
$ ~/dev/gcc/bin/gcc -DCONSTANT='(1<<30)' -S -o - -O2 /tmp/test.cpp | sed -n
'/startproc/,/endproc/p'
.cfi_startproc
lock btsl $30, (%rdi)
setc%al
ret
.cfi_endproc
$ ~/dev/gcc/bin/gcc -DCONSTANT='(1<<31)' -S -o - -O2 /tmp/test.cpp | sed -n
'/startproc/,/endproc/p'
.cfi_startproc
movl(%rdi), %eax
.L2:
movl%eax, %ecx
movl%eax, %edx
orl $-2147483648, %ecx
lock cmpxchgl %ecx, (%rdi)
jne .L2
shrl$31, %edx
movl%edx, %eax
ret
.cfi_endproc
Changing to std::atomic makes no difference.
[Bug c++/97573] Implement C++20 [depr.arith.conv.enum]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97573 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2dda00b734888d3b53ac91160083b5c6cd5ca5c8 commit r12-4148-g2dda00b734888d3b53ac91160083b5c6cd5ca5c8 Author: Marek Polacek Date: Wed Sep 29 11:45:24 2021 -0400 c-family: Implement -Warray-compare [PR97573] This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Warray-compare. Since the code in question is dubious (the comparison doesn't actually compare the array elements), I've added this warning for C too, and enabled it in all C++ modes. PR c++/97573 gcc/c-family/ChangeLog: * c-common.h (do_warn_array_compare): Declare. * c-warn.c (do_warn_array_compare): New. * c.opt (Warray-compare): New option. gcc/c/ChangeLog: * c-typeck.c (parser_build_binary_op): Call do_warn_array_compare. gcc/cp/ChangeLog: * typeck.c (cp_build_binary_op): Call do_warn_array_compare. gcc/ChangeLog: * doc/invoke.texi: Document -Warray-compare. gcc/testsuite/ChangeLog: * c-c++-common/Warray-compare-1.c: New test. * c-c++-common/Warray-compare-2.c: New test.
[Bug c++/97573] Implement C++20 [depr.arith.conv.enum]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97573 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #9 from miko at predsci dot com --- Both the C and Fortran versions returned "-1".
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dd6098467ff83351948435efc826e1c4b4b27f99 commit r11-9068-gdd6098467ff83351948435efc826e1c4b4b27f99 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:41e21afc427ffe4a320616d4a454144b1e93a670 commit r10-10167-g41e21afc427ffe4a320616d4a454144b1e93a670 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:a5b9ac0301c850a02d045b5630aa08b4ceab20c1 commit r9-9756-ga5b9ac0301c850a02d045b5630aa08b4ceab20c1 Author: Iain Buclaw Date: Sun Oct 3 16:02:24 2021 +0200 d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library Adds handling of `-static-libstc++' in the gdc driver, so that libstdc++ is appropriately linked if libstdc++ is either needed or seen on the command-line. PR d/102574 gcc/d/ChangeLog: * d-spec.cc (lang_specific_driver): Link libstdc++ statically if -static-libstdc++ was given on command-line. (cherry picked from commit c86a16b07b76604a8e3d556f135babab80e2b747)
[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
--- Comment #6 from qinzhao at gcc dot gnu.org ---
with the committed patch, this testing case still failed but in a later rtl
stage:
qinzhao@gcc116:~/Bugs/102587$ sh t
/home/qinzhao/Install/latest/bin/gcc -ftrivial-auto-var-init=zero t.c -S
during RTL pass: pro_and_epilogue
t.c: In function ‘foo’:
t.c:1:33: internal compiler error: Segmentation fault
1 | void foo() { __SVFloat64_t f64; }
| ^
0xe18fab crash_signal
../../latest_gcc_git/gcc/toplev.c:331
0x122ed20 aarch64_add_offset
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:5042
0x123044f aarch64_sub_sp
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:5225
0x123044f aarch64_allocate_and_probe_stack_space
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:8502
0x1230cfb aarch64_expand_prologue()
../../latest_gcc_git/gcc/config/aarch64/aarch64.c:8841
0x169fb63 gen_prologue()
../../latest_gcc_git/gcc/config/aarch64/aarch64.md:853
0x1226d17 target_gen_prologue
../../latest_gcc_git/gcc/config/aarch64/aarch64.md:7448
0xa9495f make_prologue_seq
../../latest_gcc_git/gcc/function.c:5825
0xa94b8b thread_prologue_and_epilogue_insns()
../../latest_gcc_git/gcc/function.c:6043
0xa95293 rest_of_handle_thread_prologue_and_epilogue
../../latest_gcc_git/gcc/function.c:6534
0xa95293 execute
../../latest_gcc_git/gcc/function.c:6610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug d/102574] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102574 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fix committed.
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 --- Comment #6 from Andrew Macleod --- > > > It removes a > > relationship between c_10 and _2. The reason ranger no longer can fold _2 > > == 0 > > is because the sequence is now: > > > > 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] > > > > We do not find _2 is non-zero on the outgoing edge because _2 is not > > related to > > the calculation in the condition. (ie c_10 no longer has a dependency on > > _2) > > > > We do recalculate _2 based on the outgoing range of a.0_1, but with it > > being a > > 64 bit value and _2 being 32 bits, we only know the outgoing range of a.0_1 > > is > > non-zero.. we dont track any of the upper bits... > > 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] > > And when we recalculate _2 using that value, we still get varying because > > 0x in not zero, but can still produce a zero in _2. > > > > The problem is that the condition c_10 != 0 no longer related to the value > > of > > _2 in the IL... so ranger never sees it. and we cant represent the 2^16 > > subranges that end in [1,0x]. > > > > Before that transformation, > > _2 = (unsigned int) a.0_1; > >b = _2; > > c_10 = (long int) _2; > > The relationship is obvious, and ranger would relate the c_10 != 0 to _2 no > > problem. > > I see - too bad. Note the transform made the dependence chain of _6 > one instruction shorter without increasing the number of instructions > so it's a profitable transform. > > Btw, the relation is still there but only indirectly via a.0_1. The > old (E)VRP had this find_asserts(?) that produced assertions based > on the definitions - sth that now range-ops does(?), so it would > eventually have built assertions for a.0_1 for both conditions and > allow relations based on that? I can't seem to find my way around > the VRP code now - pieces moved all over the place and so my mind > fails me on the searching task :/ We do know that a.0_1 is non-zero on that edge: 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] the problem is that we can't currently represent that the bitmask operation causes all patterns ending in 0x to not occur.. we just leave it at ~[0,0]. which isn't sufficient for this use case. we don't currently track any equivalences between values of different precision.. (even though ranger once did). Handling it as a general equivalence was fraught with issues. We might be able to add a new equivalence class "slice" or something.. I had considered it but hadn't seen a great need case. This would make _6 a 32 bit slice of a.0_1 with range [1, 0x]. Then when we are querying for the cast _2 = (unsigned int) a.0_1; we could also query the 32 bit equivalence slices of a.0_1, find _6, and get the outgoing range of [1,0x].. and apply that value. It would probably resolve an entire class of things where we don't recognize an equivalence between a cast and a bitmask of equivalent precision. This would also mean the reverse would apply.. ie if we instead branched on _2 != 0 we would also understand that _6 will be non-zero.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #22)
> Hmm, my proposed patch seems to work. I've adjusted it to not regress
> previously correctly handled cases and will test it fully.
I guess the reason for it worked for you because you tested it after the patch
for 102587?
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
/* Expand this memset call. */
expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
}
- else
+ /* ??? Deal with poly-int sized registers. */
+ else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
{
/* If this variable is in a register, use expand_assignment might
generate better code. */
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
||bergner at gcc dot gnu.org,
||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Peter Bergner ---
I agree it is GCC's job to emit a ".machine CPU" directive that allows the
assembler to correctly assemble the code GCC generates. Your test case however
uses inline asm and GCC does not know that you are using the mfppr32 mnemonic.
The assembler code you write in an inline asm is basically a black box to the
compiler. It is therefor up to the programmer to ensure that either the
-mcpu=CPU GCC option that is being used (which emits".machine CPU" directive)
is enough to assemble the mnemonics in the inline asm or you have to emit them
in your inline asm. For the later, you can fix your test case like:
bergner@pike:~$ cat mfppr32.c
long f () {
long ppr;
asm volatile ("mfppr32 %0" : "=r"(ppr));
return ppr;
}
bergner@pike:~$ cat mfppr32-2.c
long f () {
long ppr;
asm volatile (".machine push\n\
.machine power7\n\
mfppr32 %0\n\
.machine pop" : "=r"(ppr));
return ppr;
}
bergner@pike:~$ gcc -c mfppr32.c
/tmp/ccSpp2V8.s: Assembler messages:
/tmp/ccSpp2V8.s:19: Error: unrecognized opcode: `mfppr32'
bergner@pike:~$ gcc -c mfppr32-2.c
bergner@pike:~$
Therefore, I'm not sure there is anything for GCC to do here.
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #2 from Paul Clarke --- GCC putting the base ".machine" directive at the beginning of the file makes any command-line use of "-many" (-Wa,-many) be ignored. Is that OK? "-many" is supposed to make those black boxes just work. This worked before recent changes to binutils/GCC. Is there any valid use of "-Wa,-many" now?
[Bug c++/102593] New: [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593
Bug ID: 102593
Summary: [10/11/12 Regression] ICE in
cp_oacc_check_attachments, at cp/semantics.c:6561
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20191215 and 20200105 :
$ cat z1.cc
template
void f ()
{
struct t { int a; };
#pragma acc data detach (t.a)
;
}
$ g++-12-20211003 -c z1.cc -fopenacc
z1.cc: In function 'void f()':
z1.cc:5:32: internal compiler error: Segmentation fault
5 | #pragma acc data detach (t.a)
|^
0xe17d4f crash_signal
../../gcc/toplev.c:331
0x8f6da6 cp_oacc_check_attachments
../../gcc/cp/semantics.c:6561
0x90842a finish_omp_clauses(tree_node*, c_omp_region_type)
../../gcc/cp/semantics.c:7850
0x897fb4 cp_parser_oacc_all_clauses
../../gcc/cp/parser.c:39710
0x8b3009 cp_parser_oacc_data
../../gcc/cp/parser.c:44231
0x8b3009 cp_parser_omp_construct
../../gcc/cp/parser.c:46870
0x8897b9 cp_parser_pragma
../../gcc/cp/parser.c:47594
0x8905b7 cp_parser_statement
../../gcc/cp/parser.c:12266
0x8913d4 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12722
0x89148f cp_parser_compound_statement
../../gcc/cp/parser.c:12671
0x8af888 cp_parser_function_body
../../gcc/cp/parser.c:24902
0x8af888 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24953
0x8afd36 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:31083
0x8b0c57 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30999
0x8b0c57 cp_parser_init_declarator
../../gcc/cp/parser.c:22436
0x8b35b6 cp_parser_single_declaration
../../gcc/cp/parser.c:31586
0x8b37d5 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:31151
0x8b3f9b cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:31417
0x8b3f9b cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:31436
0x8b61f9 cp_parser_declaration
../../gcc/cp/parser.c:14759
[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 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 51548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51548&action=edit gcc12-pr102548.patch Untested fix.
[Bug c++/102594] New: ICE in decay_conversion, at cp/typeck.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102594
Bug ID: 102594
Summary: ICE in decay_conversion, at cp/typeck.c:2311
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r8 :
$ cat z1.cc
struct s {
s() {}
};
s a[1][1];
auto [b](a);
$ g++-12-20211003 -c z1.cc
z1.cc:5:11: internal compiler error: Segmentation fault
5 | auto [b](a);
| ^
0xe17d4f crash_signal
../../gcc/toplev.c:331
0x92719a decay_conversion(tree_node*, int, bool)
../../gcc/cp/typeck.c:2311
0x80f80a build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../gcc/cp/init.c:4297
0x81012f build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../gcc/cp/init.c:4528
0x81062b build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1823
0x7ee8ed build_aggr_init_full_exprs
../../gcc/cp/decl.c:7048
0x7ee8ed check_initializer
../../gcc/cp/decl.c:7209
0x7efbb1 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:8211
0x88ecbc cp_parser_decomposition_declaration
../../gcc/cp/parser.c:15427
0x88ecbc cp_parser_simple_declaration
../../gcc/cp/parser.c:15066
0x8b642f cp_parser_declaration
../../gcc/cp/parser.c:14828
0x8b6ebb cp_parser_translation_unit
../../gcc/cp/parser.c:4987
0x8b6ebb c_parse_file()
../../gcc/cp/parser.c:47774
0x988802 c_common_parse_file()
../../gcc/c-family/c-opts.c:1237
[Bug fortran/102595] New: ICE in var_element, at fortran/decl.c:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 Bug ID: 102595 Summary: ICE in var_element, at fortran/decl.c:298 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r10 : $ cat z1.f90 program p complex, parameter :: x(0) = 2 data x%im /3.0/ end $ cat z2.f90 program p complex, parameter :: x(1) = 2 data x%im /3.0/ end $ gfortran-12-20211003 -c z2.f90 z2.f90:3:12: 3 |data x%im /3.0/ |1 Error: PARAMETER 'x' shall not appear in a DATA statement at (1) $ gfortran-12-20211003 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd41bdf crash_signal ../../gcc/toplev.c:331 0x77b0ed var_element ../../gcc/fortran/decl.c:298 0x77d4c4 top_var_list ../../gcc/fortran/decl.c:338 0x77d4c4 gfc_match_data() ../../gcc/fortran/decl.c:655 0x7eb6f1 match_word ../../gcc/fortran/parse.c:65 0x7f065e decode_statement ../../gcc/fortran/parse.c:469 0x7f13ca next_free ../../gcc/fortran/parse.c:1384 0x7f13ca next_statement ../../gcc/fortran/parse.c:1616 0x7f2aeb parse_spec ../../gcc/fortran/parse.c:4151 0x7f58bc parse_progunit ../../gcc/fortran/parse.c:6117 0x7f7041 gfc_parse_file() ../../gcc/fortran/parse.c:6658 0x843f3f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102385 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Mine.
[Bug fortran/102596] New: [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102596 Bug ID: 102596 Summary: [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20201108 and 20201115 : (ICEs with an allocatable) $ cat z1.f90 program p integer, allocatable :: r r = 0 !$omp target parallel reduction(task, +:r) r = r + 1 !$omp end target parallel end $ gfortran-12-20211003 -c z1.f90 -fopenmp during GIMPLE pass: omplower z1.f90:5:12: 5 |r = r + 1 |^ internal compiler error: in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 0x8af41b gfc_omp_clause_default_ctor(tree_node*, tree_node*, tree_node*) ../../gcc/fortran/trans-openmp.c:713 0xc1fc2e lower_rec_input_clauses ../../gcc/omp-low.c:6460 0xc239a6 lower_omp_taskreg ../../gcc/omp-low.c:12407 0xc14f21 lower_omp_1 ../../gcc/omp-low.c:14086 0xc14f21 lower_omp ../../gcc/omp-low.c:14287 0xc18a44 lower_omp_target ../../gcc/omp-low.c:12834 0xc18a44 lower_omp_1 ../../gcc/omp-low.c:14148 0xc18a44 lower_omp ../../gcc/omp-low.c:14287 0xc152e8 lower_omp_1 ../../gcc/omp-low.c:14064 0xc152e8 lower_omp ../../gcc/omp-low.c:14287 0xc153bd lower_omp_1 ../../gcc/omp-low.c:14077 0xc153bd lower_omp ../../gcc/omp-low.c:14287 0xc1c511 execute_lower_omp ../../gcc/omp-low.c:14326 0xc1c511 execute ../../gcc/omp-low.c:14374
[Bug fortran/102597] New: ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102597 Bug ID: 102597 Summary: ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r7 : $ cat z1.f90 program p use iso_fortran_env associate (y => (compiler_version)) end associate end $ cat z0.f90 program p use iso_fortran_env associate (y => compiler_version) end associate end $ gfortran-12-20211003 -c z1.f90 z1.f90:3:38: 3 |associate (y => (compiler_version)) | 1 internal compiler error: Segmentation fault 0xd41bdf crash_signal ../../gcc/toplev.c:331 0x86c901 gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-decl.c:2243 0x86d0ad gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-decl.c:2121 0x86d9c7 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1772 0x87d3e8 gfc_conv_variable ../../gcc/fortran/trans-expr.c:2994 0x87958a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9074 0x879696 gfc_conv_expr_op ../../gcc/fortran/trans-expr.c:3771 0x879696 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9062 0x889881 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11359 0x8bc04c trans_associate_var ../../gcc/fortran/trans-stmt.c:2201 0x8c2771 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2314 0x84adc7 trans_code ../../gcc/fortran/trans.c:2014 0x871974 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6905 0x7f77b6 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x7f77b6 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x843f3f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
