[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396 Jason Merrill changed: What|Removed |Added Target Milestone|--- |12.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a53781c8fd258608780821168a7f5faf7be63690 commit r12-3538-ga53781c8fd258608780821168a7f5faf7be63690 Author: Jason Merrill Date: Tue Sep 14 17:37:27 2021 -0400 c++: don't predeclare std::type_info [PR48396] We've always predeclared std::type_info, which has been wrong for a while, but now with modules it becomes more of a practical problem, if we want to declare it in the purview of a module. So don't predeclare it. For building up the type_info information to write out with the vtable, we can use void* instead of type_info*, since they already aren't the real types. PR c++/48396 gcc/cp/ChangeLog: * cp-tree.h (enum cp_tree_index): Remove CPTI_TYPE_INFO_PTR_TYPE. (type_info_ptr_type): Remove. * rtti.c (init_rtti_processing): Don't predeclare std::type_info. (typeid_ok_p): Check for null const_type_info_type_node. (type_info_ptr_type, get_void_tinfo_ptr): New fns. (get_tinfo_decl_dynamic, get_tinfo_ptr): Use them. (ptr_initializer, ptm_initializer, get_pseudo_ti_init): Use them. (get_tinfo_desc): Use const_ptr_type_node. gcc/testsuite/ChangeLog: * g++.dg/rtti/undeclared1.C: New test.
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 --- Comment #2 from Hugo van der Sanden --- I guess this is justified by the second paragraph of the -Wmaybe-uninitialized docs: "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." Firstly, I'd request for this case that the wording of the diagnostic should clarify that it's the data pointed to that may be used uninitialized rather than the pointer itself. Secondly, I think there's a case to be made that 'const void *' should specifically be exempt from this warning: that a void* is not "a pointer to an object". (The specific call in the original code was to pthread_getspecific(); it seems reasonable that it should take a 'const void *' as its second argument.)
[Bug target/102336] plugins for xtensa-elf gcc cannot be built because xtensa-config.h is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102336 --- Comment #1 from CVS Commits --- The master branch has been updated by Max Filippov : https://gcc.gnu.org/g:4633d623d7c112a8e239b84b2d85caaef02d316c commit r12-3535-g4633d623d7c112a8e239b84b2d85caaef02d316c Author: Max Filippov Date: Tue Sep 7 15:40:00 2021 -0700 gcc: xtensa: fix PR target/102336 2021-09-14 Max Filippov gcc/ PR target/102336 * config/xtensa/t-xtensa (TM_H): Add include/xtensa-config.h.
[Bug debug/80629] Missing .loc for a function in the presence of -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80629 Andrew Pinski changed: What|Removed |Added Keywords||wrong-debug --- Comment #2 from Andrew Pinski --- Hmm, something changed on the trunk to fix this case.
[Bug target/102327] gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 --- Comment #2 from Hongtao.liu --- Yes, it's redundant, Also vector init for v8hf is not optimal , refer to https://godbolt.org/z/M6a4aav48.
[Bug c/102337] New: possibly wrong warning about truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102337
Bug ID: 102337
Summary: possibly wrong warning about truncation
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rootkit85 at yahoo dot it
Target Milestone: ---
The following code:
#include
// build with: -O2 -Werror=format-truncation
void poke_kprobe_events(int add)
{
char cmd[192], probename[128], probefunc[128];
snprintf(probename, sizeof(probename), "a");
snprintf(probefunc, sizeof(probefunc), "b");
snprintf(cmd, sizeof(cmd), "%s %s", probename, probefunc);
}
Generates the following warning:
$ gcc -O2 -c test.c -Werror=format-truncation
test.c: In function ‘poke_kprobe_events’:
test.c:11:40: error: ‘%s’ directive output may be truncated writing up to 127
bytes into a region of size between 64 and 191 [-Werror=format-truncation=]
11 | snprintf(cmd, sizeof(cmd), "%s %s", probename, probefunc);
|^~ ~
test.c:11:9: note: ‘snprintf’ output between 2 and 256 bytes into a destination
of size 192
11 | snprintf(cmd, sizeof(cmd), "%s %s", probename, probefunc);
| ^
cc1: some warnings being treated as errors
I'm using the Fedora 34 packages:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20210728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
[Bug tree-optimization/45256] Missed arithmetic simplification at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
--- Comment #4 from Andrew Pinski ---
With IVOPTs we get:
# ivtmp.13_97 = PHI
_34 = MEM[(const __be32 *)_28 + -4B + ivtmp.13_97 * 4];
_36 = MEM[(const __be32 *)_27 + -4B + ivtmp.13_97 * 4];
if (_34 != _36)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 217424209]:
_22 = (int) ivtmp.13_97;
_40 = _22 * 32;
xb_37 = _34 ^ _36;
iftmp.1_53 = __fswab32 (xb_37);
__asm__("clz %0, %1" : "=r" ret_54 : "r" iftmp.1_53 : "cc");
ret_56 = 32 - ret_54;
_57 = _40 - ret_56;
MEM[(struct ipv6_saddr_score *) + 32B].matchlen = _57;
if (_57 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
So there is no extra add one any more.
BUT with -fno-ivopts I still see the add one.
[Bug tree-optimization/102324] ICE in initialize_matrix_A, at tree-data-ref.c:3959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
Andrew Pinski changed:
What|Removed |Added
Target Milestone|10.4|---
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-09-14
--- Comment #3 from Andrew Pinski ---
Reduced testcase (removing the C++ lambda):
#include
svint8_t doit(svbool_t ptrue, svint8_t in) {
int8_t data [2000];
svst1(ptrue, (int8_t *)data, in);
for (int _i = (int)svcntb()/2; _i < (int)svcntb(); ++_i)
data[_i] = data[_i-(int)svcntb()];
in = svld1(ptrue, data);
return in;
}
Confirmed.
ldist asked to generate code for vertex 3
(compute_affine_dependence
stmt_a: _2 = data[_1];
stmt_b: data[_i_16] = _2;
(analyze_overlapping_iterations
(chrec_a = {_i_9 - POLY_INT_CST [16, 16], +, 1}_1)
(chrec_b = {_i_9, +, 1}_1)
(analyze_siv_subscript
can_use_subscript_aff_aff_for_symbolic
(analyze_subscript_affine_affine
[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 --- Comment #9 from Eric Botcazou --- > The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1 > as well, does this mean it could happen before this patch as well? No idea, but it seems strange to disallow the copy for i2 and not the others.
[Bug target/102336] New: plugins for xtensa-elf gcc cannot be built because xtensa-config.h is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102336 Bug ID: 102336 Summary: plugins for xtensa-elf gcc cannot be built because xtensa-config.h is missing Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Enabling plugin support in xtensa linux results in the following build error: .../lib/gcc/xtensa-dc232b-elf/10.1.0/plugin/include/config/xtensa/xtensa.h:22:10: fatal error: xtensa-config.h: No such file or directory
[Bug tree-optimization/41244] "[i] - data" isn't converted to "i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
--- Comment #6 from Andrew Pinski ---
Here are some better testcases as the power of 2 case can be handled on the rtl
level as it is just a shift.
extern struct s{
int a, b, c, d, e, f, g, h;
} data[];
int find(int i, int j)
{
struct s *a = [i];
struct s *b = [j];
return a - b;
}
extern struct {
int a, b, c;
} data1[];
int find1(int i, int j)
{
return [i] - data1;
}
[Bug target/79559] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 Andrew Pinski changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #11 from Andrew Pinski --- *** Bug 63264 has been marked as a duplicate of this bug. ***
[Bug target/63264] Internal error due to invalid assembler register specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63264 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 79559. *** This bug has been marked as a duplicate of bug 79559 ***
[Bug middle-end/93903] space in constraint for inline-asm not ignored after all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93903 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-14 Component|inline-asm |middle-end Summary|invalid input constraint in |space in constraint for |__asm__ |inline-asm not ignored ||after all Ever confirmed|0 |1 Keywords||rejects-valid Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug inline-asm/84187] -O0 fails inline assembly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
This inline-asm is invalid for -O0 where no optimizations is done.
Reduced testcase:
static inline __attribute__((always_inline))
void _static_cpu_has(unsigned short bit)
{
asm ("": : "i" (bit));
}
void
GccCompileError_init(void)
{
_static_cpu_has(( 9*32+10)) ;
}
bit is not a literal constant so at -O0 there is no expectation that bit would
match the "i" constraints.
[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396 --- Comment #4 from Jason Merrill --- Created attachment 51462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51462=edit patch to allow redeclaration in module This isn't a proper fix, but may let you make progress with modularization.
[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 --- Comment #8 from Segher Boessenkool --- The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1 as well, does this mean it could happen before this patch as well? We already did have some things that did combine 2->2 (via a splitter), fwiw. But we do not check everything from splitters, we just trust it is good.
[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- (In reply to Eric Botcazou from comment #3) > This should probably have been prevented in two different ways: 1) the > volatile load and 2) the equal cost for a 2->2 combination. No, it is equal cost, but fewer dependencies; it is lower latency. This is how all costing in combine works. 1) of course *is* a problem.
[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
--- Comment #3 from Jonathan Wakely ---
cp/rtti.c defines:
/* Declare language defined type_info type and a pointer to const
type_info. This is incomplete here, and will be completed when
the user #includes . There are language defined
restrictions on what can be done until that is included. Create
the internal versions of the ABI types. */
void
init_rtti_processing (void)
{
push_nested_namespace (std_node);
tree type_info_type = xref_tag (class_type, get_identifier ("type_info"));
pop_nested_namespace (std_node);
const_type_info_type_node
= cp_build_qualified_type (type_info_type, TYPE_QUAL_CONST);
type_info_ptr_type = build_pointer_type (const_type_info_type_node);
vec_alloc (unemitted_tinfo_decls, 124);
create_tinfo_types ();
}
Is there a way to do that without making it visible to user code? Or without
implicitly adding it to the GMF?
[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-03-05 00:00:00 |2021-9-14
Keywords||rejects-valid
--- Comment #2 from Jonathan Wakely ---
This breaks modules, and makes it very difficult to export a 'std' module, as
proposed by https://wg21.link/p2412r0
export module std;
// define it
namespace std
{
class type_info;
}
// exports
export namespace std { };
namespace std
{
export class type_info;
}
g++ -fmodules-ts -fmodule-only std.cc
std.cc:6:9: error: cannot declare 'struct std::type_info' in a different module
6 | class type_info;
| ^
: note: declared here
std.cc:14:16: error: cannot declare 'struct std::type_info' in a different
module
14 | export class type_info;
|^
: note: declared here
std.cc:1:8: warning: not writing module 'std' due to errors
1 | export module std;
|^~
As a stop-gap, could we maybe suppress the implicit definition when
-fmodules-ts is in use? Otherwise I am unable to prototype the proposal.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #6 from Andreas Krebbel --- (insn 9 8 10 2 (set (strict_low_part (reg:SI 66)) (mem/c:SI (plus:SI (reg/f:SI 64) (const_int 4 [0x4])) [1 read_inode_val+0 S4 A32])) With -mesa this should be a simple move. However, in that case it apparently is emitted via insv.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Andreas Krebbel changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org --- Comment #5 from Andreas Krebbel --- Created attachment 51461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51461=edit Experimental patch
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
--- Comment #8 from Andrew Pinski ---
I thought there was another bug which was asking for something similar that I
did not link here yet. It had a reference to a syntax something like {"r1"}.
But I can't find it right now.
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 Andrew Pinski changed: What|Removed |Added Component|inline-asm |c Severity|normal |enhancement
[Bug fortran/102333] [9/10/11/12 Regression] ICE in gfc_generate_function_code, at fortran/trans-decl.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||accepts-invalid, ||ice-on-valid-code Last reconfirmed||2021-09-14 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- The result clause is not needed. We even ICE on: function f(x) class(*), pointer :: f contains function g() procedure(f), pointer :: g end end or function f(x) class(*), allocatable :: f contains function g() procedure(f), pointer :: g end end Note however that the code in comment#1 is invalid and should be rejected.
[Bug rtl-optimization/71246] "+g" assembly constraint causes error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71246 --- Comment #1 from Andrew Pinski --- So I think there needs to be some better documentation here with respect to the constraints that allow memory and the + modifier.
[Bug rtl-optimization/94180] inconsistent operand constraints: "+X"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180 Andrew Pinski changed: What|Removed |Added Keywords||documentation --- Comment #1 from Andrew Pinski --- So I think there needs to be some better documentation here with respect to the constraints that allow memory and the + modifier.
[Bug c/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 --- Comment #12 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #11) > as mentioned in another bug, this is more of a documentation issue and the > internal details on how inline-asm works. Yup. I suggest we advice to always use a register-size variable for an "r" operand: so not smaller, and not any random expression, but a simple variable. Are there situations where this is a limitation?
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Slightly cleaned up and submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056522.html
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 --- Comment #5 from anlauf at gcc dot gnu.org --- For the sake of completeness: considered as "obvious" https://gcc.gnu.org/pipermail/fortran/2021-September/056521.html
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #10 from Jakub Jelinek --- The optimize attribute is how different options are represented in LTO compilation, so it grew over years from perhaps initial debugging use to something that is used everywhere. And we definitely aren't going to add further and further attributes that match just a small subset of the optimize and/or target attributes, especially when they'd need to use the same infrastructure under the hood anyway. If you don't want to use optimize attribute, there is always the option to just do the arithmetics in unsigned types in the few selected functions where you don't want the sanitization, and if you really want use -fwrapv-pointer together with -fsanitize=integer-signed-overflow and throw away -fno-strict-overflow.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3 Summary|gcc-11 -Warray-bounds or|[11/12 Regression] gcc-11 |-Wstringop-overread warning |-Warray-bounds or |when accessing a pointer|-Wstringop-overread warning |from integer literal|when accessing a pointer ||from integer literal
[Bug c++/102050] Nonempty list-initialization rejects constructor with defaulted std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102050 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-09-14 Ever confirmed|0 |1
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #9 from Kees Cook ---
(In reply to Jakub Jelinek from comment #8)
> So, instead (when building the kernel with sanitization) build with
> -fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
> the routines where you want wrapv behavior and not runtime traps build with
> optimize ("wrapv", "wrapv-pointer") attribute?
__attribute__((optimize)) is documented as not for production use ("for
debugging purposes only"):
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-optimize-function-attribute
and the kernel has hit multiple problems with it. As such, all use has been
removed, for example:
https://lore.kernel.org/lkml/20201027205723.12514-1-a...@kernel.org/
https://lore.kernel.org/lkml/20201028080433.26799-1-a...@kernel.org/
https://lore.kernel.org/lkml/20210118105557.186614-3-adrian.ra...@collabora.com/
If there were an __attribute__((wrapv)) and __attribute__((wrapv-pointer)), we
could create the wrapping helpers with those and
__attribute__((no_sanitize("signed-integer-overflow")))
FWIW, I've been trying to track this issue in the kernel here:
https://github.com/KSPP/linux/issues/26
[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Summary|Volatile pointer|[9/10/11/12 Regression] |dereferenced twice |Volatile pointer ||dereferenced twice --- Comment #6 from Andrew Pinski --- Just so it is easier for the future the commit was r9-2064-gc4c5ad1d6d1e1e1fe7a .
[Bug tree-optimization/98774] gcc -O3 does not vectorize some operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774
--- Comment #5 from Andrew Pinski ---
For the trunk (without -ffast-math), the perms are done too early:
vect__5.32_53 = VEC_PERM_EXPR ;
vect__5.33_54 = VEC_PERM_EXPR ;
vect__5.34_55 = VEC_PERM_EXPR ;
_3 = *mag_9(D);
_58 = {_3, _3};
vect__4.35_59 = vect__5.32_53 * _58;
vect__4.35_60 = vect__5.33_54 * _58;
vect__4.35_61 = vect__5.34_55 * _58;
With -ffast-math:
a$x_1 = *dpos_10(D).x;
a$y_11 = *dpos_10(D).y;
_49 = {a$x_1, a$y_11};
_35 = _49 * _58;
And the PERM is done too early the same way ..
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b305ec979d9dfc8153859a62a8ab9dd43c3bfc73 commit r12-3533-gb305ec979d9dfc8153859a62a8ab9dd43c3bfc73 Author: Harald Anlauf Date: Tue Sep 14 20:23:27 2021 +0200 Fortran - fix ICE during error recovery checking entry characteristics gcc/fortran/ChangeLog: PR fortran/102311 * resolve.c (resolve_entries): Attempt to recover cleanly after rejecting mismatched function entries. gcc/testsuite/ChangeLog: PR fortran/102311 * gfortran.dg/entry_25.f90: New test.
[Bug tree-optimization/98774] gcc -O3 does not vectorize some operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774 --- Comment #4 from Ivan Sorokin --- I retested the sample on GCC 11.2. https://godbolt.org/z/xrarP3zbY Compared to Clang 12.0.1 GCC still generates 6 more instructions in total and does 6 mulpd against Clang's 4 mulpd.
[Bug c++/102335] gcc misses -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335 --- Comment #1 from Andrew Pinski --- Internal GCC details: Most likely because there is a TARGET_EXPR in the IR which causes it to be considered a side effect: <) >;
[Bug c++/102335] gcc misses -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335 Andrew Pinski changed: What|Removed |Added Severity|normal |minor Keywords||diagnostic
[Bug c++/102335] New: gcc misses -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335
Bug ID: 102335
Summary: gcc misses -Wunused-value
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
struct mytype
{
int memfun [[gnu::pure]] ();
};
void test()
{
mytype x;
x.memfun();// -Wunused-value
mytype().memfun(); // no -Wunused-value
}
https://godbolt.org/z/vc49jWGqn
The code above contains two usages of a [[gnu::pure]] function with ignored
return value. GCC detect only the first one. I believe the second one deserves
a warning too.
Clang shows a warning on both usages.
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Kees Cook changed: What|Removed |Added CC||kees at outflux dot net --- Comment #3 from Kees Cook --- Clang shares this problem, though it also lacks a warning, making it a silent missing initialization: https://bugs.llvm.org/show_bug.cgi?id=44916 FWIW, the Linux kernel has already purged all these cases, in preparation of using -ftrivial-auto-var-init: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep=Distribute+switch+variables+for+initialization
[Bug rtl-optimization/78963] [missed optimization] using 3-byte instead of 4-byte variables causes unnecessary work on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78963 --- Comment #1 from Eyal Rozenberg --- ... and perhaps I should add that, under certain circumstances, perhaps it should be possible to just mov four bytes from memory and ignore one of the bytes. On platforms where access must be aligned that would be more difficult to support consistently; and there may be end-of-page issues etc. Still, it's not inconceivable.
[Bug fortran/102334] New: [12 Regression] ICE in trans_associate_var, at fortran/trans-stmt.c:1794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102334 Bug ID: 102334 Summary: [12 Regression] ICE in trans_associate_var, at fortran/trans-stmt.c:1794 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 20210613 and 20210620 : $ cat z1.f90 subroutine s(x) class(*), allocatable, intent(out), target :: x(..) select rank (x) rank (1) end select end $ cat z4.f90 program p type t end type contains subroutine s(x) class(t), allocatable, target, intent(out) :: x(..) select rank (x) rank (1) end select end end $ gfortran-12-20210905 -c z1.f90 z1.f90:1:12: 1 | subroutine s(x) |1 internal compiler error: Segmentation fault 0xd09e4f crash_signal ../../gcc/toplev.c:328 0x88641e trans_associate_var ../../gcc/fortran/trans-stmt.c:1794 0x88d3a1 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2313 0x816407 trans_code ../../gcc/fortran/trans.c:2014 0x88ebd5 gfc_trans_select_rank_cases ../../gcc/fortran/trans-stmt.c:3733 0x88ebd5 gfc_trans_select_rank(gfc_code*) ../../gcc/fortran/trans-stmt.c:3788 0x8164a7 trans_code ../../gcc/fortran/trans.c:2038 0x88d32f gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2306 0x816407 trans_code ../../gcc/fortran/trans.c:2014 0x83cb64 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6918 0x7c2ee6 translate_all_program_units ../../gcc/fortran/parse.c:6569 0x7c2ee6 gfc_parse_file() ../../gcc/fortran/parse.c:6838 0x80f57f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102333] [9/10/11/12 Regression] ICE in gfc_generate_function_code, at fortran/trans-decl.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333 --- Comment #1 from G. Steinmetz --- Compiles with "allocatable" instead : $ cat z2.f90 function f(x) result(y) class(*), allocatable :: y contains function g() result(z) procedure(f), allocatable :: z end end
[Bug fortran/102333] New: [9/10/11/12 Regression] ICE in gfc_generate_function_code, at fortran/trans-decl.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333 Bug ID: 102333 Summary: [9/10/11/12 Regression] ICE in gfc_generate_function_code, at fortran/trans-decl.c:6941 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 (before 20180426) : $ cat z1.f90 function f(x) result(y) class(*), pointer :: y contains function g() result(z) procedure(f), pointer :: z end end $ gfortran-6 -c z1.f90 z1.f90:4:25: function g() result(z) 1 Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer $ gfortran-12-20210905 -c z1.f90 z1.f90:6:6: 6 |end | 1 internal compiler error: Segmentation fault 0xd09e4f crash_signal ../../gcc/toplev.c:328 0x83d821 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6941 0x83c964 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5912 0x83c964 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6850 0x7c2ee6 translate_all_program_units ../../gcc/fortran/parse.c:6569 0x7c2ee6 gfc_parse_file() ../../gcc/fortran/parse.c:6838 0x80f57f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- And also : $ cat zz1.f90 program p type t real :: a, b end type class(t) :: x select type (y => x) class is (t) y%a = 0 end select end $ cat zz4.f90 program p type t real :: a, b end type class(t) :: x select type (y => x) class default y%a = 0 end select end $ cat z3.f90 program p type t real :: a, b end type class(t) :: x select type (y => x) type default y%a = 0 end select end
[Bug fortran/102332] New: ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 Bug ID: 102332 Summary: ICE in select_type_set_tmp, at fortran/match.c:6366 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: --- With a missing attribute allocatable or pointer : (down to at least r5) $ cat z1.f90 program p type t real :: a, b end type class(t) :: x select type (y => x) type is (t) y%a = 0 end select end $ cat z2.f90 program p type t real :: a, b end type class(t), allocatable :: x select type (y => x) type is (t) y%a = 0 end select end $ gfortran-12-20210905 -c z2.f90 # ok $ $ gfortran-12-20210905 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd09e4f crash_signal ../../gcc/toplev.c:328 0x78fa67 select_type_set_tmp ../../gcc/fortran/match.c:6366 0x798bfc gfc_match_type_is() ../../gcc/fortran/match.c:6901 0x7b6e01 match_word ../../gcc/fortran/parse.c:65 0x7bc444 decode_statement ../../gcc/fortran/parse.c:572 0x7bcada next_free ../../gcc/fortran/parse.c:1384 0x7bcada next_statement ../../gcc/fortran/parse.c:1616 0x7bfe31 parse_select_type_block ../../gcc/fortran/parse.c:4526 0x7bfe31 parse_executable ../../gcc/fortran/parse.c:5737 0x7c108f parse_progunit ../../gcc/fortran/parse.c:6140 0x7c2771 gfc_parse_file() ../../gcc/fortran/parse.c:6655 0x80f57f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Detected with "type" instead of "class" : $ cat za1.f90 type(t) function f() allocatable :: f end $ cat za2.f90 type(t) function f() pointer :: f end $ gfortran-12-20210905 -c za1.f90 za1.f90:1:0: 1 | type(t) function f() | Error: The type for function 'f' at (1) is not accessible
[Bug fortran/102331] New: ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 Bug ID: 102331 Summary: ICE in attr_decl1, at fortran/decl.c:8691 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: --- Affects versions down to at least r5 (type t not defined) : $ cat z1.f90 class(t) function f() allocatable :: f end $ cat z2.f90 class(t) function f() pointer :: f end $ gfortran-12-20210905 -c z1.f90 f951: internal compiler error: Segmentation fault 0xeace0f crash_signal ../../gcc/toplev.c:328 0x7882b4 attr_decl1 ../../gcc/fortran/decl.c:8691 0x7882b4 attr_decl ../../gcc/fortran/decl.c:8777 0x7f7db1 match_word ../../gcc/fortran/parse.c:65 0x7fd189 decode_statement ../../gcc/fortran/parse.c:441 0x7fda8a next_free ../../gcc/fortran/parse.c:1384 0x7fda8a next_statement ../../gcc/fortran/parse.c:1616 0x7ff2ad parse_spec ../../gcc/fortran/parse.c:4164 0x801f9c parse_progunit ../../gcc/fortran/parse.c:6114 0x803a37 gfc_parse_file() ../../gcc/fortran/parse.c:6669 0x8510ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102330] New: [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330 Bug ID: 102330 Summary: [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 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 between 20210530 and 20210606 : $ cat z1.f90 program p !$omp master taskloop simd do i = 1, 8 end do !$acc parallel loop do i = 1, 8 end do end $ gfortran-12-20210905 -c z1.f90 -fopenmp -fopenacc during RTL pass: expand z1.f90:5:21: 5 | !$acc parallel loop | ^ internal compiler error: in expand_gimple_stmt_1, at cfgexpand.c:3932 0x8dd6db expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3931 0x8dd6db expand_gimple_stmt ../../gcc/cfgexpand.c:4040 0x8e2bd7 expand_gimple_basic_block ../../gcc/cfgexpand.c:6082 0x8e553e execute ../../gcc/cfgexpand.c:6808 --- z1.f90:8:3: 8 | end | ^ Error: non-register as LHS of binary operation # .MEM_25 = VDEF <.MEM_3> i = 1 + .offset.9_2; z1.f90:8:3: Error: non-register as LHS of binary operation # .MEM_28 = VDEF <.MEM_4> i = 1 + 8; during GIMPLE pass: ssa z1.f90:8:3: internal compiler error: verify_gimple failed 0xf05dd4 verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.c:5531 0xdb304e execute_function_todo ../../gcc/passes.c:2042 0xdb3ef2 execute_todo ../../gcc/passes.c:2096
[Bug c/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This was added in r11-959-gb825a22890740f341eae566af27e18e528cd29a7
[Bug c/102329] New: pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
Bug ID: 102329
Summary: pointer "maybe uninitialized" right after assignment
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
Reduced from perl source code:
% cat test.c
extern void *malloc (long unsigned int size);
extern void f1 (const void *pointer);
void perl_alloc(void) {
void *vp1 = malloc(1);
/* *(char*)vp1 = 0; */
f1((const void *)vp1);
}
% gcc-11.2.0 -c -Wmaybe-uninitialized -O2 test.c
test.c: In function 'perl_alloc':
test.c:7:5: warning: 'vp1' may be used uninitialized [-Wmaybe-uninitialized]
8 | f1((const void *)vp1);
| ^
test.c:2:13: note: by argument 1 of type 'const void *' to 'f1' declared here
3 | extern void f1 (const void *pointer);
| ^~
%
This build of gcc was configured as follows (including the error in prefix):
../gcc/configure --prefix=/opt/gcc-12 --disable-gcov --disable-multilib
--enable-languages=c --disable-nls --disable-decimal-float
No warning is seen under my system "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102", nor does 11.2.0 complain if the commented-out assignment is
uncommented, nor if 'malloc' is renamed to 'f2', nor if 'const' is removed from
the signature of f1 along with the corresponding cast.
Is the warning intended to imply that the memory pointed to by vp1 may be
uninitialized, rather than vp1 itself? If so, perhaps it is only that the
message is misleadingly worded, and making possibly inappropriate assumptions
about what f1() may do.
[Bug tree-optimization/102324] ICE in initialize_matrix_A, at tree-data-ref.c:3959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > So likely we're seeing a POLY_INT here which could eventually be handled the > same as an INTEGER_CST but the question is what to do else (well, return > chrec_dont_know). Well, following previous discussion about SCEVs, the agreement was to treat POLY_INT_CSTs as symbolic. The only caller of initialize_matrix_A is analyze_subscript_affine_affine, which says: /* Determines the overlapping elements due to accesses CHREC_A and CHREC_B, that are affine functions. This function cannot handle symbolic evolution functions, ie. when initial conditions are parameters, because it uses lambda matrices of integers. */ So I guess one question is why we're still seeing symbolic chrecs despite that.
[Bug analyzer/102328] New: ICE when compare std::list iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102328
Bug ID: 102328
Summary: ICE when compare std::list iterator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
std::list l;
l.begin() == l.end();
}
https://godbolt.org/z/YdYTcrW4r
I have never used the gcc static analyzer and I just found this ICE
accidentally. Please correct me if I did something wrong.
[Bug target/102327] gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-14
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #8 from Jakub Jelinek ---
So, instead (when building the kernel with sanitization) build with
-fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
the routines where you want wrapv behavior and not runtime traps build with
optimize ("wrapv", "wrapv-pointer") attribute?
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #7 from Kees Cook ---
The problem the kernel needs to solve is basically having our cake and eating
it too. :)
In _most_ situations, we want signed overflows to trap (i.e. get caught by
"-fsanitize=signed-integer-overflow").
In some limited situations, we want to be able to depend on 2s-complement
wrap-around on overflow -- and we would create a helper function to do this
work, marked with __attribute__((no_sanitize("signed-integer-overflow"))). (We
need this most for our atomic_t/refcount_t code, as well as all the open-coded
bounds checks -- see details below.)
For the latter case (wrap-around), the kernel must depend on the effects of
"-fwrapv-pointer" and "-fwrapv" because otherwise some cases end up being
elided due to being classified as undefined behavior.
(In reply to Jakub Jelinek from comment #6)
> That doesn't make sense. -fsanitize=signed-integer-overflow also removes
> that undefined behavior by defining what happens on signed integer overflow,
> one can choose whether to get a non-fatal runtime diagnostic + wrapv
> behavior, or fatal runtime diagnostic, or just abort.
There doesn't appear to be a way to remove the UB _and_ the diagnostic on a
case-by-case basis.
The matrix of behaviors:
code generation: UB, no UB (2s-complement wrap-around)
diagnostics: no diagnostic, warn or trap
-fno-strict-overflow provides "no UB", and "no diagnostic". ("warn or trap" are
not available.)
-fsanitize=signed-integer-overflow provides "no UB" and "warn or trap". ("no
diagnostic" is not available; using
__attribute__((no_sanitize("signed-integer-overflow"))) also removes "no UB")
So, on a per-function basis, we need to _either_ catch overflow _or_
deterministically perform 2s-complement wrap-around.
If there's a way to achieve this already, I would be very grateful, as I've not
been able to find the correct combination.
Background on the kernel's use of -fno-strict-overflow:
https://git.kernel.org/linus/a137802ee839ace40079bebde24cfb416f73208a
and (earlier) -fwrapv:
https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594
An example of wanting no-UB without diagnostic:
https://git.kernel.org/linus/adb03115f4590baa280ddc440a8eff08a6be0cb7
which ultimately had to be reverted:
https://git.kernel.org/linus/a6211caa634da39d861a47437ffcda8b38ef421b
and all of UBSAN integer overflow support was removed:
https://git.kernel.org/linus/6aaa31aeb9cf260e1b7155cc11ec864f052db5ec
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
(In reply to 康桓瑋 from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> > in rejecting it.
>
> Maybe. But why does GCC accept the following?
>
> #include
> #include
>
> int main() {
> std::tuple t{{}, {}};
> }
>
> https://godbolt.org/z/ePovjh3fa
Looks like we accept this testcase because the template parameter _Alloc for
the template candidate
template::value, _T1, _T2> = true>
tuple(std::allocator_arg_t, const _Alloc&)
is no longer deducible (whereas in the original testcase _Alloc is deduced to
int here), so this candidate is discarded and the result of overload resolution
is no longer ambiguous.
(In reply to Andrew Pinski from comment #2)
> See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> in rejecting it.
Agreed FWIW
[Bug c++/102163] [10/11/12 Regression] std::variant rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102163 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:de07cff96abd43f6f65dcf333958899c2ec42598 commit r12-3527-gde07cff96abd43f6f65dcf333958899c2ec42598 Author: Patrick Palka Date: Tue Sep 14 11:22:12 2021 -0400 c++: empty union member activation during constexpr [PR102163] Here, the union's constructor is defined to activate its empty data member _M_rest, but during constexpr evaluation of this constructor the subobject constructor call O::O(&_M_rest, 42) doesn't produce a side effect that actually activates the member, so the union still appears uninitialized after its constructor has run. This patch fixes this by using a dummy MODIFY_EXPR in this situation, whose evaluation ensures the member gets activated. PR c++/102163 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_call_expression): After evaluating a subobject constructor call for an empty union member, produce a side effect that makes sure the member gets activated. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-empty17.C: New test.
[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305 --- Comment #6 from Jonathan Wakely --- It should be backported IMHO. I don't see how anybody can be relying on is_default_constructible being wrong, that doesn't make much sense. You check that trait in SFINAE contexts to see if you can construct the type, but because the answer is wrong any code that tries to construct it will get a compiler error.
[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #5 from Jakub Jelinek ---
On one side, some code could be relying on bug compatibility and so it would be
undesirable to change it on release branches, on the other side the current
behavior there is just weird,
#include
template struct AbstractTemplate {
virtual ~AbstractTemplate() = 0;
};
#ifdef D
struct S : AbstractTemplate {};
#endif
bool a = std::is_default_constructible >::value;
a is true if D is not defined and false if D is defined. And one can't really
construct those abstract template classes...
[Bug target/102327] gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 David Binderman changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding author for clarification.
[Bug target/102327] New: gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327 Bug ID: 102327 Summary: gcc/config/i386/i386-expand.c:14678: Suspicious coding ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: gcc/config/i386/i386-expand.c:14678:8: style: Variable 'op1' is reassigned a value before the old one has been used. [redundantAssignment] Source code is /* Convert HFmode to HImode. */ op1 = gen_reg_rtx (HImode); op1 = gen_rtx_SUBREG (HImode, force_reg (HFmode, op), 0); I don't know the code, but if the return value from gen_reg_rtx isn't needed, then suggest don't assign it into op1.
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295 --- Comment #6 from Jakub Jelinek --- Fixed for 12+ so far.
[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305 --- Comment #4 from Jakub Jelinek --- Fixed for 12.0 so far. Do we want to backport it?
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:818c505188ff5cd8eb048eb0e614c4ef732225bd commit r12-3526-g818c505188ff5cd8eb048eb0e614c4ef732225bd Author: Jakub Jelinek Date: Tue Sep 14 16:56:30 2021 +0200 c++: Update DECL_*SIZE for objects with flexible array members with initializers [PR102295] The C FE updates DECL_*SIZE for vars which have initializers for flexible array members for many years, but C++ FE kept DECL_*SIZE the same as the type size (i.e. as if there were zero elements in the flexible array member). This results e.g. in ELF symbol sizes being too small. Note, if the flexible array member is initialized only with non-constant initializers, we have a worse bug that this patch doesn't solve, the splitting of initializers into constant and dynamic initialization removes the initializer and we don't have just wrong DECL_*SIZE, but nothing is emitted when emitting those vars into assembly either and so the dynamic initialization clobbers other vars that may overlap the variable. I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the flexible array member in that case. 2021-09-14 Jakub Jelinek PR c++/102295 * decl.c (layout_var_decl): For aggregates ending with a flexible array member, add the size of the initializer for that member to DECL_SIZE and DECL_SIZE_UNIT. * g++.target/i386/pr102295.C: New test.
[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f008fd3a480e3718436156697ebe7eeb47841457 commit r12-3525-gf008fd3a480e3718436156697ebe7eeb47841457 Author: Jakub Jelinek Date: Tue Sep 14 16:55:04 2021 +0200 c++: Fix __is_*constructible/assignable for templates [PR102305] is_xible_helper returns error_mark_node (i.e. false from the traits) for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early. Unfortunately, as the testcase shows, that doesn't work on class templates that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false until it is instantiated, which is done when the routine later constructs a dummy object with that type. The following patch fixes this by calling complete_type first, so that ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling of arrays with unknown bounds, or incomplete types where it is done currently. 2021-09-14 Jakub Jelinek PR c++/102305 * method.c (is_xible_helper): Call complete_type on to. * g++.dg/cpp0x/pr102305.C: New test.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #22 from Chip Kerchner ---
(In reply to Chip Kerchner from comment #21) - Forgot one line of code
> --
> #pragma GCC target "cpu=power10"
> int main() {
> float *b;
> __vector_quad c;
> __builtin_mma_disassemble_acc(b, );
> return 0;
> }
> --
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #21 from Chip Kerchner ---
I'm also seeing MMA problems with LTO. With this simple program (main.ii)
--
int main() {
float *b;
__vector_quad c;
__builtin_mma_disassemble_acc(b, );
return 0;
}
--
And this compile (using gcc 10.3.1)
--
g++ -flto=auto -mcpu=power9 main.ii
--
I'm seeing this error (which does NOT occur without LTO)
--
lto1: error: '__builtin_mma_xxmfacc_internal' requires the '-mmma' option
lto1: fatal error: target specific builtin not available
compilation terminated.
--
[Bug rtl-optimization/102306] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 --- Comment #5 from Eric Botcazou --- Created attachment 51460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51460=edit Tentative fix To be tested.
[Bug rtl-optimization/102306] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 --- Comment #4 from Eric Botcazou --- There is substantial checking for volatile references in can_combine_p but it implicitly assumes that the combination reduces the number of instructions.
[Bug rtl-optimization/102306] Volatile pointer dereferenced twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Trying 6 -> 7: 6: r109:QI=[%i0:SI] REG_DEAD %i0:SI 7: r112:SI=zero_extend(r109:QI) Failed to match this instruction: (parallel [ (set (reg:SI 112 [ _1+-3 ]) (zero_extend:SI (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8]))) (set (reg:QI 109 [ _1 ]) (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8])) ]) Failed to match this instruction: (parallel [ (set (reg:SI 112 [ _1+-3 ]) (zero_extend:SI (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8]))) (set (reg:QI 109 [ _1 ]) (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8])) ]) Successfully matched this instruction: (set (reg:QI 109 [ _1 ]) (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8])) Successfully matched this instruction: (set (reg:SI 112 [ _1+-3 ]) (zero_extend:SI (mem/v:QI (reg:SI 24 %i0 [ a ]) [0 *a_5(D)+0 S1 A8]))) allowing combination of insns 6 and 7 original costs 4 + 4 = 8 replacement costs 4 + 4 = 8 modifying insn i2 6: r109:QI=[%i0:SI] deferring rescan insn with uid = 6. modifying insn i3 7: r112:SI=zero_extend([%i0:SI]) REG_DEAD %i0:SI deferring rescan insn with uid = 7. This should probably have been prevented in two different ways: 1) the volatile load and 2) the equal cost for a 2->2 combination.
[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981 --- Comment #9 from Martin Liška --- So GCC 7 emits: $ nm --print-size pr101981-2.o 0034 T big_switch and GCC master emits: nm --print-size pr101981-2.o 0030 T big_switch So the code is smaller with the current master.
[Bug c++/102326] New: ICE in tree_to_uhwi, at tree.c:4520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102326
Bug ID: 102326
Summary: ICE in tree_to_uhwi, at tree.c:4520
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pc.wang at linux dot alibaba.com
Target Milestone: ---
Created attachment 51459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51459=edit
A patch that may fix this bug
If there exists static local variable of variable-length vector type(like types
in AARCH64 SVE and RISCV Vector Extension) in C++ template, like:
```
#include
template
void f()
{
int i = 0;
static svbool_t pg = svwhilelt_b64(0, N);
}
int main(int argc, char **argv)
{
f<2>();
return 0;
}
```
GCC raises an ICE like:
```
static-var-in-template.cpp:14:1: internal compiler error: in tree_to_uhwi, at
tree.h:4520
14 | }
| ^
```
And here is the version of GCC:
```
Using built-in specs.
COLLECT_GCC=aarch64-none-linux-gnu-g++
COLLECT_LTO_WRAPPER=/lhome/wangpc/software/arm/bin/../libexec/gcc/aarch64-none-linux-gnu/10.2.1/lto-wrapper
Target: aarch64-none-linux-gnu
Configured with:
/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/src/gcc/configure
--target=aarch64-none-linux-gnu --prefix=
--with-sysroot=/aarch64-none-linux-gnu/libc
--with-build-sysroot=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/install//aarch64-none-linux-gnu/libc
--with-bugurl=https://bugs.linaro.org/ --enable-gnu-indirect-function
--enable-shared --disable-libssp --disable-libmudflap --enable-checking=release
--enable-languages=c,c++,fortran
--with-gmp=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-mpfr=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-mpc=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-isl=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--enable-fix-cortex-a53-843419 --with-pkgversion='GNU Toolchain for the
A-profile Architecture 10.2-2020.11 (arm-10.16)'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
10.2-2020.11 (arm-10.16))
```
The lack of type checking (defined by hook `TARGET_VERIFY_TYPE_CONTEXT`) after
instantiation is the reason, since SVE/RVV types can't be static.
[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
--- Comment #8 from Martin Liška ---
>
> Not a big difference in term of instructions is this case but as much as the
> switch increases, the difference becomes huge (in my case it switched from
> 75 to 94 lines)
> Code size increases of about 10%.
>
>
> @Martin, do you know if this is linked?
Yes, it's slightly related. This one is about a bit changed emission of
bit-tests:
GCC 7 emits:
[100.00%]:
_6 = (unsigned int) a_2(D);
if (_6 > 29)
goto ; [50.00%]
else
goto ; [50.00%]
[50.00%]:
_8 = 1 << _6;
_9 = _8 & 933684326;
if (_9 != 0)
goto ; [46.00%]
else
goto ; [54.00%]
[77.00%]:
printf ("default a(%d)\n", a_2(D));
[100.00%]:
printf ("a(%d)\n", a_2(D)); [tail call]
return;
while GCC master does:
[local count: 1073741824]:
_13 = (unsigned int) a_2(D);
_12 = _13 > 29;
if (_12 != 0)
goto ; [20.00%]
else
goto ; [80.00%]
[local count: 858993464]:
_11 = 933684326 >> _13;
_10 = _11 & 1;
_9 = _10 != 0;
if (_9 != 0)
goto ; [58.62%]
else
goto ; [41.38%]
[local count: 354334800]:
:
printf ("default a(%d)\n", a_2(D));
[local count: 1073741824]:
:
printf ("a(%d)\n", a_2(D));
return;
which is pretty much the same code. Note your line count metrics is a bit
misleading
as directives like .word or .byte have a different size in the final binary,
simiarly for other
instructions.
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320 --- Comment #7 from zhuguanghong --- I get it, thank you for your answer
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Jakub Jelinek ---
That is just a wrong expectation. GOMP_CPU_AFFINITY is IMHO clearly documented
what it does:
Binds threads to specific CPUs. The variable should contain a space-separated
or comma-separated list of CPUs. This list may contain different kinds of
entries: either single CPU numbers in any order, a range of CPUs (M-N)
or a range with some stride (M-N:S). CPU numbers are zero based. For example,
@code{GOMP_CPU_AFFINITY="0 3 1-2 4-15:2"} will bind the initial thread
to CPU 0, the second to CPU 3, the third to CPU 1, the fourth to
CPU 2, the fifth to CPU 4, the sixth through tenth to CPUs 6, 8, 10, 12,
and 14 respectively and then start assigning back from the beginning of
the list. @code{GOMP_CPU_AFFINITY=0} binds all threads to CPU 0.
So, if you use 0-7, the first thread (initial thread) goes to cpu 0, second to
1, etc. up to 7 and then again from the beginning of the list.
If you want something else, you can use the standard OMP_PLACES variable, which
allows you to define a place as having a set of CPUs and then bind threads to
selected places.
[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- maxim has posted the (IMO obvious) patch here: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579159.html as noted any platform that might be bootstrapped using clang is affected.
[Bug fortran/102313] [12 Regression] ICE in gfc_ascii_statement(): Bad statement code since r12-2962-gf8d535f3fec81c1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED. Thanks for the report.
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #6 from David Malcolm --- Patch discussion: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579354.html
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320 --- Comment #5 from zhuguanghong --- But what I want is that 0-7cpu can run this thread
[Bug fortran/102313] [12 Regression] ICE in gfc_ascii_statement(): Bad statement code since r12-2962-gf8d535f3fec81c1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:33fdbbe4ce6055eb858096d01720ccf94aa854ec commit r12-3524-g33fdbbe4ce6055eb858096d01720ccf94aa854ec Author: Tobias Burnus Date: Tue Sep 14 14:17:35 2021 +0200 Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313] PR fortran/102313 gcc/fortran/ChangeLog: * parse.c (gfc_ascii_statement): Add missing ST_OMP_END_SCOPE. gcc/testsuite/ChangeLog: * gfortran.dg/goacc/unexpected-end.f90: New test. * gfortran.dg/gomp/unexpected-end.f90: New test.
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320 --- Comment #4 from zhuguanghong --- This leads to when I set the environment variable "GOMP_CPU_AFFINITY=0-7" and call the initialize_env function, the thread will be automatically bound to one cpu and cannot be scheduled to other cpu.
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #3 from zhuguanghong ---
hi ，thanks for your reply
initialize_env (void)
1 {
0
1 if (parse_affinity (ignore))
2 {
3 if (gomp_global_icv.bind_var == omp_proc_bind_false)
4 gomp_global_icv.bind_var = true;
5 ignore = true;
6 }
7 if (gomp_global_icv.bind_var != omp_proc_bind_false)
8 gomp_init_affinity ();
Set the cpuset in the parse_affinity function and set it in different
gomp_places_list .the cpuset is set in the parse_affinity function and is set
in different gomp_places_list, but in the function gomp_init_affinity it is
only set using gomp_places_list[0]
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320 --- Comment #2 from Jakub Jelinek --- I'm sorry but from the above it is impossible to decipher what do you think is a bug and why. Can you write a few sentences about what env var or cpu configuration do you think misbehaves and why?
[Bug libgomp/102320] Set cpu affinity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #1 from zhuguanghong ---
fix？ like this ?
while(gomp_places_list_len-- ){
*(gomp_places_list[0]) | = *(gomp_places_list[gomp_places_list_len])
[Bug tree-optimization/102324] ICE in initialize_matrix_A, at tree-data-ref.c:3959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- So likely we're seeing a POLY_INT here which could eventually be handled the same as an INTEGER_CST but the question is what to do else (well, return chrec_dont_know). Somebody needs to verify whether the dependence compute resulting is sane (or gracefully fails).
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-09-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug modula2/102325] New: gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 Bug ID: 102325 Summary: gm2 testsuite drivers should be unique Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Currently, all but one of the gm2 testsuite drivers are called gm2.exp. This is bad because it doesn't support running specific parts of the testsuite selectivly, like make check-m2 RUNTESTFLAGS=.exp. Instead, this should follow the other testsuites where the driver names are unique.
[Bug tree-optimization/102324] ICE in initialize_matrix_A, at tree-data-ref.c:3959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.4 Target||aarch64 Known to fail||10.3.1, 11.1.1, 12.0
[Bug tree-optimization/102324] New: ICE in initialize_matrix_A, at tree-data-ref.c:3959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
Bug ID: 102324
Summary: ICE in initialize_matrix_A, at tree-data-ref.c:3959
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: ktkachov at gcc dot gnu.org
Target Milestone: ---
The AArch64 SVE ACLE testcase below
#include
svint8_t doit(svbool_t ptrue, svint8_t m0) {
auto combine_low =
[]( svint8_t in) -> svint8_t {
int8_t data [2000];
svst1(ptrue, (int8_t *)data, in);
for (int _i = (int)svcntb()/2; _i < (int)svcntb(); ++_i)
data[_i] = data[_i-(int)svcntb()];
in = svld1(ptrue, data);
return in;
};
return combine_low(m0);
}
ICEs with -march=armv8-a+sve -O2
ice.cc: In lambda function:
ice.cc:4:5: internal compiler error: in initialize_matrix_A, at
tree-data-ref.c:3959
4 | []( svint8_t in) -> svint8_t {
| ^
0x1ed2988 initialize_matrix_A
$SRC/gcc/tree-data-ref.c:3959
0x1ed2965 initialize_matrix_A
$SRC/gcc/tree-data-ref.c:3929
0x1ed8454 analyze_subscript_affine_affine
$SRC/gcc/tree-data-ref.c:4361
0x1edb8fd analyze_siv_subscript
$SRC/gcc/tree-data-ref.c:4703
0x1edb8fd analyze_overlapping_iterations
$SRC/gcc/tree-data-ref.c:4933
0x1edb8fd subscript_dependence_tester_1
$SRC/gcc/tree-data-ref.c:5487
0x1edc10c subscript_dependence_tester
$SRC/gcc/tree-data-ref.c:5537
0x1edc10c compute_affine_dependence(data_dependence_relation*, loop*)
$SRC/gcc/tree-data-ref.c:5597
0x118ea4d loop_distribution::get_data_dependence(graph*, data_reference*,
data_reference*)
$SRC/gcc/tree-loop-distribution.c:1379
0x118eaba loop_distribution::data_dep_in_cycle_p(graph*, data_reference*,
data_reference*)
$SRC/gcc/tree-loop-distribution.c:1398
0x118ed49 loop_distribution::update_type_for_merge(graph*, partition*,
partition*)
$SRC/gcc/tree-loop-distribution.c:1441
0x118f927 loop_distribution::build_rdg_partition_for_vertex(graph*, int)
$SRC/gcc/tree-loop-distribution.c:1485
0x118fb51 loop_distribution::rdg_build_partitions(graph*, vec, vec*)
$SRC/gcc/tree-loop-distribution.c:1938
0x1191c19 loop_distribution::distribute_loop(loop*, vec const&, control_dependences*, int*, bool*, bool)
$SRC/gcc/tree-loop-distribution.c:2984
0x11940f8 loop_distribution::execute(function*)
$SRC/gcc/tree-loop-distribution.c:3353
0x119508d execute
$SRC/gcc/tree-loop-distribution.c:3441
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug modula2/102323] New: gm2 testsuite needs to be parallelized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323 Bug ID: 102323 Summary: gm2 testsuite needs to be parallelized Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- When running the gm2 testsuite, I noticed that it currently only runs sequentially. E.g. on a 2-socket AMD EPYC 7452 system, the testsuite run took 51 minutes. This can easily dominate total test time and can be avoided by introducing an appropriate amount of parallelism, cf. lang_checks_parallelized and check_$lang_parallelize in gcc/*/Make-lang.in.
[Bug modula2/102322] New: libgm2 Makefiles should be self-contained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102322 Bug ID: 102322 Summary: libgm2 Makefiles should be self-contained Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- When trying to investigate PR modula2/101389, I noticed that the libgm2 Makefiles use several Makefiles that are only passed in from the toplevel, like GM2_FOR_TARGET. This is both inconvenient (if you want to build just a single target when investigating some issue, you have to determine the missing variables from the toplevel Makefile and pass them explicitly) and not in line with the other target libraries. Every libgm2 Makefile should be self-contained, meaning every variable used (or at least the required ones) should be substituted into the Makefiles at configure time.
[Bug modula2/101389] Parallel build doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101389 --- Comment #2 from Rainer Orth --- (In reply to Gaius Mulley from comment #1) > Thanks for the report - I've pushed some fixes to various Makefiles. I've > tested it using make -j48 and believe it is fixed. A -j48 build on x86_64-pc-linux-gnu worked ok yesterday. However, on i386-pc-solaris2.11 I ran into exactly the same issue again (i.e. affecting the build of ASCII.lo). I managed to complete the build sequentially afterwards, but it's still strange. Investigation was hampered by the libgm2 Makefiles not being self-contained. I'll file a separate PR for that.
[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Rainer Orth changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-14 Status|UNCONFIRMED |NEW --- Comment #1 from Rainer Orth --- (In reply to Rainer Orth from comment #0) > I couldn't make much sense of this yet. Probably requires rebuilding cc1gm2 > with > -g3 -O0. I've now done just that. Here's what I find: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb51bb0 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfeb51bb0 in strlen () from /lib/libc.so.1 #1 0xfeb937fc in strdup () from /lib/libc.so.1 #2 0x02a48c90 in lrealpath (filename=0x0) at /vol/gcc/src/git/modula-2/libiberty/lrealpath.c:88 #3 0x02a45fa4 in canonical_filename_eq (a=0xffbff8e2 "SYSTEM.s", b=0x0) at /vol/gcc/src/git/modula-2/libiberty/filename_cmp.c:216 #4 0x016e97c8 in init_asm_output (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 #5 0x016ed1dc in lang_dependent_init (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2218 #7 0x016ee4a8 in toplev::main (this=0xffbff6e2, argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 #8 0x02924ec4 in main (argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/main.c:39 #4 0x016e97c8 in init_asm_output (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 714 else if (!canonical_filename_eq (asm_file_name, name) (gdb) p asm_file_name $3 = 0xffbff8e2 "SYSTEM.s" (gdb) p name $4 = 0x0 (gdb) up #5 0x016ed1dc in lang_dependent_init (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 1927 init_asm_output (name); gdb) up #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2218 2218 if (lang_dependent_init (main_input_filename)) (gdb) p main_input_filename $6 = 0x0 (gdb) up #7 0x016ee4a8 in toplev::main (this=0xffbff6e2, argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 2372 do_compile (); Ultimately, the problem is two-fold: * cc1gm2 doesn't set main_input_filename (perhaps only with -fdump-system-exports, I haven't checked) * In the end, libiberty's lrealpath is called with lrealpath (NULL, NULL) which again calls strdup (NULL), leading to the SEGV. I couldn't find a clear indication if this is supported by the C standard, but even if I harden lrealpath to avoid strdup(NULL), I get more SEGVs later on in other places. So clearly the error is not setting main_input_filename. No idea why this happens for gm2 only or how to fix this, though.
[Bug modula2/101388] Unconditional use of __MAX_BAUD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2021-09-14 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #4 from Rainer Orth --- When I tried a fresh build on i386-pc-solaris2.11 yesterday, it turned out that the fix hadn't been complete: /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c: In function 'termios_GetFlag': /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c:877:27: error: '__MAX_BAUD' undeclared (first use in this function) 877 | *b = ((t->c_cflag & __MAX_BAUD) == __MAX_BAUD); | ^~ I'm attaching the patch that allowed me to finish the build.
[Bug modula2/101388] Unconditional use of __MAX_BAUD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 --- Comment #3 from Rainer Orth --- Created attachment 51458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51458=edit Missed part of patch
[Bug modula2/101391] Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 --- Comment #4 from Rainer Orth --- Created attachment 51457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51457=edit Additonal patch providing cgetopt_*
