[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404
--- Comment #14 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #9)
> valgrind says there is use of uninitialized variable:
I picked _gcov.c and minimized it's unstable compilation under cvise. Then
minimized it under presence of warnings related to var-tracking. Here is the
minimized example:
$ cat _gcov.c
int a;
int b(void) {
for (;;)
for (; a;)
for (unsigned c; c < b; c++)
;
}
$ valgrind --trace-children=yes --track-origins=yes --num-callers=50 --quiet
stage3-gcc/xgcc -Bstage3-gcc -O2 -g -o _gcov-s3.S -DL_gcov -S _gcov.c
==913420== Conditional jump or move depends on uninitialised value(s)
==913420==at 0xDBDABB: vt_find_locations() (in
/home/slyfox/tmp/portage/sys-devel/gcc-11.0.0_pre/work/build/stage3-gcc/cc1)
...
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #16 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:e41da82345fb01c4c2641c979a94a975d15312ab commit r11-2487-ge41da82345fb01c4c2641c979a94a975d15312ab Author: Paul Thomas Date: Sun Aug 2 10:35:36 2020 +0100 This patch fixes PR96325. See the explanatory comment in the testcase. 2020-08-02 Paul Thomas gcc/fortran PR fortran/96325 * primary.c (gfc_match_varspec): In the case that a component reference is added to an intrinsic type component, emit the error message in this function. gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: New test. * gfortran.dg/pr91589.f90: Update error message.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #19 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:a5baf71b0a5bd79923c095cf81218b8194008f60 commit r11-2489-ga5baf71b0a5bd79923c095cf81218b8194008f60 Author: Paul Thomas Date: Sun Aug 2 10:57:59 2020 +0100 This patch fixes PR96320. See the explanatory comment in the testcase. 2020-08-01 Paul Thomas gcc/fortran PR target/96320 * interface.c (gfc_check_dummy_characteristics): If a module procedure arrives with assumed shape in the interface and deferred shape in the procedure itself, update the latter and copy the lower bounds. gcc/testsuite/ PR target/96320 * gfortran.dg/module_procedure_4.f90 : New test.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #20 from Paul Thomas --- (In reply to CVS Commits from comment #19) > The master branch has been updated by Paul Thomas : > > https://gcc.gnu.org/g:a5baf71b0a5bd79923c095cf81218b8194008f60 > > commit r11-2489-ga5baf71b0a5bd79923c095cf81218b8194008f60 > Author: Paul Thomas > Date: Sun Aug 2 10:57:59 2020 +0100 > > This patch fixes PR96320. See the explanatory comment in the testcase. > > 2020-08-01 Paul Thomas > > gcc/fortran > PR target/96320 > * interface.c (gfc_check_dummy_characteristics): If a module > procedure arrives with assumed shape in the interface and > deferred shape in the procedure itself, update the latter and > copy the lower bounds. > > gcc/testsuite/ > PR target/96320 > * gfortran.dg/module_procedure_4.f90 : New test. 'target' has been replaced with 'fortran' in the ChangeLog commit :-) Paul
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404
--- Comment #15 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #14)
> (In reply to Sergei Trofimovich from comment #9)
> > valgrind says there is use of uninitialized variable:
>
> I picked _gcov.c and minimized it's unstable compilation under cvise. Then
> minimized it under presence of warnings related to var-tracking. Here is the
> minimized example:
>
> $ cat _gcov.c
> int a;
> int b(void) {
> for (;;)
> for (; a;)
> for (unsigned c; c < b; c++)
> ;
> }
>
> $ valgrind --trace-children=yes --track-origins=yes --num-callers=50 --quiet
> stage3-gcc/xgcc -Bstage3-gcc -O2 -g -o _gcov-s3.S -DL_gcov -S _gcov.c
>
> ==913420== Conditional jump or move depends on uninitialised value(s)
> ==913420==at 0xDBDABB: vt_find_locations() (in
> /home/slyfox/tmp/portage/sys-devel/gcc-11.0.0_pre/work/build/stage3-gcc/
> cc1)
> ...
The following patch seems to fix use of uninitialized variable:
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -7089,20 +7089,21 @@ vt_find_locations (void)
auto_vec > toplevel_scc_extents;
int n = rev_post_order_and_mark_dfs_back_seme
(cfun, single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun)), exit_bbs, true,
rc_order, &toplevel_scc_extents);
for (i = 0; i < n; i++)
bb_order[rc_order[i]] = i;
in_worklist = sbitmap_alloc (last_basic_block_for_fn (cfun));
in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun));
bitmap_clear (in_worklist);
+ bitmap_clear (in_pending);
/* We're performing the dataflow iteration independently over the
toplevel SCCs plus leading non-cyclic entry blocks and separately
over the tail. That ensures best memory locality and the least
number of visited blocks. */
unsigned extent = 0;
int curr_start = -1;
int curr_end = -1;
do
{
Don't know if the change correct or papers over the problem. Looking at the
initialization of 'in_pending' right below it does not seem to assume full
'in_pending' initialization.
I'll check if it fixes bootstrap for me.
[Bug debug/96417] New: c++ `using` causes massive debug-info bloat (debug-info is kept for types/symbols)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96417 Bug ID: 96417 Summary: c++ `using` causes massive debug-info bloat (debug-info is kept for types/symbols) Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: sagebar at web dot de Target Milestone: --- Created attachment 48982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48982&action=edit Compile me with and without -DNO_USING It appears as though the c++ `using` keyword prevents - `-feliminate-unused-debug-symbols` and - `-feliminate-unused-debug-types` from working for the associated symbol/type. As such, any use of c++'s `using` causes debug information to be generated, even if (in the case of symbols) the associated object doesn't appears as an addressible entity in generated object files, or are ever even used. As a demonstration, you may compile the attached file as: $ g++ -g -S -o - demo.cc | grep imported_ .string "_ZN1a17imported_functionEi" .string "imported_function" .string "imported_type" $ g++ -g -S -o - demo.cc -DNO_USING | grep imported_ Note that only `using ns::symbol;` is affected by this, but `using namespace ns;` works just fine. In addition to g++9.3.0, I was also able to reproduce the same problem on g++9.1.0 and g++5.4.0, meaning that this must have been going on for ages. - So long as a matter of fact that I'm wondering if there's some ABI mandate that requires this kind of behavior??? In case there is some kind of weird, non-sensical ABI requirement that requires debug information to always be generated for c++ using declarations, I'd like to request a commandline option to work around this, as I'm working on a program that's currently 4MiB actual text+data, and 6MiB debug info (and that is with already using -gz=zlib)
[Bug fortran/96102] ICE in check_host_association, at fortran/resolve.c:5994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 48983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48983&action=edit Proposed patch for the PR Steve's proposed patch caused regressions in host_assoc_function_[1,2].f90. This one regtests OK. I don't know if the gcc_assert needs to be retained or not. I will go through all the possible cases that can arrive here. If the only one is caught by the condition above, then the assert can go as can the second and third lines in the condition. Paul
[Bug lto/96385] [8/9/10/11 Regression] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 H.J. Lu changed: What|Removed |Added Summary|GCC generates separate |[8/9/10/11 Regression] GCC |debug info with undefined |generates separate debug |symbols without relocations |info with undefined symbols ||without relocations --- Comment #11 from H.J. Lu --- GCC 7.3.1 is OK: [hjl@gnu-cfl-2 pr26324]$ make /usr/gcc-7.3.1-x32/bin/gcc -B./ -O2 -g -flto -ffat-lto-objects -c -o pr26324a.o pr26324a.c /usr/gcc-7.3.1-x32/bin/gcc -B./ -O2 -g -fPIC -c -o pr15146c.o pr15146c.c /usr/gcc-7.3.1-x32/bin/gcc -B./ -O2 -g -fPIC -c -o pr15146b.o pr15146b.c /usr/gcc-7.3.1-x32/bin/gcc -B./ -shared -o pr15146b.so pr15146b.o /usr/gcc-7.3.1-x32/bin/gcc -B./ -shared -o pr15146c.so pr15146c.o pr15146b.so /usr/gcc-7.3.1-x32/bin/gcc -B./ -O2 -g -o x -Wl,-R,. \ -Wl,--no-copy-dt-needed-entries -Wl,--no-as-needed pr26324a.o pr15146c.so ./x PASS [hjl@gnu-cfl-2 pr26324]$
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #16 from Sergei Trofimovich --- Sent https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551174.html for review. > I'll check if it fixes bootstrap for me. The patch fixed gcc bootstrap for me.
[Bug fortran/82375] PDT components in PDT declarations fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82375 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #8 from José Rui Faustino de Sousa --- Hi all! Still ICEs using -fcheck=bounds Due to the bounds check the symbol gets added to the deferrdd symbols list (tlink) and then gfc_trans_deferred_vars calls gfc_check_pdt_dummy and an infinite loop is created due to the recursion into the PDT components in structure_alloc_comps. This seems to be enough to reproduce: subroutine push_8 (self) type link(mat_len) integer, len :: mat_len type (link(:)), allocatable :: next end type link type (link(:)), allocatable :: self integer :: i i = self%mat_len print *, i end subroutine push_8 Thank you very much. Best regards, José Rui
[Bug fortran/96418] New: Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 Bug ID: 96418 Summary: Test coarray_alloc_comp_4.f08 ICEs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi all! Test coarray_alloc_comp_4.f08 ICEs if using -fcoarray=single instead of -fcoarray=lib. Thank you very much. Best regards, José Rui
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #17 from David Edelsohn --- The patch fixes bootstrap for AIX.
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 --- Comment #1 from José Rui Faustino de Sousa --- And coarray_alloc_comp_3.f08 too. Best regards, José Rui
[Bug c++/96419] New: Constant propoagation works on global variable, but not in a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96419
Bug ID: 96419
Summary: Constant propoagation works on global variable, but
not in a function
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: milasudril at gmail dot com
Target Milestone: ---
I tried to implement a map-like data structure, with compile-time keys:
#include
#include
#include
namespace fixed_flatmap_detail
{
template
constexpr auto sort(std::array const& x, Compare const& compare)
{
auto tmp = x;
std::ranges::sort(tmp, compare);
return tmp;
}
}
template>
class FixedFlatmap
{
public:
using key_type = std::remove_reference_t;
using value_type = Value;
static constexpr auto size() { return std::size(Keys::items); }
static constexpr auto const keys() { return s_keys; }
constexpr auto const values() const { return m_vals; }
constexpr auto values() { return m_vals; }
constexpr auto find(key_type const& key) const
{
auto i = std::ranges::lower_bound(s_keys, key, Compare{});
if(i != std::end(s_keys) && !Compare{}(key, *i)) [[likely]]
{
return std::begin(m_vals) + (i - std::begin(s_keys));
}
return static_cast(nullptr);
}
constexpr auto find(key_type const& key)
{
return const_cast(std::as_const(*this).find(key));
}
private:
static constexpr auto s_keys = fixed_flatmap_detail::sort(Keys::items,
Compare{});
std::array m_vals;
};
struct KeyStruct
{
static constexpr std::array items{"Foo", "Bar",
"Kaka"};
};
FixedFlatmap my_vals{};
auto this_value_is_computed_at_compile_time = my_vals.find("Kaka");
int* test_lookup(FixedFlatmap& vals)
{
return vals.find("Foo"); // == static_cast(static_cast(&vals)
+ sizeof(int))
}
Interestingly gcc succeeds to compute `find` on a global variable, but fails as
soon as the same structure is allocated in a function. I am not an expert in
compilers, but realize that it could be trickier to compute it on a non-global
object (base address is not known at compile-time). However, the binary search
does not even use *this. Thus, `std::lower_bound` and outcome validation should
be possible to compute.
Godbolt: https://gcc.godbolt.org/z/c7E3P9
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404
--- Comment #18 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:6e46b3f3da5c03bc529b3690dd0995927feb9142
commit r11-2491-g6e46b3f3da5c03bc529b3690dd0995927feb9142
Author: Sergei Trofimovich
Date: Sun Aug 2 12:03:55 2020 +0100
var-tracking: fix uninitialised use of 'in_pending' [PR96404]
r11-2447-g:1212cfad093 ("Improve var-tracking dataflow
iteration order") changed 'in_pending' initialization
from:
in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun));
bitmap_ones (in_pending);
to more complex partial bit population algorithm. Due to presence
of uninitialized bits gcc started injecting extra debug entries
in seemigly arbitrary locations and started failing stage2/stage3
bootstrap comparison.
valgrind detected unilitialized bits as:
Conditional jump or move depends on uninitialised value(s)
at 0xDBED3B: vt_find_locations() (var-tracking.c:7230)
by 0xDBF2FB: variable_tracking_main_1() (var-tracking.c:10519)
...
Uninitialised value was created by a heap allocation
at 0x483779F: malloc (vg_replace_malloc.c:307)
by 0x14EE80B: xmalloc (xmalloc.c:147)
by 0x14911F9: sbitmap_alloc(unsigned int) (sbitmap.c:51)
...
The fix explicitly initializes 'in_pending' bitmap with zeros.
2020-08-02 Sergei Trofimovich
gcc/
PR bootstrap/96404
* var-tracking.c (vt_find_locations): Fully initialize
all 'in_pending' bits.
[Bug bootstrap/96404] [11 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Summary|[10 Regression] Bootstrap |[11 Regression] Bootstrap |failure |failure Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #19 from Sergei Trofimovich --- Should be fixed now. I tweaked bug subject to point at gcc-11 as the only affected version (I assume gcc-10 works).
[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Bug 96383 depends on bug 96404, which changed state. Bug 96404 Summary: [11 Regression] Bootstrap failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/96420] New: -Wsign-extensions warnings are generated from system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96420
Bug ID: 96420
Summary: -Wsign-extensions warnings are generated from system
header macros
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Gcc doesn't silence -Wsign-conversion warnings in the expansion of
system-header macros (e.g., in the expansion of Musl's/Cygwin's FD_SET) unlike
other warnings in system-header macros.
E.g.,
#include
void f(int X)
{
fd_set set;
FD_ZERO(&set);
FD_SET(X,&set);
FD_CLR(X+1,&set);
(void)FD_ISSET(X+2,&set);
}
generates -Wsign-conversion warnings when compiled with musl-gcc or with gcc on
Cygwin.
Arguably, this should be fixed in the respective c libs, but the treatment of
-Wsign-conversion in system-header macro expansion does seem inconsistent with
that of other warnings in that context.
[Bug c++/96412] format suggestion issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96412 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2020-08-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Confirmed. If the conversion specification is "%d" it still recommends %ld for size_t.
[Bug c/96421] New: missing __builtin_ia32_pand256 in X86 AVX2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96421
Bug ID: 96421
Summary: missing __builtin_ia32_pand256 in X86 AVX2 intrinsics
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.c
#include
#include
#include
/*
static __v4di __builtin_ia32_pand256 (__v4di a, __v4di b)
{
__v4di r;
__asm__ ("vpand %1, %2, %0" : "=x" (r) : "x" (a), "x" (b));
return r;
}
*/
int main ()
{
__v4di a, b, n, o, x;
memset (&a, 3, sizeof (a));
memset (&b, 5, sizeof (b));
n = __builtin_ia32_pand256 (a, b);
o = __builtin_ia32_por256 (a, b);
x = __builtin_ia32_pxor256 (a, b);
printf ("%x %x %x\n", *(int *) &n, *(int *) &o, *(int *) &x);
};
% gcc -mavx2 test.c
test.c: In function 'main':
test.c:21:7: warning: implicit declaration of function
'__builtin_ia32_pand256'; did you mean '__builtin_ia32_pabsd256'?
[-Wimplicit-function-declaration]
n = __builtin_ia32_pand256 (a, b);
^~
__builtin_ia32_pabsd256
test.c:21:5: error: incompatible types when assigning to type '__v4di' {aka
'__vector(4) long long int'} from type 'int'
n = __builtin_ia32_pand256 (a, b);
^
There are 256 bit variants of "or" and "xor", but "and" is missing. I don't see
a reason why; they look very similar.
It can be added as shown in the commented out code, though that's not quite as
efficient as a built-in (e.g. no constant folding).
[Bug bootstrap/96422] New: [11 regression] Comparison failure in some 32-bit libgomp PIC objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96422 Bug ID: 96422 Summary: [11 regression] Comparison failure in some 32-bit libgomp PIC objects Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: amd64-pc-solaris2.11, i386-pc-solaris2.11 Between 20200730 (561a19c3011f7bde3a41f2a27ea979118e3a2dff) and 20200731 (ed0b4bb29a50d6be0e4b6411b3cc9f22967f1313), Solaris/x86 bootstrap began to fail: I'm seeing several comparison failures: Bootstrap comparison failure! i386-pc-solaris2.11/libgomp/.libs/task.o differs i386-pc-solaris2.11/libgomp/.libs/target.o differs i386-pc-solaris2.11/libgomp/.libs/oacc-mem.o differs i386-pc-solaris2.11/libgomp/.libs/oacc-init.o differs i386-pc-solaris2.11/libgomp/.libs/oacc-parallel.o differs They only affect the 32-bit PIC objects, both for 32-bit-default and 64-bit-default builds. However, this only happens when the native assembler is used; bootstraps with gas work fine. I haven't done much analysis yet. However, for the smallest of the files Solaris elfdiff shows: $ elfdiff -e oacc-parallel.o.stage? *** section: [11].debug_info: data information differs < 0x1d11: \01 s \12 s \07 \0 \0 \1a \0d \0 \0 F \08 \17 \0 \0 > 0x1d11: \01 s \12 s \07 \0 \0 \0e \0d \0 \0 F \08 \17 \0 \0 *** section: [13].debug_loc: shdr information differs < sh_size: 0xf54 sh_type:[ SHT_PROGBITS ] > sh_size: 0xf48 sh_type:[ SHT_PROGBITS ] *** section: [13].debug_loc: data information differs < 0xcb9: \01 \0 \0 \02 \0 3 \9f p \01 \0 \0 \9e \01 \0 \0 \02 > 0xcb9: \01 \0 \0 \02 \0 3 \9f z \01 \0 \0 \9e \01 \0 \0 \02 It seems plausible that this patch 2020-07-31 Richard Biener PR debug/96383 * langhooks-def.h (lhd_finalize_early_debug): Declare. (LANG_HOOKS_FINALIZE_EARLY_DEBUG): Define. (LANG_HOOKS_INITIALIZER): Amend. * langhooks.c: Include cgraph.h and debug.h. (lhd_finalize_early_debug): Default implementation from former code in finalize_compilation_unit. * langhooks.h (lang_hooks::finalize_early_debug): Add. * cgraphunit.c (symbol_table::finalize_compilation_unit): Call the finalize_early_debug langhook. is the culprit.
[Bug bootstrap/96422] [11 regression] Comparison failure in some 32-bit libgomp PIC objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96422 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug bootstrap/96422] [11 regression] Comparison failure in some 32-bit libgomp PIC objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96422 --- Comment #1 from Rainer Orth --- Created attachment 48984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48984&action=edit stage2 and stage3 oacc-parallel.o
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #17 from jvdelisle at charter dot net --- (In reply to CVS Commits from comment #16) > The master branch has been updated by Paul Thomas : > Paul, I see you got the format just right. I stumbled on that part and then decided to get out of town for sanity. I went up to the mountains and found the official center of the universe (seriously, I know where it is now). In my half of the State here we are in Insanity Phase 1.5 on Steve's scale. Cheers all. ;)
[Bug target/96421] missing __builtin_ia32_pand256 in X86 AVX2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96421 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Don't use the builtins directly. Instead use the x86 intrins (_mm256_and_si256, _mm256_or_si256, etc.) themselves or use the GNU vector extension to do and/or/xor.
[Bug c/96420] -Wsign-extensions warnings are generated from system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96420
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
Minimized standalone testcase:
# 1 "foo.c" 1
# 1 "foo.h" 1
# 1 "foo.h" 3
#define C(x) (0u+(x))
# 2 "foo.c" 2
unsigned f(int x)
{
return C(x);
}
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #18 from Rainer Orth ---
(In reply to CVS Commits from comment #16)
> gcc/testsuite/
> PR fortran/96325
> * gfortran.dg/pr96325.f90: New test.
The new testcase produces
+UNRESOLVED: gfortran.dg/pr96325.f90 -O0 compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90 -O1 compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90 -O2 compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -g compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90 -Os compilation failed to produce
executable
everywhere. It cannot be
! { dg-do run }
when the compilation is expected to fail.
[Bug fortran/96423] New: It is not checked whether module procedures have separate interface bodies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96423 Bug ID: 96423 Summary: It is not checked whether module procedures have separate interface bodies. Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chilikin.k at gmail dot com Target Milestone: --- The following code: MODULE M CONTAINS MODULE SUBROUTINE S() END SUBROUTINE END MODULE compiles successfully with gfortran 10.2.0. However, it should not compile, as S() is a separate module procedure and it should have a separate interface body. Compiler configuration: Target: x86_64-pc-linux-gnu Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0 Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) Compilation command: $ gfortran -c -o test.o test.f90
[Bug tree-optimization/96424] New: ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 23); or ICE: Segmentation fault (in expand_omp_for_init_vars/contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96424
Bug ID: 96424
Summary: ICE: verify_flow_info failed (error: wrong outgoing
edge flags at end of bb 23); or ICE: Segmentation
fault (in
expand_omp_for_init_vars/contains_struct_check)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
1.
g++-11.0.0-alpha20200726 snapshot (g:39ddfef9a5c24acf6412236f52f6716c8e0ebc9e)
ICEs when compiling the following testcase, reduced from
libgomp/testsuite/libgomp.c/loop-18.c, w/ -fbranch-probabilities
-fnon-call-exceptions -fopenmp:
int
main ()
{
int i, j;
#pragma omp for collapse (2)
for (i = 0; i < 1; ++i)
for (j = 0; j <= i; ++j)
{
}
return 0;
}
% g++-11.0.0 -fbranch-probabilities -fnon-call-exceptions -fopenmp -c
qr6y7wzi.c
qr6y7wzi.c: In function 'int main()':
qr6y7wzi.c:13:1: error: wrong outgoing edge flags at end of bb 23
13 | }
| ^
during IPA pass: profile
qr6y7wzi.c:13:1: internal compiler error: verify_flow_info failed
0xb80b56 verify_flow_info()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/cfghooks.c:269
0x105e7e7 checking_verify_flow_info
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/cfghooks.h:212
0x105e7e7 gimple_flow_call_edges_add
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-cfg.c:8622
0xf81fdd branch_prob(bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/profile.c:1099
0x10fe836 tree_profiling
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-profile.c:779
0x10fe836 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-profile.c:885
2.
Replacing <= w/ < yields the following instead:
--- qr6y7wzi.c
+++ #
@@ -5,7 +5,7 @@ main ()
#pragma omp for collapse (2)
for (i = 0; i < 1; ++i)
-for (j = 0; j <= i; ++j)
+for (j = 0; j < i; ++j)
{
}
% g++-11.0.0 -fbranch-probabilities -fnon-call-exceptions -fopenmp -c
qr6y7wzi.c
during GIMPLE pass: ompexp
qr6y7wzi.c: In function 'int main()':
qr6y7wzi.c:6:9: internal compiler error: Segmentation fault
6 | #pragma omp for collapse (2)
| ^~~
0x1028baf crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/toplev.c:328
0xec69ae contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree.h:3416
0xec69ae expand_omp_for_init_vars
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/omp-expand.c:2271
0xeccbe2 expand_omp_for_static_nochunk
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/omp-expand.c:4969
0xedc6b4 expand_omp_for
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/omp-expand.c:7421
0xedcb8a expand_omp
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/omp-expand.c:9691
0xede96c execute_expand_omp
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/omp-expand.c:9920
[Bug d/96250] d: Field access in parentheses causes error: need 'this' for 'field' of type 'type'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96250 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:442b5a661e312b27fc87f769834a2b58412a847a commit r11-2493-g442b5a661e312b27fc87f769834a2b58412a847a Author: Iain Buclaw Date: Tue Jul 21 19:32:54 2020 +0200 d: Merge upstream dmd c2274e56a (PR96250). 1. Fixes an ICE in the front-end if a struct symbol were to appear twice in the compilation unit. 2. Fixes a rejects-valid bug in the front-end where `(symbol)' was being resolved as a `var' expression, instead of `this.var'. Reviewed-on: https://github.com/dlang/dmd/pull/11436 https://github.com/dlang/dmd/pull/11439 gcc/d/ChangeLog: PR d/96250 * dmd/MERGE: Merge upstream dmd c2274e56a.
[Bug c++/96425] New: [8/9/10/11 regression] internal compiler error in maybe_process_partial_specialization()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96425
Bug ID: 96425
Summary: [8/9/10/11 regression] internal compiler error in
maybe_process_partial_specialization()
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
In attempt to find why boost is able to crash gcc at
https://bugs.gentoo.org/730406 creduce stumbled on another crash on invalid
fine:
//$ cat a.cc
struct a {
template static char ao;
template struct ao<>:
The crash seems to happen on gcc-8.4.0, gcc-9.3.0, gcc-10.2.0 and gcc-11:
$ LANG=C g++-8.4.0 -c a.cc
a.cc:3:27: internal compiler error: Segmentation fault
template struct ao<>:
^~~~
0x9d685f crash_signal
/usr/src/debug/sys-devel/gcc-8.4.0-r1/gcc-8.4.0/gcc/toplev.c:325
0x7f01a75ffc3f ???
/usr/src/debug/sys-libs/glibc-2.31-r6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x552fce maybe_process_partial_specialization(tree_node*)
/usr/src/debug/sys-devel/gcc-8.4.0-r1/gcc-8.4.0/gcc/cp/pt.c:966
0x51344a cp_parser_class_head
$ LANG=C g++-11.0.0 -c a.cc
a.cc:3:27: internal compiler error: Segmentation fault
3 | template struct ao<>:
| ^~~~
0xc76a0f crash_signal
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/toplev.c:328
0x7f790b9d3c3f ???
/usr/src/debug/sys-libs/glibc-2.31-r6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x75948e maybe_process_partial_specialization(tree_node*)
[Bug lto/96385] [8/9/10/11 Regression] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #12 from Richard Biener --- (In reply to H.J. Lu from comment #10) > (In reply to H.J. Lu from comment #8) > > The original pr26324a.o debug info contains reference to xxx. But reference > > to xxx has been removed by LTO. simple_object_copy_lto_debug_sections fails > > to remove the un-referenced symbol, xxx, from symbol table. > > The alternative is to ask linker to handle it: > > https://sourceware.org/pipermail/binutils/2020-July/112673.html The bug is we create the reference in the first place.
