[Bug c++/98030] error message for enum definition without ';' could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98030 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > s.cpp:1:1: note: (perhaps a semicolon is missing after the definition of ‘E’) > > so it says that. A fixit that can be used with all the fixit-related machinery would still be more useful though.
[Bug preprocessor/98021] #warning issues redundant diagnostic lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #7 from eggert at cs dot ucla.edu --- (In reply to Andreas Schwab from comment #5 and #6) > There can be comments > Also, the source may come from a different place than the directive. For the unusual case where the #warning line invokes preprocessor macros defined elsewhere, it would be OK to output the warning both before and after preprocessing (to help with debugging the warning machinery, presumably). (Comments might cause something similar, I suppose, though that's less important.) However, for the case that I mentioned where the #warning line just contains a string, the duplicate messages are confusing and redundant, and the duplication should be avoided in this more-typical case.
[Bug testsuite/98040] New: plugin.exp can't run individual .C tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98040 Bug ID: 98040 Summary: plugin.exp can't run individual .C tests Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Specifying a subset of plugin tests to run using the usual mechanism doesn't see to work as expected. For example, selecting just test with the *.C suffix runs none of them: $ make -C /build/gcc-master/gcc check-c++ RUNTESTFLAGS="plugin.exp" ... === g++ Summary === # of expected passes413 # of expected failures 2 /ssd/build/gcc-master/gcc/xg++ version 11.0.0 20201127 (experimental) (GCC) make[1]: Leaving directory '/ssd/build/gcc-master/gcc' make: Leaving directory '/ssd/build/gcc-master/gcc' But: $ make -C /build/gcc-master/gcc check-c++ RUNTESTFLAGS="plugin.exp=*.C" ... Running /src/gcc/master/gcc/testsuite/g++.dg/plugin/plugin.exp ... === g++ Summary === /ssd/build/gcc-master/gcc/xg++ version 11.0.0 20201127 (experimental) (GCC)
[Bug c++/98039] New: Member function template with dependent return type involving class's own name: wrong-mangling, accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98039
Bug ID: 98039
Summary: Member function template with dependent return type
involving class's own name: wrong-mangling,
accepts-invalid
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/qq7196
struct S {
template static void f(T);
template static auto h(T t)
-> decltype(S::f(t));
};
void test() {
S::h(42);
}
Here, GCC trunk mangles `S::h` as `_ZN1S1hIiEEDTclsrS_1ffp_EET_`, but both
Clang and ICC agree that the mangling should be
`_ZN1S1hIiEEDTclsr1SE1ffp_EET_`. I naively assume that this indicates a bug in
GCC's mangling.
_ZN1S1hIiEEDTclsrS_1ffp_EET_ has "S_" where
_ZN1S1hIiEEDTclsr1SE1ffp_EET_ has "1SE".
It gets worse: If you make `f` non-static, then GCC accepts this code even
though it is invalid. In that case, the mangled name of the `h` that is
(wrongly) called is
_ZN1S1hIiEEDTcldtdefpTsrS_1ffp_EET_
// https://godbolt.org/z/Kr1baT
struct S {
template void f(T);
template static auto h(T t)
-> decltype(S::f(t));
};
void test() {
S::h(42);
}
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #5 from Sam James --- I've also reported this to Apple as FB8919799 (and on openradar - why not? https://openradar.appspot.com/radar?id=4952611266494464).
[Bug c++/98038] ICE on invalid trying to recursively invoke a lambda object with operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038
--- Comment #1 from Alisdair Meredith ---
The following example code gives an internal compiler error, I suspect due to
the invalid attempt to call `operator()` recursively on the lambda object. Use
the -std=c++20 language flag:
#include
#include
#include
template
inline constexpr bool is_reference_wrapper_v = false;
template
inline constexpr bool is_reference_wrapper_v> = true;
template
constexpr
auto my_mem_fn(Fn T::*pmf) {
return [pmf](U&& p, ARGS&& ...args) ->
decltype(auto)
{
if constexpr(is_reference_wrapper_v>) {
return operator()(pmf, p.get(), std::forward(args)...);
}
else {
return 12;
}
};
}
struct Dummy {
constexpr int twelve() const { return 12; }
};
int main() {
Dummy x{};
auto y = my_mem_fn(::twelve);
int c = y(std::ref(x));
}
[Bug c++/98038] New: ICE on invalid trying to recursively invoke a lambda object with operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038 Bug ID: 98038 Summary: ICE on invalid trying to recursively invoke a lambda object with operator Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: ---
[Bug preprocessor/97602] #line overflow check incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97602 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Joseph S. Myers --- Fixed for GCC 11.
[Bug preprocessor/97602] #line overflow check incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97602 --- Comment #1 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:9ccffd1298b5235b25ad05b89e3104fb2935fe27 commit r11-5507-g9ccffd1298b5235b25ad05b89e3104fb2935fe27 Author: Joseph Myers Date: Fri Nov 27 22:40:01 2020 + preprocessor: Fix #line overflow check [PR97602] The preprocessor check for overflow (of linenum_type = unsigned int) when reading the line number in a #line directive is incomplete; it checks "reg < reg_prev" which doesn't cover all cases where multiplying by 10 overflowed. Fix this by checking for overflow before rather than after it occurs (using essentially the same logic as used by e.g. glibc printf when reading width and precision values from strings). Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ 2020-11-27 Joseph Myers PR preprocessor/97602 * directives.c (strtolinenum): Check for overflow before it occurs. Correct comment. gcc/testsuite/ 2020-11-27 Joseph Myers PR preprocessor/97602 * gcc.dg/cpp/line9.c, gcc.dg/cpp/line10.c: New tests.
[Bug target/98027] CET support is documented to be explicitly enabled, however it's enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98027 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #4 from mcccs at gmx dot com --- (In reply to Fabian Groffen from comment #3) > The problem with this snippet is that it doesn't work on Frameworks, does > it? At least for me, it seems it searches from usr/include only? I'm not sure but it sounds likely. Isn't usr/include the higher-priority #include <...> search directory?
[Bug d/98025] [11 Regression][CET] libphobos: dub segfaults when built with gdc 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Fixed committed.
[Bug d/98025] [11 Regression][CET] libphobos: dub segfaults when built with gdc 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:5dbab7b3f4d3a8298aeb8ecde1cfbc4b16913d28 commit r11-5506-g5dbab7b3f4d3a8298aeb8ecde1cfbc4b16913d28 Author: Iain Buclaw Date: Fri Nov 27 13:15:44 2020 +0100 libphobos: Fix segfault at run-time when using custom Fibers (PR 98025) When libphobos is configured with --enable-cet, this adds extra fields to the Fiber class to support the ucontext_t fallback implementation. These fields get omitted when compiling user code unless they also used `-fversion=CET' to build their project, which resulted in data being overwritten from within swapcontext(). On reviewing the ucontext_t definitions, it was found that the shadow stack fields were missing, and the struct size didn't match up on X32. This has been fixed in upstream druntime and merged down here. Reviewed-on: https://github.com/dlang/druntime/pull/3293 libphobos/ChangeLog: PR d/98025 * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac (DCFG_ENABLE_CET): Substitute. * libdruntime/MERGE: Merge upstream druntime 0fe7974c. * libdruntime/Makefile.in: Regenerate. * libdruntime/core/thread.d: Import gcc.config. (class Fiber): Add ucontext_t fields when GNU_Enable_CET is true. * libdruntime/gcc/config.d.in (GNU_Enable_CET): Define. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate.
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- It's much more interesting than a mere regression. Reduced and modified testcase: program p implicit none integer :: i character(*), parameter :: exprs(1) = ['abc()'] print *, (pack(exprs,exprs(:)(:1)=='a'),i=1,1) print *, (pack(exprs,exprs(:)(:1)=='a') ) end 7.4.1 gives: abc() a 8.4.1 and later give: a a Expected output: abc() abc()
[Bug tree-optimization/97424] Warn on invalid shift amount after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424 --- Comment #6 from Florian Weimer --- (In reply to David Malcolm from comment #5) > The above commit implements it as an analyzer warning. Should I close this > out, or should we keep it open for the __builtin_warning approach? Thanks for the analyzer warning. I think the __builtin_warning approach is very desirable here. To me, it looks like GCC already did all the work to figure out this undefined.
[Bug c++/96863] [9/10/11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 --- Comment #6 from Sergei Trofimovich --- In we see ICEs related to '[[no_unique_address]]' on chromium source code: https://bugs.gentoo.org/757150 (a variant of #c4 example).
[Bug c++/98031] missing the error message of undeclared label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98031 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is again diagnostics on uninstantiated template, invalid, no diagnostics required. Instantiate the template and it will be diagnosed.
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 --- Comment #21 from Jakub Jelinek --- Created attachment 49639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49639=edit gcc11-pr97459-alt.patch Variant version of the patch which avoids the final adjustment from unsigned to signed modulo by using different correction addend and signed modulo on the word. But it seems to have mixed effects, on i386 results in somewhat smaller code, but on x86_64 in larger code.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #25 from Toon Moene --- BTW, the speed difference between the native and the OpenMPI based program is staggering. For a 936x770x60 grid, the native run takes around 14 seconds elapsed time, while the OpenMPI based one takes 2 minutes on my 10 core x 2 hyperthreads Skylake machine.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #6 from ktkachov at gcc dot gnu.org --- Bisection shows it started with g:8d2d39587d941a40f25ea0144cceb677df115040
[Bug testsuite/98036] gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036 --- Comment #5 from Uroš Bizjak --- Oh... --cut here-- diff --git a/gcc/testsuite/gcc.target/i386/xop-hsubX.c b/gcc/testsuite/gcc.target/i386/xop-hsubX.c index f0fa9b312f2..dc7944d8bb7 100644 --- a/gcc/testsuite/gcc.target/i386/xop-hsubX.c +++ b/gcc/testsuite/gcc.target/i386/xop-hsubX.c @@ -58,6 +58,7 @@ check_sbyte2word () check_fails++; } } + return check_fails; } static int @@ -75,6 +76,7 @@ check_sword2dword () check_fails++; } } + return check_fails; } static int @@ -92,6 +94,7 @@ check_dword2qword () check_fails++; } } + return check_fails; } static void --cut here--
[Bug rtl-optimization/98037] ICE in dse.c:find_shift_sequence for large non-integer modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98037 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-27 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |10.3 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org
[Bug rtl-optimization/98037] New: ICE in dse.c:find_shift_sequence for large non-integer modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98037
Bug ID: 98037
Summary: ICE in dse.c:find_shift_sequence for large non-integer
modes
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following test on AArch64 with -march=armv8.2-a+sve
-msve-vector-bits=512:
-
typedef __SVInt8_t vec __attribute__((arm_sve_vector_bits(512)));
struct pair { vec v[2]; };
void use(pair &);
vec f(pair p) { vec v = p.v[1]; use(p); return v; }
-
triggers:
foo.c:4:51: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:356
4 | vec f(pair p) { vec v = p.v[1]; use(p); return v; }
| ^
... smallest_mode_for_size(poly_int<2u, unsigned long>, mode_class)
.../gcc/stor-layout.c:356
... smallest_int_mode_for_size(poly_int<2u, unsigned long>)
.../gcc/machmode.h:879
... find_shift_sequence
.../gcc/dse.c:1731
because there is no integer mode big enough to represent the
access size.
[Bug testsuite/98036] gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036
--- Comment #4 from Uroš Bizjak ---
Something is wrong in [printf added by me]:
static int
check_sword2dword ()
{
int i, j, s, t, check_fails = 0;
for (i = 0; i < (NUM * 8); i = i + 8)
{
for (j = 0; j < 4; j++)
{
t = i + (2 * j);
s = (i / 2) + j;
printf ("%i %i %i %i\n", i, j, s, t);
res.li[s] = src1.si[t] - src1.si[t + 1] ;
if (res.li[s] != dst.li[s])
check_fails++;
}
}
}
gcc -O2 -msse -m32
$ ./a.out
80 80 40 80
80 81 41 82
80 82 42 84
80 83 43 86
80 84 44 88
80 85 45 90
...
80 1006 966 1932
80 1007 967 1934
80 1008 968 1936
Segmentation fault (core dumped)
i and j should start from 0.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #37 from John David Anglin --- Created attachment 49638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49638=edit Fix for hppa-hpux
[Bug testsuite/98036] gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036 Uroš Bizjak changed: What|Removed |Added Last reconfirmed||2020-11-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- Program received signal SIGSEGV, Segmentation fault. 0x08049151 in check_sword2dword () at xop-hsubX.c:122 122 res.li[s] = src1.si[t] - src1.si[t + 1] ; (gdb) p s $3 = 968 (gdb) p t $4 = 1936 Huh? Works OK on 64bit target.
[Bug testsuite/98036] gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036 --- Comment #2 from Uroš Bizjak --- Created attachment 49637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49637=edit Testcase with emulated XOP instructions This testcase without XOP insns also fails with "-O2 -msse" on 32bit target.
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 Jakub Jelinek changed: What|Removed |Added Attachment #49634|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2020-11-27 --- Comment #20 from Jakub Jelinek --- Created attachment 49636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49636=edit gcc11-pr97459-wip.patch Updated patch that can also handle signed modulo.
[Bug target/98032] [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032
--- Comment #5 from Martin Liška ---
Reduced test-case:
$ cat vcldemo.ii
namespace osl {
class Thread {
public:
virtual ~Thread();
virtual void join();
};
} // namespace osl
class SimpleReferenceObject {
protected:
virtual ~SimpleReferenceObject();
};
class Thread : SimpleReferenceObject, osl::Thread {
public:
osl::Thread::join;
};
class RenderThread : Thread {
RenderThread() { join(); }
};
and a nice backtrace:
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B
/home/marxin/Programming/gcc2/objdir/gcc -O0 -Wall -fstack-protector-strong -c
vcldemo.ii
vcldemo.ii:14:3: warning: access declarations are deprecated in favour of
using-declarations; suggestion: add the ‘using’ keyword [-Wdeprecated]
14 | osl::Thread::join;
| ^~~
vcldemo.ii: In constructor ‘RenderThread::RenderThread()’:
vcldemo.ii:17:25: internal compiler error: Segmentation fault
17 | RenderThread() { join(); }
| ^
0xb2168f crash_signal
/home/marxin/Programming/gcc2/gcc/toplev.c:326
0x5b05d1 lookup_vfn_in_binfo(tree_node*, tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/class.c:2405
0x5a36d5 build_over_call
/home/marxin/Programming/gcc2/gcc/cp/call.c:8300
0x5a53ae build_new_method_call_1
/home/marxin/Programming/gcc2/gcc/cp/call.c:9913
0x5a5dbf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/marxin/Programming/gcc2/gcc/cp/call.c:9988
0x660cdd cp_parser_postfix_expression
/home/marxin/Programming/gcc2/gcc/cp/parser.c:7361
0x6480fa cp_parser_binary_expression
/home/marxin/Programming/gcc2/gcc/cp/parser.c:9461
0x648e17 cp_parser_assignment_expression
/home/marxin/Programming/gcc2/gcc/cp/parser.c:9759
0x649051 cp_parser_expression
/home/marxin/Programming/gcc2/gcc/cp/parser.c:9926
0x64bd25 cp_parser_expression_statement
/home/marxin/Programming/gcc2/gcc/cp/parser.c:11524
0x655d5d cp_parser_statement
/home/marxin/Programming/gcc2/gcc/cp/parser.c:11320
0x657488 cp_parser_statement_seq_opt
/home/marxin/Programming/gcc2/gcc/cp/parser.c:11667
0x657540 cp_parser_compound_statement
/home/marxin/Programming/gcc2/gcc/cp/parser.c:11621
0x66a3b0 cp_parser_function_body
/home/marxin/Programming/gcc2/gcc/cp/parser.c:22693
0x66a3b0 cp_parser_ctor_initializer_opt_and_function_body
/home/marxin/Programming/gcc2/gcc/cp/parser.c:22744
0x66d8dd cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc2/gcc/cp/parser.c:27873
0x66ea29 cp_parser_late_parsing_for_member
/home/marxin/Programming/gcc2/gcc/cp/parser.c:28760
0x6515e3 cp_parser_class_specifier_1
/home/marxin/Programming/gcc2/gcc/cp/parser.c:23693
0x6524cb cp_parser_class_specifier
/home/marxin/Programming/gcc2/gcc/cp/parser.c:23719
0x6524cb cp_parser_type_specifier
/home/marxin/Programming/gcc2/gcc/cp/parser.c:17462
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98032] [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032 Richard Biener changed: What|Removed |Added Keywords||needs-reduction --- Comment #4 from Richard Biener --- Needs reduction of a valid testcase.
[Bug target/98032] [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |9.4 --- Comment #3 from Richard Biener --- Hum. Can we have a better backtrace?
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #24 from Toon Moene --- And I can reproduce the GFORTRAN_NUM_IMAGES=64 segfault: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=64; echo ' nxglobal=936, nyglobal=770, nzglobal=60 / ' | ./a.out) Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fec7b252bd0 in ??? #1 0x7fec7b251e25 in ??? #2 0x7fec7af00cbf in ??? #3 0x7fec7b5377ae in shared_malloc at /home/toon/compilers/coarray_native/libgfortran/caf_shared/allocator.c:70 #4 0x7fec7b5374ab in get_memory_by_id_internal at /home/toon/compilers/coarray_native/libgfortran/caf_shared/alloc.c:75 #5 0x4141ed in random_weather at /home/toon/src/random-weather.f90:551 #6 0x7fec7b537c0a in image_main_wrapper at /home/toon/compilers/coarray_native/libgfortran/caf_shared/coarraynative.c:183 #7 0x415d2a in main at /home/toon/src/random-weather.f90:413 ERROR: Image 64(0x3a877f) failed after which message it hangs ... Notably, I did add a check on boundary relaxation zone size, so that cannot be the problem.
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #14 from Jonathan Wakely --- It looks like _stat and _wstat were fixed, but not _wstat64 which is what we use.
[Bug target/98027] CET support is documented to be explicitly enabled, however it's enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98027 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:9df6c9c7a3936ff0a38a7066281842128cdd6914 commit r11-5499-g9df6c9c7a3936ff0a38a7066281842128cdd6914 Author: H.J. Lu Date: Fri Nov 27 05:39:56 2020 -0800 INSTALL: Default to --enable-cet=auto PR other/98027 * doc/install.texi: Default to --enable-cet=auto.
[Bug testsuite/98036] gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036 Richard Biener changed: What|Removed |Added Target||i?86-*-* --- Comment #1 from Richard Biener --- Sofar only seen on i?86.
[Bug testsuite/98036] New: gcc.target/i386/xop-hsubX.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98036 Bug ID: 98036 Summary: gcc.target/i386/xop-hsubX.c is broken Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- It seems to quite reliably fail (you need XOP in the first place), easier with -O0. I'm not able to natively compile it (machine too old), but transfered objects linked there abort or segfault depending on optimization level.
[Bug target/98032] [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2020-11-27 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r9-9066-g19323ea3e9344eb773f8fe872eadbe4f1ac6461f.
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 Jonathan Wakely changed: What|Removed |Added Target Milestone|tree-ssa|9.4
[Bug target/98032] [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032 --- Comment #1 from Matthias Klose --- also works with the gcc-9 branch 20200911
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #13 from Jonathan Wakely ---
My fix for the trailing slash does:
#if _GLIBCXX_FILESYSTEM_IS_WINDOWS
#if ! defined __MINGW64_VERSION_MAJOR || __MINGW64_VERSION_MAJOR < 6
// stat() fails if there's a trailing slash (PR 1)
I'm seeing status("./") fail with mingw64 6.0.0 so apparently the workaround is
still needed.
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #12 from Jonathan Wakely --- *** Bug 98035 has been marked as a duplicate of this bug. ***
[Bug libstdc++/98035] filesystem::exists("./") fails on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98035 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Oh this is PR 1 again. *** This bug has been marked as a duplicate of bug 1 ***
[Bug libstdc++/98035] New: filesystem::exists("./") fails on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98035
Bug ID: 98035
Summary: filesystem::exists("./") fails on Windows
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
int main()
{
std::cout << std::filesystem::exists("./") << '\n';
std::cout << std::experimental::filesystem::exists("./") << '\n';
}
This prints two zeros.
The trailing slash is the problem.
[Bug libstdc++/98034] std::atomic_signed_lock_free and std::atomic_unsigned_lock_free not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98034 --- Comment #1 from Jonathan Wakely --- Also, we should probably be using a futex directly for unsigned, and for other types with the same size and alignment as int (e.g. long on ilp32 targets).
[Bug libstdc++/98034] New: std::atomic_signed_lock_free and std::atomic_unsigned_lock_free not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98034 Bug ID: 98034 Summary: std::atomic_signed_lock_free and std::atomic_unsigned_lock_free not defined Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: rodgertq at gcc dot gnu.org Target Milestone: --- C++20 adds these typedefs. For linux they should be atomic and atomic, because they can use futex for waiting and notifying. I don't know about other targets.
[Bug libstdc++/98033] New: ABA problem in atomic wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98033
Bug ID: 98033
Summary: ABA problem in atomic wait
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In __atomic_wait in include/bits/atomic_wait.h we have:
while (!__pred())
{
if constexpr (__platform_wait_uses_type<_Tp>)
{
__platform_wait(__addr, __old);
}
If the predicate is initially false (i.e. *addr == old) we enter the loop. If
the value changes before calling __platform_wait then that will return
immediately. If it then changes back to the old value the predicate will be
false again and we will re-enter the loop. This time __platform_wait will block
waiting for the value to change.
The standard says we're allowed to miss such transient values, and so the code
above is conforming. But I think we can make it work on linux for the
std::atomic_signed_lock_free type at least (which isn't defined, but should be
atomic).
If __platform_wait returned a boolean indicating whether the not-equal
condition was met (either because it was already true, the EAGAIN case, or
because the futex wait got woken up) then the caller could check that and not
re-check the predicate.
[Bug target/98032] New: [9 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98032
Bug ID: 98032
Summary: [9 Regression] ICE (segfault) on arm-linux-gnueabihf
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 49635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49635=edit
preprocessed source
seen with the gcc-9 branch 20201126 on arm-linux-gnueabihf, gives a correct
error message with the gcc-10 branch and the trunk. worked with the 9.3.0
release.
Also attaching the unreduced test case (which is valid code), therefor tagging
with ice-on-valid and ice-on-invalid.
gcc is configured with --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=hard --with-mode=thumb --enable-default-pie
$ cat vcldemo.ii
class Thread {
public:
virtual ~Thread();
virtual void join();
};
class SimpleReferenceObject {
protected:
virtual ~SimpleReferenceObject();
};
class Trans_NS_salhelper_Thread : SimpleReferenceObject, Thread {
public:
using Thread::join;
};
class RenderThread : Trans_NS_salhelper_Thread {
RenderThread() { join() }
};
$ g++-9 -c -std=c++17 -O0 -Wall -fstack-protector-strong vcldemo.ii
vcldemo.ii: In constructor 'RenderThread::RenderThread()':
vcldemo.ii:15:25: internal compiler error: Segmentation fault
15 | RenderThread() { join() }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
$ g++-10 -c -std=c++17 -O0 -Wall vcldemo.ii
vcldemo.ii: In constructor 'RenderThread::RenderThread()':
vcldemo.ii:15:26: error: expected ';' before '}' token
15 | RenderThread() { join() }
| ^~
| ;
[Bug c++/98031] New: missing the error message of undeclared label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98031
Bug ID: 98031
Summary: missing the error message of undeclared label
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Hi, the following code has two errors. However, gcc only reports the second
error while ignoring the first one.
$ cat s.cpp
template
int fun(T i)
{
static void* labs[2] = { &, & };
goto *(labs[i==0]);
lab1: return 1;
labs: return 2; //should report an error
return 0;
}
int main()
{ return lab1(1); } //error here
$ g++ -c s.cpp
s.cpp: In function ‘int main()’:
s.cpp:12:11: error: ‘lab1’ was not declared in this scope
12 | { return lab1(1); }
|
$ clang++ -c s.cpp
s.cpp:4:38: error: use of undeclared label 'lab2'
static void* labs[2] = { &, & };
^
s.cpp:12:11: error: use of undeclared identifier 'lab1'
{ return lab1(1); }
^
2 errors generated.
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 Jakub Jelinek changed: What|Removed |Added Attachment #49633|0 |1 is obsolete|| --- Comment #19 from Jakub Jelinek --- Created attachment 49634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49634=edit gcc11-pr97459-wip.patch The earlier patch was buggy, we can't really consider the bit 63 for 128-bit umod or 31 for 64-bit umod, because the sum of the 3 numbers like: 0x7fffULL + 0x7fffULL + 0x3ULL can overflow and unlike the bit 64 (or 32) case it would need more code to handle those 2 values where it overflowed. I'll see if I figure out how to do signed modulo too.
[Bug c++/98030] error message for enum definition without ';' could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98030 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- s.cpp:1:1: note: (perhaps a semicolon is missing after the definition of ‘E’) so it says that.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #36 from Eric Botcazou --- > The s390x build failure is still preset. Can you please take a look? This one looks unrelated to r11-4029 or other Ada changes. Do you know which revision has introduced it?
[Bug c++/98030] New: error message for enum definition without ';' could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98030
Bug ID: 98030
Summary: error message for enum definition without ';' could be
improved
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Hi, the following code misses a ';' at the end of the enum definition. GCC
reports an error with 'new types may not be defined', which may not be easily
understood by novices, while clang suggests the additional ';' could be better.
$ cat s.cpp
enum E {
e = 3,
} //miss a ';' here
int main() {
bool var1 = e;
bool var2 = 3;
}
$ g++ -c s.cpp
s.cpp:1:1: error: new types may not be defined in a return type
1 | enum E {
| ^~~~
s.cpp:1:1: note: (perhaps a semicolon is missing after the definition of ‘E’)
s.cpp:1:1: error: two or more data types in declaration of ‘main’
$ clang++ -c s.cpp
s.cpp:3:2: error: expected ';' after enum
}
^
;
1 error generated.
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-20201122/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-20201122/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11-20201122/configure --prefix=/usr/local/gcc-20201122
--enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201122 (experimental) (GCC)
[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Summary|volatile triggers incorrect |[11 Regression] volatile |"warning: right-hand|triggers incorrect |operand of comma expression |"warning: right-hand |has no effect |operand of comma expression |[-Wunused-value]" |has no effect ||[-Wunused-value]" since ||r11-5188-g32934a4f45a72144 Ever confirmed|0 |1 Last reconfirmed||2020-11-27 --- Comment #1 from Martin Liška --- Confirmed, started with r11-5188-g32934a4f45a72144.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #35 from Martin Liška --- (In reply to Martin Liška from comment #20) > Created attachment 49465 [details] > Build log for s390x Hello. The s390x build failure is still preset. Can you please take a look?
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #5 from Paul Sokolovsky ---
ktkac...@gcc.gnu.org:
Thanks for looking into this issue! Looking forward for the root cause to be
found. Given the minimized testcase which CReduce came to, my finger-in-the-sky
bet would be that it's a very fine case of data structure corruption, which
doesn't lead to segfault, but rather to infiniloop.
I'm saying that, because I tried to play with the minimized example myself, but
saw that most changes get rid of the issue. The only "simplifying" change I
could make which still leads to infiniloop is replace usage of the "h" enum
with "char" ("int" doesn't work). That makes declaration of the "h" enum
unused, and yet removal of it fixes the loop. That's why I say it looks like
very fine memory corruption, it's hard to imagine how unused enum declaration
can affect regalloc.
But then, I don't have experience with this stuff, and the setup is too
complicated for me to try. So again, thanks for looking into this.
[Bug c/98029] New: volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029
Bug ID: 98029
Summary: volatile triggers incorrect "warning: right-hand
operand of comma expression has no effect
[-Wunused-value]"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc (Debian 20201125-2) 11.0.0 20201125 (experimental) [master revision
a4d9837ee4b:97273aee415:b13dacdfb315675803982ad5a3098f7b55e6357a]
double f1 (void)
{
double d;
int i;
for (d = 2.0, i = 0; i < 5; i++, d *= d)
;
return d;
}
double f2 (void)
{
volatile double d;
int i;
for (d = 2.0, i = 0; i < 5; i++, d *= d)
;
return d;
}
yields the following incorrect warning when using "-Wunused-value":
tst.c: In function 'f2':
tst.c:17:10: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
17 | for (d = 2.0, i = 0; i < 5; i++, d *= d)
|~~^
Note that one gets a warning only for f2. The only difference is the
"volatile".
I found this when testing GNU MPFR (a similar code occurs in tests/tset_ld.c).
[Bug preprocessor/98021] #warning issues redundant diagnostic lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #6 from Andreas Schwab --- Also, the source may come from a different place than the directive.
[Bug tree-optimization/98024] [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/98024] [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b6a7b72c6c91cc0d800a603a59e96fbcb07793ba commit r11-5494-gb6a7b72c6c91cc0d800a603a59e96fbcb07793ba Author: Richard Biener Date: Fri Nov 27 12:01:25 2020 +0100 tree-optimization/98024 - fix rnflow regression The change to make PRE insertion iterate less had a typo in checking successors RPO state. Fixing this exposes that regular PRE insertion when facing a value that is the same on all edges inserts an assignment in place of a PHI node but fails to set up things so that this insertion is not repeated (it correctly does not return 'new_stuff'). But with the new iteration scheme this causes us to repeatedly insert such assignment and change AVAIL_OUT over to the newly inserted expression. The fix is to treat this as PHI and insert into PHI_GEN, avoiding repetitive insertion. 2020-11-27 Richard Biener PR tree-optimization/98024 * tree-ssa-pre.c (insert): Fix successor RPO order check. (do_pre_regular_insertion): When inserting an assignment in place of an all-same-value PHI still record that into PHI_GEN.
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- This is not a regression IMHO since the inquiry reference feature (ie. ...%re) was introduced by the commit reference in comment 1. That said, it does remove the syntax error for the non-existent feature with an ICE. Paul
[Bug tree-optimization/98024] [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Acked by LNT: https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.791.0=26.791.0=171.791.0
[Bug fortran/98023] ICE: free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-27 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Btw. started with r8-3056-g5bab4c9631c478b7.
[Bug gcov-profile/85201] [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85201 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #8 from Sunil Kumar --- Hi Jakub/Martin, In gcc version 7.4.0, The line #6 is marked as '-'. can you please confirm the gcc behaviour.
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 Martin Liška changed: What|Removed |Added Priority|P3 |P4 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Last reconfirmed||2020-11-27 Status|UNCONFIRMED |NEW Summary|ICE in |[9/10/11 Regression] ICE in |gfc_assign_data_value, at |gfc_assign_data_value, at |fortran/data.c:468 |fortran/data.c:468 since ||r9-3803-ga5fbc2f36a291cbe Target Milestone|--- |9.4 --- Comment #1 from Martin Liška --- Confirmed, started with r9-3803-ga5fbc2f36a291cbe.
[Bug preprocessor/98021] #warning issues redundant diagnostic lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #5 from Andreas Schwab --- > For '#warning "xxx"' they're the same That is not true. There can be comments.
[Bug target/98018] Option to force frame pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- About the IPA passes, it's likely quite close to -flive-patching=inline-only-static what we want here.
[Bug tree-optimization/98028] [8/9/10/11 Regression] __builtin_sub_overflow_p not folded to const when some constraints are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98028 Jakub Jelinek changed: What|Removed |Added Summary|__builtin_sub_overflow_p|[8/9/10/11 Regression] |not folded to const when|__builtin_sub_overflow_p |some constraints are known |not folded to const when ||some constraints are known Last reconfirmed||2020-11-27 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |8.5 CC||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- f1 changed with r8-2630-g0db8ddfcb660397bab428ce0d271967d24c23177, until then dom propagated one of those SSA_NAMEs, so we ended up with __builtin_sub_overflow_p (i, i, (unsigned) 0) which we can still even on the trunk optimize. Anyway, I guess all this is a task for the symbolic value ranges in the ranger.
[Bug gcov-profile/85349] [GCOV] struct varaible definition in while(1) will cause incorrect coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85349 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #5 from Sunil Kumar --- For first braces of while loop is marked as '-' and for second while loop also same in gcc version 7.4.0. Please can you confirm the gcc behaviour.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #12 from Jonathan Wakely --- This one still fails sometimes on Solaris: FAIL: 30_threads/semaphore/try_acquire_until.cc execution test
[Bug gcov-profile/85276] [GCOV] A comparative statement with '=', '&&' , '||', and '==' operators is wrongly marked as executed twice in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85276 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #6 from Sunil Kumar --- Line #3 is properly marked as executed once in gcc verion 7.4.0. Please let me know your opinion.
[Bug d/98025] [11 Regression][CET] libphobos: dub segfaults when built with gdc 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Target Milestone|--- |11.0
[Bug tree-optimization/98026] optimization dependant on condition order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026 Richard Biener changed: What|Removed |Added Blocks||85316 --- Comment #1 from Richard Biener --- This is because symbolic range handling sometimes throws away the symbolic equivalence I think. OTOH we have equivalences for this (but they are not always used, and with ranger all but the symbolic cases can be handled with multi-entry ranges) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/98028] New: __builtin_sub_overflow_p not folded to const when some constraints are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98028
Bug ID: 98028
Summary: __builtin_sub_overflow_p not folded to const when some
constraints are known
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
According to godbolt, f1 used to be optimised with gcc 7.
The same problem can be seen with signed types (and maybe more conditions?).
All the following functions should be only one instruction plus ret with O2
-
unsigned f1(unsigned i, unsigned j) {
if (j != i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f2(unsigned i, unsigned j) {
if (j > i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f3(unsigned i, unsigned j) {
if (j >= i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f4(unsigned i, unsigned j) {
if (j < i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
-
[Bug target/98027] CET support is documented to be explicitly enabled, however it's enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98027 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||documentation Last reconfirmed||2020-11-27 Status|UNCONFIRMED |NEW Component|other |target Target||x86_64-*-* i?86-*-* --- Comment #1 from Richard Biener --- I think support is autodetected now. HJ, can you adjust the wording?
[Bug gcov-profile/85225] [GCOV] An array reference in the for(;;) loop will lead the loop has incorrect execution times in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85225 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #6 from Sunil Kumar --- Executed same code in gcc version 7.4.0, The line #3 is marked as '-'. The coverage count for infinite loop is not detected
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bf0a63a1f47525d1c466dbb84616dcb72010affa commit r11-5490-gbf0a63a1f47525d1c466dbb84616dcb72010affa Author: Jakub Jelinek Date: Fri Nov 27 11:23:45 2020 +0100 gimple-fold: Fix another __builtin_clear_padding ICE When playing with __builtin_bit_cast, I have noticed __builtin_clear_padding ICE on the G class below. The artificial field with D type has offset 0 and size 8 bytes, but the following artificial field with E type has offset 0 and size 0, so it triggers the asserts that we don't move current position backwards. Fixed by ignoring is_empty_type (TREE_TYPE (field)) fields, all of their bits are padding which is what is added when skipping over to next field anyway. 2020-11-27 Jakub Jelinek PR libstdc++/88101 * gimple-fold.c (clear_padding_type): Ignore fields with is_empty_type types. * g++.dg/torture/builtin-clear-padding-3.C: New test.
[Bug c/97880] [8/9/10/11 Regression] [OpenACC] ICE in emit_library_call_value_1, at calls.c:5298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97880 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:f324479caf0ac326534f4fcf72cb12991ccddb3d commit r11-5489-gf324479caf0ac326534f4fcf72cb12991ccddb3d Author: Tobias Burnus Date: Fri Nov 27 11:17:50 2020 +0100 OpenACC: Fix integer-type issue with collapse/tile [PR97880] gcc/ChangeLog: PR c/97880 * omp-expand.c (expand_oacc_collapse_init, expand_oacc_collapse_vars): Use now passed diff_type. (expand_oacc_for): Take largest type for diff_type, taking tiling and collapsing into account. gcc/testsuite/ChangeLog: PR c/97880 * gcc.dg/goacc/tile-1.c: New test.
[Bug other/98027] New: CET support is documented to be explicitly enabled, however it's enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98027
Bug ID: 98027
Summary: CET support is documented to be explicitly enabled,
however it's enabled by default
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
CET support is documented to be explicitly enabled, however it's enabled by
default.
install.texi reads:
@item --enable-cet
@itemx --disable-cet
Enable building target run-time libraries with control-flow
instrumentation, see @option{-fcf-protection} option. When
@code{--enable-cet} is specified target libraries are configured
to add @option{-fcf-protection} and, if needed, other target
specific options to a set of building options.
The option is disabled by default. When @code{--enable-cet=auto}
is used, it is enabled on Linux/x86 if target binutils
supports @code{Intel CET} instructions and disabled otherwise.
In this case the target libraries are configured to get additional
@option{-fcf-protection} option.
however it's still enabled when no --enable-/--disable-cet configure options is
given.
Please either update the documentation or the behavior. Seems to be the case
for the gcc-10 branch as well.
unreleated question: when do you configure with -fcf-protection -mshstk, and
when just with -fcf-protection?
[Bug gcov-profile/90066] [GCOV] function with inline attribute leading to incorrect coverage for the "if" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90066 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #2 from Sunil Kumar --- Without uncommenting line #15, The line #14 is marked as executed once in gcc version 7.4.0. Is that issue available in 8.2.0 and later verison.
[Bug tree-optimization/98026] New: optimization dependant on condition order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
Bug ID: 98026
Summary: optimization dependant on condition order
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In all the following functions gcc should recognize that j can't be greater
than 100, and link_error should not appear in assembly. Currently only f3 is
optimized.
---
void link_error();
void f1(int i, int j) {
if (j > i || i > 100) return;
if (j > 100) link_error();
}
void f2(int i, int j) {
if (i > 100 || j > i) return;
if (j > 100) link_error();
}
void f3(int i, int j) {
if (i > 100) return;
if (j > i) return;
if (j > 100) link_error();
}
void f4(signed int i,unsigned int j) {
if (i > 100) return;
if (j > i) return;
if (j > 100) link_error();
}
--
[Bug gcov-profile/85336] [GCOV] wrong coverage for builtin functions and "||" logic operators in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85336 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #6 from Sunil Kumar --- In gcc version 7.4.0, Line #6, #7, #8, #9 are marked as 2, 2, 3, 2. Can you confirm me how line #7 got executed 3 times
[Bug tree-optimization/98024] [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 --- Comment #2 from Richard Biener --- Stupid typo. Meh.
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 --- Comment #8 from Vincent Lefèvre --- But note that there is no issue with -fsanitize=undefined on return i - (-4096); So the cause is the transformation of i + 4096 to i - (-4096).
[Bug gcov-profile/85199] [GCOV] A cond-expr with a iterative variable in a for loop is marked as "-" in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85199 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #6 from Sunil Kumar --- In gcc version 7.4.0 line #4, #5 and #6 are marked as executed 1,2 and '-'. Please let me know your comment.
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 --- Comment #7 from Vincent Lefèvre --- For i + 4095: add %g1, 4095, %g1 For i + 4096: sub %g1, -4096, %g1 For i + 4097: sethi %hi(4195328), %g1 srlx%g1, 10, %g1 add %g2, %g1, %g1 SPARC can handle immediate signed constants directly up to 13 bits. For the positive ones, that's up to 4095. If one wants to add 4096 or more, one has to use sethi. But to add 4096, there is a specific optimization: subtract -4096, since this constant fits in 13 bits (two's complement).
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #16 from rsandifo at gcc dot gnu.org
---
> 2) mad2.c
>
> float foo (double x, float y, float z)
> {
>return ( y * fabs (x) + z );
> }
>
>
> mad2.c.098t.cunrolli:
>
> foo (double x, float y, float z)
> {
> double _1;
> double _2;
> double _3;
> double _4;
> double _5;
> float _9;
>
>[local count: 1073741824]:
> _1 = (double) y_6(D);
> _2 = ABS_EXPR ;
> _3 = _1 * _2;
> _4 = (double) z_8(D);
> _5 = _3 + _4;
> _9 = (float) _5;
> return _9;
>
> }
>
> mad2.c.099t.backprop:
>
> [USE] _9 in return _9;
> [USE] _5 in _9 = (float) _5;
> _5: convert from float to double not important
> [DEF] Recording new information for _5 = _3 + _4;
> _5: convert from float to double not important
> [USE] _4 in _5 = _3 + _4;
> _4: convert from float to double not important
> [DEF] Recording new information for _4 = (double) z_8(D);
> _4: convert from float to double not important
> [USE] _3 in _5 = _3 + _4;
> _3: convert from float to double not important
> [DEF] Recording new information for _3 = _1 * _2;
> _3: convert from float to double not important
> [USE] _2 in _3 = _1 * _2;
> _2: convert from float to double not important
> [DEF] Recording new information for _2 = ABS_EXPR ;
> _2: convert from float to double not important
> [USE] _1 in _3 = _1 * _2;
> _1: convert from float to double not important
> [DEF] Recording new information for _1 = (double) y_6(D);
> _1: convert from float to double not important
>
> Deleting _4 = (double) z_8(D);
> Deleting _1 = (double) y_6(D);
>
>
> EMERGENCY DUMP:
>
> __attribute__((noinline))
> foo (double x, float y, float z)
> {
> double _2;
> double _3;
> double _5;
> float _9;
>
>[local count: 1073741824]:
> _2 = ABS_EXPR ;
> _3 = _2 * y_6(D);
> _5 = _3 + z_8(D);
> _9 = (float) _5;
> return _9;
>
> }
Maybe I'm misunderstanding the point, but isn't this
just an issue with the way that the results of the
analysis are applied to the IL, rather than a problem
in the analysis itself?
[Bug d/98025] New: [11 Regression][CET] libphobos: dub segfaults when built with gdc 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025 Bug ID: 98025 Summary: [11 Regression][CET] libphobos: dub segfaults when built with gdc 11 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Following on from pr95680, the layout of the Fiber class changes when libphobos is built with -fversion=CET. This breaks user code that implement their own fibers based off core.thread unless they also compile with -fversion=CET as well. So when libphobos is compiled with --enable-cet, this needs to be also recorded in gcc.config to persist in the ABI. Not just as an internal implementation detail.
[Bug gcov-profile/85206] [GCOV] a return statement in the body of for(;0;) loop is wrongly marked as executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85206 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #3 from Sunil Kumar --- No malfunction is detected in gcc version 7.4.0
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #6 from Eric Botcazou ---
> Not sure how useful this is but all of the following toss the same ICE :
>
> long f(long arg){return arg + 4096;}
>
> long f(long arg){return arg - 4096;}
>
> long f(long arg){return 4096 + arg;}
>
> long f(long arg){return arg - 4096;}
>
> However these work fine :
>
> long f(long arg){return 4096 - arg;}
>
> long f(long arg){return arg * 4096;}
>
> long f(long arg){return 4096 * arg;}
>
> long f(long arg){return arg / 4096;}
>
> etc etc etc as well as other powers of 2.
It's specific to 4096 and additive operations. A look at the assembly
generated for the first 4 without -fsanitize=undefined may give a hunch about
what happens.
[Bug gcov-profile/90023] The coverage of a label is incorrect when it is after a return statement and followed by a blank statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90023 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #2 from Sunil Kumar --- In gcc version 7.4.0 line #10 is marked as executed once and still block with empty case is marked as executed once.
[Bug gcov-profile/90104] [GCOV] Wrong coverage for calling a function with variable arguments when they are embedded in a inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90104 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #2 from Sunil Kumar --- Line #9 is correctly marked as executed once in gcc 7.4.0. Please let us know your comment.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #23 from Toon Moene --- The segfault at GFORTRAN_NUM_IMAGES=64 might be due to the fact that the program doesn't contain a check whether the size of the boundary relaxation zone (currently set to 4) is too large for the slabs. The boundary relaxation is programmed under the assumption that the size of a slab >= 4x4. If that's the problem, it should go away by setting the size to 3 or 2 (or use a larger domain than horizontally 72 x 70). The current version of the program can be found at: http://moene.org/~toon/random-weather
[Bug tree-optimization/98024] [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-27 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/98024] New: [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98024 Bug ID: 98024 Summary: [11 Regression] Big rnflow regression caused by g:512c6ba04102295fccc62a173ee0086ca733c920 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The rev. caused runtime for Polyhedron rnflow to regress from 7s to 13s.
