[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 Frederik Harwath changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Frederik Harwath --- See attached patch.
[Bug c++/92918] New: Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918
Bug ID: 92918
Summary: Does not do name lookup when using from base class
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: CoachHagins at gmail dot com
Target Milestone: ---
This bug exists on all versions of the compiler I tried, including the current
branch.
Here is a link to compiler explorer with the code example:
https://godbolt.org/z/wYo-4n
And here is a copy/paste of the code. Compile with "-std=c++17 -DSHOW_BUG"
It shows several similar cases where the code compiles, followed by the case
which does not compile.
-
#include
class ThisCompilesOnGCC {
static void impl(char const *);
public:
template
[[nodiscard]] constexpr auto operator()(const T ) const noexcept
-> decltype(impl(t))
{
return impl(t);
}
};
void thisCompilesOnGCC() {
ThisCompilesOnGCC{}("42");
}
class Base01 {
protected:
static void impl(char const *);
};
class ThisAlsoCompilesOnGCC : private Base01 {
using Base01::impl;
public:
template
[[nodiscard]] constexpr auto operator()(const T ) const noexcept
-> decltype(impl(t))
{
return impl(t);
}
};
void thisAlsoCompilesOnGCC() {
ThisAlsoCompilesOnGCC{}("42");
}
class Base02 {
protected:
static void impl(char const *);
};
class ThisCompilesOnGCCToo : private Base02 {
using Base02::impl;
static void impl(int);
public:
template
[[nodiscard]] constexpr auto operator()(const T ) const noexcept
-> decltype(impl(t))
{
return impl(t);
}
};
void thisCompilesOnGCCToo() {
ThisCompilesOnGCCToo{}("42");
}
#if defined (__clang__) || defined(SHOW_BUG)
// This compiles with clang - but not with gcc
class Base03 {
protected:
static void impl(int);
};
class ThisDoesNotCompileOnGCC : private Base03 {
using Base03::impl;
static void impl(char const *);
public:
template
[[nodiscard]] constexpr auto operator()(const T ) const noexcept
-> decltype(impl(t))
{
return impl(t);
}
};
void thisDoesNotCompileOnGCC() {
ThisDoesNotCompileOnGCC{}("42");
}
#endif
[Bug fortran/92899] [8/9 Regression] [OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92899 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] [OpenMP] |[OpenMP] ICE in |ICE in |gfc_trans_omp_atomic, at|gfc_trans_omp_atomic, at |fortran/trans-openmp.c:3769 |fortran/trans-openmp.c:3769 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug ipa/92917] New: ipa-cp segfaults in print_all_lattices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92917
Bug ID: 92917
Summary: ipa-cp segfaults in print_all_lattices
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: erick.oc...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 47477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47477=edit
Possible fix
Stacktrace
===
lto1: internal compiler error: Segmentation fault
0xbcff9b crash_signal
../../gcc/gcc/toplev.c:328
0x1533c14 print_all_lattices
../../gcc/gcc/ipa-cp.c:547
0x1536edf ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:3876
0x153c1c7 ipcp_driver
../../gcc/gcc/ipa-cp.c:5746
0x153c1c7 execute
../../gcc/gcc/ipa-cp.c:5839
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: ../gcc2/gcc-inst/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:2: all] Error 1
Code to trigger
===
int
main(int argc, char**argv)
{
return 0;
}
How to compile
===
/path/to/gcc a.c -flto -fdump-ipa-all
How gcc was compiled
$ ../gcc2/gcc-inst/bin/gcc -v
Using built-in specs.
COLLECT_GCC=../gcc2/gcc-inst/bin/gcc
COLLECT_LTO_WRAPPER=/home/eochoa/code/gcc2/gcc-inst/libexec/gcc/aarch64-unknown-linux-gnu/10.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap --disable-libsanitizer
--enable-__cxa_atexit --enable-shared --disable-libsanitizer
--enable-languages=c,c++,fortran --enable-lto --enable-gold
--enable-linker-build-id --with-cpu-emag
--prefix=/home/eochoa/code/gcc2/gcc-inst : (reconfigured) ../gcc/configure
--disable-bootstrap --disable-libsanitizer --enable-__cxa_atexit
--enable-shared --disable-libsanitizer --enable-languages=c,c++,fortran
--enable-lto --enable-gold --enable-linker-build-id --with-cpu-emag
--prefix=/home/eochoa/code/gcc2/gcc-inst
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191211 (experimental) (GCC)
Which git commit id is HEAD?
===
300dae5c80ddda7ab4fedffaa0bbf53887232a53
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279250
138bc75d-0d04-0410-961f-82ee72b054a4
I have attached a possible (lazy) fix.
[Bug target/92723] [8/9 Regression] ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Target Milestone|10.0|8.4 Summary|[10 Regression] ICE in |[8/9 Regression] ICE in |expand_shift_1, at |expand_shift_1, at |expmed.c:2635 |expmed.c:2635 --- Comment #9 from Jakub Jelinek --- Actually, reopening for backports to release branches. On the testcase that got committed with just the rotate in there, this used to compile fine at -O3 on aarch64 with r20 and ICEs already in r201445, so it is a regression, just don't know which exact change caused it, but the rotate pattern changes are before that, so most likely some aarch64 backend changes triggered it.
[Bug target/92723] [10 Regression] ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug fortran/92899] [8/9/10 Regression] [OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92899 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Dec 11 23:58:04 2019 New Revision: 279266 URL: https://gcc.gnu.org/viewcvs?rev=279266=gcc=rev Log: PR fortran/92899 * trans-openmp.c (gfc_trans_omp_atomic): For GFC_OMP_ATOMIC_SWAP, do look through conversion on expr2 if any. * testsuite/libgomp.fortran/atomic1.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/atomic1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/libgomp/ChangeLog
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #14 from Richard Henderson --- The only reason I can think for jump tables to be put into the text section is the old aout format, which didn't have a separate read only data section. There should be no reason to do that these days.
[Bug libgomp/92835] [OpenACC] Run time error with enter./exit data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92835 --- Comment #2 from Ron --- (In reply to Thomas Schwinge from comment #1) > (In reply to Ron from comment #0) > > I am trying to compile and run my OpenACC code with GNU 9.1.0 branch. > > > > I am getting the following error: > > Thanks for the report. > > > libgomp: GOACC_enter_exit_data UNHANDLED kind 0x01 > > > > What does this mean? My code works fine with PGI. > > Huh, that's strange. That's the data mapping kind used for the OpenACC > 'copyin' clause, which certainly I see handled in 'GOACC_enter_exit_data'. > Can you tell what your source code line is? You can run your code in GDB, > with 'break gomp_fatal', and when this hits, then 'backtrace'. Hi, It turns out my library path was not pointing to the proper library (it was pointing to GNU 7). The code now runs (very slowly). Can you point me to a simple instruction as to what flags to use during configuration of the 9 branch to enable NVIDIA support? Do I have to separately install nvptx-none? On compilation, do I need to specify the offload to nvptx-none or should it automatically compile for NVIDIA? The wiki is some help but a bit out-dated and not easy to follow. If these questions are not proper for bugzilla (since they are not "bugs", what forum do you recommend to post questions such as these? Thanks - Ron
[Bug target/92723] [10 Regression] ICE in expand_shift_1, at expmed.c:2635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92723 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Dec 11 23:49:30 2019 New Revision: 279265 URL: https://gcc.gnu.org/viewcvs?rev=279265=gcc=rev Log: PR target/92723 * tree-vect-patterns.c (vect_recog_rotate_pattern): If dt is not vect_internal_def, use oprnd1 as is, without trying to cast it. Formatting fix. * gcc.dg/vect/pr92723.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92723.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug libbacktrace/92916] New: elf_add freeing strtab_view in fail, even though it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92916 Bug ID: 92916 Summary: elf_add freeing strtab_view in fail, even though it shouldn't Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: marc.streckfuss at gmail dot com CC: ian at gcc dot gnu.org Target Milestone: --- First of all, apologies if this report doesn't follow the correct convention, but since this is a libbacktrace bug, most of it doesn't apply. I'm keeping this rather short, since I guess the maintainer is the same one as the github version (https://github.com/ianlancetaylor/libbacktrace), so this is mostly to help internal/upstream tracking and coordination: https://github.com/ianlancetaylor/libbacktrace/blob/master/elf.c#L2965 claims, that "we hold on to the string table permanently.", which is only true until a https://github.com/ianlancetaylor/libbacktrace/blob/master/elf.c#L3197, which is caused by https://github.com/ianlancetaylor/libbacktrace/blob/master/elf.c#L3071 Now I don't know if it's "okay" for L3071 to fail, like this expected, then Line 3197 is just wrong. If this is a more critical fault or releasing the symnames there is required, then the changes made to the state (symdata) have to be rolled back, so no one is relying on them as the error is not propagated back, but skipped. the mentioned backtrace_get_view fails because of backtrace_get_view L77 -> file too short, size = 2884504395, got = 2147479552. see https://github.com/ianlancetaylor/libbacktrace/issues/29 for where I intially reported this.
[Bug fortran/92782] [OpenMP] ICE in fold_convert_loc, at fold-const.c:2431
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92782 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Summary|ICE in fold_convert_loc, at |[OpenMP] ICE in |fold-const.c:2431 |fold_convert_loc, at ||fold-const.c:2431
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #13 from Eric Botcazou --- > I think that case vector stuff was written by Richard Henderson FWIW. Richard, do you have any recollection of this?
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #12 from davem at gcc dot gnu.org --- I think that case vector stuff was written by Richard Henderson FWIW.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- Created attachment 47476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47476=edit Tentative fix
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #10 from Eric Botcazou --- The SPARC port even has a specific implementation here: /* This is how we hook in and defer the case-vector until the end of the function. */ #define ASM_OUTPUT_ADDR_VEC(LAB,VEC) \ sparc_defer_case_vector ((LAB),(VEC), 0) #define ASM_OUTPUT_ADDR_DIFF_VEC(LAB,VEC) \ sparc_defer_case_vector ((LAB),(VEC), 1)
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Summary|jump tables are put in the |jump tables are put into |.text section |the text section --- Comment #9 from Eric Botcazou --- > I cannot think of any specific reason why the jump tables were put into the > text section. I even tried to consider relocation ramifications. Yes, relocation considerations quickly come to mind. Thanks in any case. > Maybe this makes GOT OP linker optimizations more likely when -fPIC? I wonder whether this wouldn't stem from limitations of the Sun assembler or somesuch: in PIC mode, this would generate differences between labels from different sections, so relocations need to be generated by the assembler.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #8 from davem at gcc dot gnu.org --- I cannot think of any specific reason why the jump tables were put into the text section. I even tried to consider relocation ramifications. Maybe this makes GOT OP linker optimizations more likely when -fPIC?
[Bug c++/92907] noexcept does not consider "const" in member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92907
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-11
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
void f(const int&);
void f(int&) = delete;
struct A
{
int i;
void g() const noexcept(noexcept(f(i)));
};
This should compile, but is rejected:
ne.cc:7:41: error: use of deleted function ‘void f(int&)’
7 | void g() const noexcept(noexcept(f(i)));
| ^
ne.cc:2:6: note: declared here
2 | void f(int&) = delete;
| ^
(In reply to Helmut Zeisel from comment #0)
> In addition, member variables are not found when they are declared after the
> noexcept operator.
That was PR c++/86476 and is already fixed on trunk.
[Bug fortran/92897] [9/10 Regression] [Coarray] ICE in gfc_set_array_spec, at fortran/array.c:864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92897 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- Fixed.
[Bug fortran/92897] [9/10 Regression] [Coarray] ICE in gfc_set_array_spec, at fortran/array.c:864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92897 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 11 20:18:17 2019 New Revision: 279249 URL: https://gcc.gnu.org/viewcvs?rev=279249=gcc=rev Log: 2019-12-11 Steven G. Kargl PR fortran/92897 * array.c (gfc_set_array_spec): Remove invalid assert() triggered by invalid Fortran code. 2019-12-11 Steven G. Kargl PR fortran/92897 * gfortran.dg/pr92897.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr92897.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/array.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/92900] Cannot use member of packed struct in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92900 --- Comment #4 from Jonathan Wakely --- Since accessing a misaligned variable is undefined behaviour, I don't think it should be permitted in constant expressions (at least for the cases where the alignment is reduced from its natural value).
[Bug bootstrap/92915] msys issue couldn't commit memory for cygwin heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92915 --- Comment #2 from darksectordds --- (In reply to Andrew Pinski from comment #1) > This is not a bug in GCC as make is failing with an internal error. Please > report it to the msys folks instead. I'd be glad if you could tell me where. It is very difficult to just find them.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- DaveM, any recollection about the rationale for the decision?
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #6 from Eric Botcazou --- > So assuming the intend is to put the jump table in the rodata section, > something seems to be broken in the build then. No, see my earlier remark, this was intended.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #5 from Jean-Christophe Dubois --- I guess JUMP_TABLES_IN_TEXT_SECTION is supposed to mean that the "jump tables" should not be put in the text section. However something is wrong then because gcc 9 (and maybe previous) is putting the jump table as a "subsection" of the text section in the generated assembly code (therefore it is part of the text section). I am attaching a generated assembly file where "jump tables" are generated and declared as subsection of the text section. In this file you can for example look at the L87 jump table which is used by the tfp_format function (this is the first jump table that triggered an exception in my test case). So assuming the intend is to put the jump table in the rodata section, something seems to be broken in the build then.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #4 from Jean-Christophe Dubois --- Created attachment 47475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47475=edit assembly file with jump tables in the text section
[Bug fortran/92897] [9/10 Regression] [Coarray] ICE in gfc_set_array_spec, at fortran/array.c:864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92897 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 11 19:28:57 2019 New Revision: 279247 URL: https://gcc.gnu.org/viewcvs?rev=279247=gcc=rev Log: 2019-12-11 Steven G. Kargl PR fortran/92897 * array.c (gfc_set_array_spec): Remove invalid assert() triggered by invalid Fortran code. 2019-12-11 Steven G. Kargl PR fortran/92897 * gfortran.dg/pr92897.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr92897.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/92915] msys issue couldn't commit memory for cygwin heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92915 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- This is not a bug in GCC as make is failing with an internal error. Please report it to the msys folks instead.
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909
Jakub Jelinek changed:
What|Removed |Added
Keywords||accepts-invalid,
||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-11
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |8.4
Summary|ICE on incorrect lambda |[8/9/10 Regression] ICE on
|inside variadic template|incorrect lambda inside
||variadic template
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Before r251433 this used to be rejected:
pr92909.C: In lambda function:
pr92909.C:4:19: error: parameter packs not expanded with ‘...’:
[]{ using T = Ts; }();
^
pr92909.C:4:19: note: ‘Ts’
afterwards it is accepted without -g and ICEs with -g.
clang++ seems to reject it in all cases.
So, tentatively marking as accepts-invalid/ice-on-invalid-code.
[Bug target/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 --- Comment #3 from Segher Boessenkool --- (In reply to Christophe Leroy from comment #2) > But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before > branching to LR as the ASM functions do, does it ? Not at all, no. But e.g. (linker-generated) glue code is free to clobber R0! > In our ABIs, r3 is also volatile in our ABIs, it doesn't prevent using it as > function return. No, R3 is defined to be used as the return value. CR0 is not.
[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92869 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed. Thanks for the report.
[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92869 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Dec 11 18:44:02 2019 New Revision: 279241 URL: https://gcc.gnu.org/viewcvs?rev=279241=gcc=rev Log: PR c++/92869 * class.c (finish_struct): For C++17 and earlier, check type_has_user_provided_or_explicit_constructor rather than TYPE_HAS_USER_CONSTRUCTOR whether to set CLASSTYPE_NON_AGGREGATE. * g++.dg/cpp0x/aggr3.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/aggr3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92900] Cannot use member of packed struct in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92900 Jakub Jelinek changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The difference between those two is that s1.i FIELD_DECL doesn't have DECL_PACKED set on it (a bug in the #pragma pack support?), while with packed attribute it does. DECL_PACKED on the FIELD_DECL in s2 is set during check_field_decls called from check_bases_and_members from finish_struct*. For S1, TYPE_PACKED is actually never set, and thus DECL_PACKED neither. The reason the s2 case is rejected is that lvalue_kind returns something with clk_packed on it, forcing a temporary. That was added in https://gcc.gnu.org/ml/gcc-patches/2003-07/msg01664.html CCing the author. Note, even in the C FE pragma pack actually doesn't cause TYPE_PACKED/DECL_PACKED to be set, it isn't really identical to what packed attribute does either, e.g. I believe we should only set DECL_PACKED on FIELD_DECLs where packed attribute on the containing type or pragma pack or -fpack-struct= etc. actually lowered the alignment over what it would normally have.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Wed Dec 11 18:40:55 2019
New Revision: 279240
URL: https://gcc.gnu.org/viewcvs?rev=279240=gcc=rev
Log:
PR c++/92878 - Parenthesized init of aggregates in new-expression.
Ville pointed out that our paren init of aggregates doesn't work for
auto a = new A(1, 2, 3);
and I think it should:
A new-expression that creates an object of type T initializes that object
as follows:
...
-- Otherwise, the new-initializer is interpreted according to the
initialization rules of [dcl.init] for direct-initialization.
so I think it follows that we should perform dcl.init#17.6.2.2.
This doesn't work with new[]; we have:
error ("parenthesized initializer in array new");
* init.c (build_new_1): Handle parenthesized initialization of
aggregates in new-expression.
* g++.dg/cpp2a/paren-init20.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
[Bug target/92488] GCC generates to calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 Segher Boessenkool changed: What|Removed |Added Target|powerpc |powerpc* Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92105] [8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |10.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 10, not worth backporting.
[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Peter Bergner --- Confirmed fixed on trunk. Thanks Vlad!
[Bug c++/92900] Cannot use member of packed struct in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92900
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Testcase without includes:
typedef __SIZE_TYPE__ size_t;
template
constexpr size_t size (const T (&)[N]) noexcept { return N; }
#pragma pack(1)
struct S1 { int i[10]; };
#pragma pack()
struct __attribute__((packed)) S2 { int i[10]; };
#define LEN(a) (sizeof(a) / sizeof(a[0]));
size_t
foo ()
{
S1 s1{};
constexpr auto sz1 = size (s1.i);
S2 s2{};
constexpr auto sz2 = size (s2.i);
constexpr auto sz3 = LEN(s2.i);
return sz1 + sz2 + sz3;
}
[Bug target/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 --- Comment #2 from Christophe Leroy --- But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before branching to LR as the ASM functions do, does it ? In our ABIs, r3 is also volatile in our ABIs, it doesn't prevent using it as function return.
[Bug c/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-12-11 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- CR0 is volatile in all our ABIs, so this is impossible to support from a C function without defining a new ABI first.
[Bug c++/92105] [8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105 --- Comment #4 from Jason Merrill --- Author: jason Date: Wed Dec 11 16:51:14 2019 New Revision: 279237 URL: https://gcc.gnu.org/viewcvs?rev=279237=gcc=rev Log: PR c++/92105 - decltype(decltype) error cascade. The primary change here is to do the CPP_DECLTYPE replacement even when we get an error, so we don't keep trying and giving the same parse error each time. We also commit to the tentative firewall parse more often, leading to better diagnostics. * parser.c (cp_parser_decltype_expr): Don't tentative_firewall here. (cp_parser_decltype): Do it here. Remember a non-tentative error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype-err1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.dg/cpp0x/decltype10.C
[Bug c++/57082] brace initialization requires public destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Wed Dec 11 16:51:09 2019
New Revision: 279236
URL: https://gcc.gnu.org/viewcvs?rev=279236=gcc=rev
Log:
PR c++/57082 - new X{} and private destructor.
build_new_1 already passes tf_no_cleanup to build_value_init, but in this
testcase we end up calling build_value_init by way of
build_special_member_call, so we need to pass it to that function as well.
* init.c (build_new_1): Also pass tf_no_cleanup to
build_special_member_call.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-new2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
[Bug c++/92774] ICE with defaulted three-way comparison function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92774 --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Dec 11 16:51:05 2019 New Revision: 279235 URL: https://gcc.gnu.org/viewcvs?rev=279235=gcc=rev Log: PR c++/92774 - ICE with implicitly deleted operator<=>. Missing error-recovery code. While I was poking at this I also figured we don't need to iterate over the members of a union. * method.c (comp_info::~comp_info): Factor out of... (build_comparison_op): Here. Handle error return from build_new_op. Added: trunk/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug libgomp/92843] [OpenACC] Wrong/missing dynamic reference counting for structured 'REFCOUNT_INFINITY'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843 --- Comment #11 from Thomas Schwinge --- Author: tschwinge Date: Wed Dec 11 16:49:27 2019 New Revision: 279234 URL: https://gcc.gnu.org/viewcvs?rev=279234=gcc=rev Log: [PR92843] [OpenACC] Fix dynamic reference counting for structured 'REFCOUNT_INFINITY' libgomp/ PR libgomp/92843 * oacc-mem.c (present_create_copy, delete_copyout): Fix dynamic reference counting for structured 'REFCOUNT_INFINITY'. Add some assertions. (goacc_insert_pointer, goacc_remove_pointer): Adjust accordingly. * testsuite/libgomp.oacc-c-c++-common/pr92843-1.c: New file. * testsuite/libgomp.oacc-c-c++-common/clauses-1.c: Fix OpenACC. * testsuite/libgomp.oacc-c-c++-common/lib-82.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/nested-1.c: Likewise. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-mem.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-82.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/nested-1.c
[Bug c++/92859] compiler treats enum type as an integer during overload resolution when a bit-field of this enum is considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92859 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Dec 11 16:48:44 2019 New Revision: 279229 URL: https://gcc.gnu.org/viewcvs?rev=279229=gcc=rev Log: PR c++/92859 - ADL and bit-field. We also need unlowered_expr_type when considering associated types for ADL. * name-lookup.c: Use unlowered_expr_type. Added: trunk/gcc/testsuite/g++.dg/overload/bit-field1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c
[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854 --- Comment #8 from Thomas Schwinge --- Author: tschwinge Date: Wed Dec 11 16:48:59 2019 New Revision: 279231 URL: https://gcc.gnu.org/viewcvs?rev=279231=gcc=rev Log: [PR92854] Add 'libgomp.oacc-c-c++-common/acc_map_data-device_already-*.c', 'libgomp.oacc-c-c++-common/acc_map_data-host_already-*.c' ... to document the status quo. libgomp/ PR libgomp/92854 * testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-1.c: New file. * testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-3.c: Likewise. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-device_already-3.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_map_data-host_already-3.c Modified: trunk/libgomp/ChangeLog
[Bug c++/92446] [C++20] template argument deduction fails for custom non-type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92446 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Dec 11 16:48:22 2019 New Revision: 279228 URL: https://gcc.gnu.org/viewcvs?rev=279228=gcc=rev Log: PR c++/92446 - deduction of class NTTP. Another place we need to look through the VIEW_CONVERT_EXPR we add to make a use of a class NTTP have const type. * pt.c (deducible_expression): Look through VIEW_CONVERT_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/92915] New: msys issue couldn't commit memory for cygwin heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92915 Bug ID: 92915 Summary: msys issue couldn't commit memory for cygwin heap Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pechenskih.stas at ya dot ru Target Milestone: --- Created attachment 47474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47474=edit make debug log file I have Windows 10(x64) 1809 17763.864. I installed msys, all necessary libraries to build gcc 8.2.0, but when the process comes to libgcc i got issue: D:\MyTest2\MinGW\_base_\msys\1.0\bin\make.exe: *** couldn't commit memory for cygwin heap, Win32 error 0. A search through Google, Yahho and other that yielded nothing. Then I added -d flag in order to see the problem clearly. And what i got: D:\MyTest2\MinGW\_base_\msys\1.0\bin\make.exe: *** couldn't commit memory for cygwin heap, Win32 error 0 Reaping losing child 0x0a090d10 PID 7316 make[1]: *** [all-target-libgcc] Error 1 Removing child 0x0a090d10 PID 7316 from chain. make[1]: Leaving directory `/d/PSP/pspsdk_custom/minpsp-master/psp/build/gcc-8.2.0' Reaping losing child 0x0a03da10 PID 3316 make: *** [all] Error 2 Removing child 0x0a03da10 PID 3316 from chain. It looks like there is a memory leak or checked some limitation.
[Bug fortran/92899] [8/9/10 Regression] [OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92899 --- Comment #2 from Jakub Jelinek --- Created attachment 47473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47473=edit gcc10-pr92899.patch Untested fix.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 79221, which changed state. Bug 79221 Summary: missing -Wstringop-overflow= on a strcat overflow https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79221 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/79221] missing -Wstringop-overflow= on a strcat overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79221 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Test case added in r279227.
[Bug middle-end/79221] missing -Wstringop-overflow= on a strcat overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79221 --- Comment #5 from Martin Sebor --- Author: msebor Date: Wed Dec 11 15:59:55 2019 New Revision: 279227 URL: https://gcc.gnu.org/viewcvs?rev=279227=gcc=rev Log: PR middle-end/79221 - missing -Wstringop-overflow= on a strcat overflow gcc/testsuite/ChangeLog: * gcc.dg/Wstringop-overflow-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-26.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/79221] missing -Wstringop-overflow= on a strcat overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79221 Martin Sebor changed: What|Removed |Added Known to work||10.0, 8.1.0, 9.2.0 Target Milestone|--- |8.4 Known to fail||7.2.0 --- Comment #4 from Martin Sebor --- Looks like this was resolved by r255755 (PR 78918). Both functions in the test case in comment #0 are now diagnosed, by different warnings. That's not unexpected but should at some point be changed to issue -Wstringop-overflow for both. $ gcc -O2 -S -Wall pr79221.c pr79221.c: In function ‘f’: pr79221.c:8:3: warning: ‘strcat’ writing between 7 and 9 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] 8 | strcat (d, s); | ^ pr79221.c: In function ‘gf’: pr79221.c:15:3: warning: ‘__builtin_memcpy’ forming offset [3, 8] is out of the bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds] 15 | strcat (d, s); | ^ pr79221.c:3:6: note: ‘d’ declared here 3 | char d[3]; | ^
[Bug fortran/92896] [10 Regression] [DEC] ICE in reduce_unary, at fortran/arith.c:1283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92896
--- Comment #4 from MarkEggleston ---
reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
gfc_expr **result)
{
gfc_constructor_base head;
gfc_constructor *c;
gfc_expr *r;
arith rc;
if (op->expr_type == EXPR_CONSTANT)
return eval (op, result);
rc = ARITH_OK;
head = gfc_constructor_copy (op->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
rc = reduce_unary (eval, c->expr, );
if (rc != ARITH_OK)
break;
gfc_replace_expr (c->expr, r);
}
if (rc != ARITH_OK)
gfc_constructor_free (head);
else
{
gfc_constructor *c = gfc_constructor_first (head);
!!! Crashes because c is NULL
r = gfc_get_array_expr (c->expr->ts.type, c->expr->ts.kind,
>where); r->shape = gfc_copy_shape
(op->shape, op->rank);
r->rank = op->rank;
r->value.constructor = head;
*result = r;
}
return rc;
}
The ICE is indicated above. The routine is called, then called again
recursively, it would seem that the constructor is missing when
-fno-range-check is omitted. Judging by comments 1 & 3 there is a missing
error message.
[Bug fortran/92896] [10 Regression] [DEC] ICE in reduce_unary, at fortran/arith.c:1283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92896 --- Comment #3 from MarkEggleston --- The value 'A' is padded out with spaces giving a value 2314885530818453554. Avoiding the conversion and using the value directly: program p print *, [integer :: 1, [integer(8) :: 2314885530818453554]] end results in: 2 |print *, [integer :: 1, [integer(8) :: 2314885530818453554]] | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check'
[Bug fortran/92899] [8/9/10 Regression] [OpenMP] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92899 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-11 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 Summary|[OpenMP] ICE in |[8/9/10 Regression] |gfc_trans_omp_atomic, at|[OpenMP] ICE in |fortran/trans-openmp.c:3769 |gfc_trans_omp_atomic, at ||fortran/trans-openmp.c:3769 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with my r240038 and backports of that patch.
[Bug c/91843] pretty printer mangles extended characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Lewis Hyatt --- Fixed for GCC 10. https://gcc.gnu.org/viewcvs/gcc?view=revision=279226
[Bug ipa/91853] [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #8 from Lewis Hyatt --- Ugh, my apologies, this commit relates to PR 91843 rather.
[Bug ipa/91853] [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853 --- Comment #7 from lhyatt at gcc dot gnu.org --- Author: lhyatt Date: Wed Dec 11 14:52:31 2019 New Revision: 279226 URL: https://gcc.gnu.org/viewcvs?rev=279226=gcc=rev Log: Adds multibyte awareness to pretty-print.c 2019-12-11 Lewis Hyatt PR 91853 * pretty-print.c (pp_quoted_string): Avoid hex-escaping valid multibyte input. Fix off-by-one-bug printing the last byte before a hex-escaped output. (pp_character): Don't apply line wrapping in the middle of multibyte characters. (test_utf8): New test. (pretty_print_c_tests): Call the new test. Modified: trunk/gcc/ChangeLog trunk/gcc/pretty-print.c
[Bug fortran/92913] Add argument-mismatch check for INTERFACE for non-module procedures in the same file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92913 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-11 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- I'll see what I can do. I think this is still something that we could do for the gcc 10 timeframe.
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #6 from Martin Liška ---
And the last piece is this one:
if (opts->x_optimize == 0)
{
/* Inlining does not work if not optimizing,
so force it not to be done. */
opts->x_warn_inline = 0;
opts->x_flag_no_inline = 1;
}
where warn_inline is not Optimization.
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #5 from Martin Liška --- param_min_crossjump_insns is changed here when we switch optimization level: if (opts->x_optimize_size) /* We want to crossjump as much as possible. */ SET_OPTION_IF_UNSET (opts, opts_set, param_min_crossjump_insns, 1); Similarly for param_max_combine_insns: /* Restrict the amount of work combine does at -Og while retaining most of its useful transforms. */ if (opts->x_optimize_debug) SET_OPTION_IF_UNSET (opts, opts_set, param_max_combine_insns, 2); likely here: /* -O2 param settings. */ opt2 = (opts->x_optimize >= 2); ... /* Track fields in field-sensitive alias analysis. */ if (opt2) SET_OPTION_IF_UNSET (opts, opts_set, param_max_fields_for_field_sensitive, 100);
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #4 from Martin Liška ---
Example 1:
$ cat tc.c
void linker_error();
__attribute__ ((optimize("-O0")))
int a ()
{
}
static int remove_me ()
{
linker_error ();
}
void
main()
{
}
$ ./xgcc -B. -Os tc.c -c -momit-leaf-frame-pointer -m32
global_options difference in flag_merge_constants (1/0)
global_options difference in flag_merge_constants (1/0)
global_options difference in flag_omit_frame_pointer (1/0)
global_options difference in flag_ree (1/0)
tc.c:4:1: internal compiler error: in handle_optimize_attribute, at
c-family/c-attribs.c:4505
4 | {
| ^
0x925d14 handle_optimize_attribute
/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4505
0x81fa2e decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/attribs.c:713
0x83ab20 start_function(c_declspecs*, c_declarator*, tree_node*)
/home/marxin/Programming/gcc/gcc/c/c-decl.c:9110
0x892c57 c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2403
0x89af13 c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1742
0x89b961 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1615
0x89b961 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:21653
0x8f213b c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1186
Where flag_omit_frame_pointer is overwritten here based on
USE_IX86_FRAME_POINTER aka -momit-leaf-frame-pointer:
│1624 if (opts->x_optimize >= 1)│
│1625 SET_OPTION_IF_UNSET (opts, opts_set,
flag_omit_frame_pointer,│
│1626 !(USE_IX86_FRAME_POINTER ||
opts->x_optimize_size));│
>│1627 if (opts->x_flag_asynchronous_unwind_tables == 2)│
│1628opts->x_flag_asynchronous_unwind_tables =
!USE_IX86_FRAME_POINTER;│
flag_merge_constants is not optimization and is changed due to when we switch
optimization level:
gcc/opts.c:{ OPT_LEVELS_1_PLUS, OPT_fmerge_constants, NULL, 1 },
I do not know why -free is changed:
gcc/common.opt:Common Report Var(flag_ree) Init(0)
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Ok, I've prepared a debugging patch that can be probably added in next stage1: https://github.com/marxin/gcc/tree/global-options-checking Using the patch I see a violation of the following options: 12 global_options difference in flag_omit_frame_pointer (1/0) 141 global_options difference in warn_inline (1/0) 695 global_options difference in param_min_crossjump_insns (5/1) 718 global_options difference in param_max_combine_insns (4/2) 1284 global_options difference in flag_merge_constants (1/0) 1396 global_options difference in flag_ree (1/0) 1601 global_options difference in param_max_fields_for_field_sensitive (0/100) I'll prepare a test-cases for that.
[Bug c++/92914] Hidden visibility incompatible with extern'd specialized explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914 --- Comment #4 from Stephen --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55347 is also related.
[Bug c++/92914] Hidden visibility incompatible with extern'd specialized explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914 --- Comment #3 from Stephen --- Also, I tried to follow what I think was indicated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56328 in that I forward declared the specialization in the header.
[Bug c++/92914] Hidden visibility incompatible with extern'd specialized explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914 --- Comment #2 from Stephen --- Also: stephen@j5:~/dev/src/playground/cpp/build$ nm mylib.g++.o | c++filt W Templ::getAnotherNum() const W Templ::getNum() const W Templ::getAnotherNum() const T Templ::getNum() const stephen@j5:~/dev/src/playground/cpp/build$ nm mylib.clang++.o | c++filt r .LCPI2_0 0004 r .LCPI3_0 W Templ::getAnotherNum() const W Templ::getNum() const W Templ::getAnotherNum() const T Templ::getNum() const
[Bug c++/92914] Hidden visibility incompatible with extern'd specialized explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914 --- Comment #1 from Stephen --- www.open-std.org/jtc1/sc22AC/wg21/docs/papers/2017/p0537r0.html may be related to this too.
[Bug c++/92914] New: Hidden visibility incompatible with extern'd specialized explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92914
Bug ID: 92914
Summary: Hidden visibility incompatible with extern'd
specialized explicit template instantiations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steveire at gmail dot com
Target Milestone: ---
I'm trying to use hidden visibility with a library which is already used with
MSVC. It uses exported explicit template specializations.
mylib.h:-
#pragma once
#if _MSC_VER
# ifdef mylib_EXPORTS
#define MYLIB_EXPORT __declspec(dllexport)
# else
#define MYLIB_EXPORT __declspec(dllimport)
# endif
#else
# ifdef mylib_EXPORTS
#define MYLIB_EXPORT __attribute__((visibility("default")))
# else
#define MYLIB_EXPORT
# endif
#endif
template
class Templ
{
public:
T getNum() const;
T getAnotherNum() const;
};
#ifdef SPECIALIZE_INT
template<> MYLIB_EXPORT int Templ::getNum() const;
#endif
#ifndef mylib_EXPORTS
extern template class Templ;
extern template class Templ;
#endif
-
mylib.cpp-
#include "mylib.h"
template
T Templ::getNum() const
{
return 7;
}
template
T Templ::getAnotherNum() const
{
return 5;
}
#ifdef SPECIALIZE_INT
template<>
int Templ::getNum() const
{
return 42;
}
#endif
template class MYLIB_EXPORT Templ;
template class MYLIB_EXPORT Templ;
-
main.cpp--
#include "mylib.h"
#include
int main()
{
Templ ti;
Templ tf;
std::cout
<< ti.getNum() << " -- " << ti.getAnotherNum()
<< tf.getNum() << " -- " << tf.getAnotherNum() << std::endl;
return 0;
}
-
build.sh--
#!/bin/sh
set -x
COMPILE_DRIVER=g++
COMPILE_DRIVER=clang++
$COMPILE_DRIVER -Dmylib_EXPORTS -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -o mylib.$COMPILE_DRIVER.o -c ../mylib.cpp
$COMPILE_DRIVER -fPIC -Wl,--no-undefined -shared -o libmylib.so
mylib.$COMPILE_DRIVER.o
$COMPILE_DRIVER -fvisibility=hidden -fvisibility-inlines-hidden -o
main.$COMPILE_DRIVER.o -c ../main.cpp
$COMPILE_DRIVER main.$COMPILE_DRIVER.o -o myexe -Wl,-rpath,$PWD libmylib.so
# Compile with SPECIALIZE_INT defined:
$COMPILE_DRIVER -DSPECIALIZE_INT -Dmylib_EXPORTS -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -o mylib.$COMPILE_DRIVER.o -c ../mylib.cpp
$COMPILE_DRIVER -fPIC -Wl,--no-undefined -shared -o libmylib.so
mylib.$COMPILE_DRIVER.o
$COMPILE_DRIVER -DSPECIALIZE_INT -fvisibility=hidden
-fvisibility-inlines-hidden -o main.$COMPILE_DRIVER.o -c ../main.cpp
$COMPILE_DRIVER main.$COMPILE_DRIVER.o -o myexe -Wl,-rpath,$PWD libmylib.so
---
clang ---
+ clang++ -Dmylib_EXPORTS -fPIC -fvisibility=hidden -fvisibility-inlines-hidden
-o mylib.clang++.o -c ../mylib.cpp
+ clang++ -fPIC -Wl,--no-undefined -shared -o libmylib.so mylib.clang++.o
+ clang++ -fvisibility=hidden -fvisibility-inlines-hidden -o main.clang++.o -c
../main.cpp
+ clang++ main.clang++.o -o myexe
-Wl,-rpath,/home/stephen/dev/src/playground/cpp/build libmylib.so
+ clang++ -DSPECIALIZE_INT -Dmylib_EXPORTS -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -o mylib.clang++.o -c ../mylib.cpp
+ clang++ -fPIC -Wl,--no-undefined -shared -o libmylib.so mylib.clang++.o
+ clang++ -DSPECIALIZE_INT -fvisibility=hidden -fvisibility-inlines-hidden -o
main.clang++.o -c ../main.cpp
+ clang++ main.clang++.o -o myexe
-Wl,-rpath,/home/stephen/dev/src/playground/cpp/build libmylib.so
---
While this works with clang above, it does not work with GCC:
gcc ---
+ g++ -Dmylib_EXPORTS -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o
mylib.g++.o -c ../mylib.cpp
+ g++ -fPIC -Wl,--no-undefined -shared -o libmylib.so mylib.g++.o
+ g++ -fvisibility=hidden -fvisibility-inlines-hidden -o main.g++.o -c
../main.cpp
+ g++ main.g++.o -o myexe -Wl,-rpath,/home/stephen/dev/src/playground/cpp/build
libmylib.so
+ g++ -DSPECIALIZE_INT -Dmylib_EXPORTS -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -o mylib.g++.o -c ../mylib.cpp
../mylib.cpp:24:29: warning: type attributes ignored after type is already
defined [-Wattributes]
template class MYLIB_EXPORT Templ;
^~
+ g++ -fPIC -Wl,--no-undefined -shared -o libmylib.so mylib.g++.o
+ g++ -DSPECIALIZE_INT -fvisibility=hidden -fvisibility-inlines-hidden -o
main.g++.o -c ../main.cpp
+ g++ main.g++.o -o myexe -Wl,-rpath,/home/stephen/dev/src/playground/cpp/build
libmylib.so
main.g++.o: In function `main':
main.cpp:(.text+0x4c): undefined reference to `Templ::getAnotherNum()
const'
collect2: error: ld returned 1 exit status
---
[Bug libstdc++/91786] Clang 8.0.1 can't compile the header on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91786 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed Dec 11 13:45:56 2019 New Revision: 279223 URL: https://gcc.gnu.org/viewcvs?rev=279223=gcc=rev Log: PR libstdc++/91786 fix compilation error with Clang Backport from mainline 2019-11-25 Jonathan Wakely PR libstdc++/91786 * include/bits/fs_path.h (filesystem_error): Move definition before the use in u8path. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/bits/fs_path.h
[Bug libstdc++/91786] Clang 8.0.1 can't compile the header on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91786 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed for GCC 9.3
[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92908 --- Comment #4 from Jakub Jelinek --- Created attachment 47472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47472=edit gcc10-pr92908.patch Full untested patch.
[Bug target/92905] [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #4 from Alexander Monakov ---
Perhaps only xmm0 is problematic, as making xmm0 unused by adding a dummy
argument brings back the old spill-free result:
float my_copysign(float dummy, float x, float y)
{
union {float f; unsigned i;} ux = {x}, uy ={y};
ux.i &= 0x7fff;
ux.i |= 0x8000 & uy.i;
return ux.f;
}
float f(float dummy, float x)
{
union {float f; unsigned i;} u = {x};
u.i |= 0x8000;
return u.f;
}
[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92908 --- Comment #3 from Jakub Jelinek --- Started with r279107.
[Bug fortran/92913] New: Add argument-mismatch check for INTERFACE for non-module procedures in the same file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92913
Bug ID: 92913
Summary: Add argument-mismatch check for INTERFACE for
non-module procedures in the same file
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the code below, there is an argument or function vs. subroutine mismatch
between stand-alone procedures and their interface blocks.
It would be very helpful to diagnose such mismatches. I have seen such code
before in some numeric programs, but it also exists as:
* libgomp/openacc.f90 – the 'module openacc_internal' has the interfaces and
the implementation is done by the stand-alone procedures at the bottom.
(libgomp/omp_lib.{h,f90}.in is different; they both only provide an interface,
except that the .h files only has 'external' and the function-result type.)
! Non-module subroutine to be compatible with Fortran 77 code
subroutine foo(x)
integer :: x
x = 5
end subroutine foo
! Make those procedures accessible as module
module m
interface
subroutine foo() ! Not diagnosed: missing argument
end subroutine foo
subroutine bar() ! Not diagnosed: subroutine vs. function
end subroutine bar
end interface
end module m
! Non-module function to be compatible with Fortran 77 code
integer function bar()
bar = 42
end function bar
Another case would be:
subroutine sub_1()
interface
subroutine bar(x)
integer :: x
end subroutine bar
interface
end subroutine sub_1
subroutine sub_2()
interface
subroutine bar() ! arg mismatch
end subroutine bar
interface
end subroutine sub_2
subroutine sub_3
external bar
integer bar ! function vs. subroutine mismatch
end subroutine sub_3
Such use also exists in real-world code – but it could also be used as cross
check for omp_lib.{h,f90} by temporarily adding
subroutine sub1()
#include
end
to omp_lib.f90 + compiling it.
[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92908
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-12-11
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
--- gcc/simplify-rtx.c.jj 2019-11-19 22:27:02.58742 +0100
+++ gcc/simplify-rtx.c 2019-12-11 13:31:57.197809704 +0100
@@ -5037,6 +5037,23 @@ simplify_relational_operation (enum rtx_
return NULL_RTX;
#endif
}
+ if (VECTOR_MODE_P (cmp_mode)
+ && SCALAR_INT_MODE_P (mode)
+ && tem == const_true_rtx)
+ {
+ /* Vector comparisons that expect a scalar integral
+bitmask. For const0_rtx the result is already correct,
+for const_true_rtx we need all bits set. */
+ int n_elts;
+ scalar_int_mode smode = as_a (mode);
+ gcc_assert (GET_MODE_NUNITS (cmp_mode).is_constant (_elts)
+ && GET_MODE_PRECISION (smode) <= n_elts);
+ if (GET_MODE_PRECISION (smode) == n_elts)
+ return constm1_rtx;
+ if (n_elts < HOST_BITS_PER_WIDE_INT)
+ return GEN_INT ((HOST_WIDE_INT_1U << n_elts) - 1);
+ return NULL_RTX;
+ }
return tem;
}
@@ -5383,7 +5400,7 @@ comparison_result (enum rtx_code code, i
}
/* Check if the given comparison (done in the given MODE) is actually
- a tautology or a contradiction. If the mode is VOID_mode, the
+ a tautology or a contradiction. If the mode is VOIDmode, the
comparison is done in "infinite precision". If no simplification
is possible, this function returns zero. Otherwise, it returns
either const_true_rtx or const0_rtx. */
fixes this.
[Bug c++/92912] New: Bad diagnostic for capture of this in free function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92912
Bug ID: 92912
Summary: Bad diagnostic for capture of this in free function
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soko.slav at yandex dot ru
Target Milestone: ---
This free function
void foo()
{
[&]()
{
static_cast(this);
};
}
does not compile but the message is misleading:
error: 'this' was not captured for this lambda function
static_cast(this);
Actually 'this' cannot be captured here as 'this' is keyword which cannot be
used in this context.
Expected message:
error: invalid use of 'this' in non-member function
tested locally and on https://godbolt.org/z/5cAA3k (more examples there
including similar case without lambda)
[Bug c++/92911] New: Valid lambda inside variadic template does not compile (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92911
Bug ID: 92911
Summary: Valid lambda inside variadic template does not compile
(2)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soko.slav at yandex dot ru
Target Milestone: ---
Code:
template
void foo()
{
(
[]()
{
using T = Ts;
}(),...
);
}
template void foo<>();
fails to compile with message
In function 'void foo()':
:8:10: error: operand of fold expression has no unexpanded parameter
packs
Tested locally and on https://godbolt.org/z/KpYaup
[Bug c++/92910] New: Valid lambda inside variadic template does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92910
Bug ID: 92910
Summary: Valid lambda inside variadic template does not compile
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soko.slav at yandex dot ru
Target Milestone: ---
Code:
template
void foo()
{
(
[]
{
static_cast(nullptr);
}()
, ...
);
}
template void foo<>();
fails to compile with message
In lambda function:
:7:13: error: parameter packs not expanded with '...':
static_cast(nullptr);
:7:13: note: 'Ts'
: In function 'void foo()':
:8:10: error: operand of fold expression has no unexpanded parameter
packs
up to gcc-7.5 (x86-64)
compiles on gcc-8.1 and later
Tested locally and on https://godbolt.org/z/F2jR9U
[Bug libgomp/92843] [OpenACC] Wrong/missing dynamic reference counting for structured 'REFCOUNT_INFINITY'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
Thomas Schwinge changed:
What|Removed |Added
Assignee|jules at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Summary|[OpenACC] Disallow |[OpenACC] Wrong/missing
|'acc_delete' etc. for |dynamic reference counting
|everything without a|for structured
|dynamic reference count |'REFCOUNT_INFINITY'
--- Comment #10 from Thomas Schwinge ---
(In reply to myself from comment #1)
> I had assumed [...]
> But, I'm not sure now, after thinking through the following. ;-\
>
> Because: per my reading, it actually is permissible to call
> 'acc_delete'/etc. (dynamic reference counter; "present decrement" action)
> inside '#pragma acc data' (structured reference counter). This "decrements
> the [...] dynamic reference counter for 'var', if its value is greater than
> zero. If the reference counter is already zero, its value is left
> unchanged". The latter applies here. "If both reference counters are then
> zero, a delete action is performed." The structured reference counter is
> left untouched by 'acc_delete', so the data remains mapped; 'acc_delete'
> actually is a no-op?
>
> #define N 23
> float h[N];
>
> #pragma acc data create(h)
> {
> acc_delete(, 92); // no-op
> // 'h' remains mapped!
> }
I read OpenACC 2.6 again, and convince myself that indeed this seems to be the
expected behavior, thus adjusting this PR Summary, and testing adjusted patch.
[Bug c++/92909] New: ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909
Bug ID: 92909
Summary: ICE on incorrect lambda inside variadic template
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soko.slav at yandex dot ru
Target Milestone: ---
Code:
template
void foo()
{
[]
{
using T = Ts;
}();
}
template void foo<>();
fails to compile with message
: In lambda function:
:10:22: internal compiler error: in is_base_type, at dwarf2out.c:12893
template void foo<>();
starting from gcc-8.1 (x86-64) till now including trunk, modules and contracts
branches
does not ICE on gcc-7.5 and earlier
does not ICE without lambda
Tested locally and on https://godbolt.org/z/gWfqhB
[Bug target/92905] [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905 --- Comment #3 from Jakub Jelinek --- Note, it isn't about , using rm in the first alternative of the reverted define_insn works well too, as well as swapping the alternatives (that is in that case basically what the trunk has, except in the second alternative the second input is rm instead of m. If the second alternative of second input is m, it works the same as current trunk (unnecessary spill), if it is rm, it works well. Now, no idea if this isn't a bug in LRA or if there are some rules that the seemingly redundant constraints actually aren't redundant.
[Bug ipa/91374] [Missed optimization] Versioning opportunities to improve performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91374 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fxue at os dot amperecomputing.com
[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92908 --- Comment #1 from Zdenek Sojka --- Created attachment 47471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47471=edit reduced testcase
[Bug target/92908] New: [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92908 Bug ID: 92908 Summary: [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Output: $ x86_64-pc-linux-gnu-gcc -Og -fno-tree-fre -mavx512bw testcase.c $ sde64 -- ./a.out Aborted The generated code: mov eax, 1 # tmp89, kmovd k0, eax # tmp89, tmp89 vpmovm2wzmm0, k0# _3, tmp89 sets only v[0] = 0x, but it should set all elements to 0x $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-279212-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-279212-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20191211 (experimental) (GCC)
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #3 from Eric Botcazou --- The decision dates back to the rewrite of the SPARC port in 1998: 21652 davem /* Align to cache line in the function's code section. */ 21652 davem function_section (current_function_decl);
[Bug c++/92907] New: noexcept does not consider "const" in member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92907 Bug ID: 92907 Summary: noexcept does not consider "const" in member functions Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: HZ2012 at gmx dot at Target Milestone: --- Created attachment 47470 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47470=edit Source code example When the noexcept operator is used in the context of a const member function, const is not considered for the member variables i.e. the enclosed expample prints for gcc 9.1.0 noexcept(ca.g())=false but should print noexcept(ca.g())=true (as is done by clang 8.0.1) In addition, member variables are not found when they are declared after the noexcept operator.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |8.4 Summary|gcc 9.2 puts "jump tables" |jump tables are put in the |in the .text section|.text section Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- Nothing has changed in GCC 9.x and this is also visible with GCC 7 & 8, although the SPARC port is configured with JUMP_TABLES_IN_TEXT_SECTION set to 0.
[Bug target/92905] [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
In particular, reverting the:
--- gcc/config/i386/i386.md 2019-12-11 10:48:51.787820841 +0100
+++ gcc/config/i386/i386.md 2019-12-09 19:50:24.604955118 +0100
@@ -9223,10 +9223,10 @@
})
(define_insn "*_1"
- [(set (match_operand:SWI248 0 "nonimmediate_operand" "=r,rm")
+ [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm,r")
(any_or:SWI248
(match_operand:SWI248 1 "nonimmediate_operand" "%0,0")
-(match_operand:SWI248 2 "" ",r")))
+(match_operand:SWI248 2 "" "r,m")))
(clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (, mode, operands)"
"{}\t{%2, %0|%0, %2}"
change fixes it. I admit I have no idea why. It is true that the operands are
commutative, so RA can choose whether to put the constant or what used to be in
xmm0 into the destination register, previously it chose what results in better
code by putting the constant into the instruction and xmm0 moved into a GPR,
now it spills xmm0 instead, puts the constant into the destination register and
uses a memory operand. The above mentioned commit changed this for commutative
operands in several spots.
[Bug target/92905] [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org Component|rtl-optimization|target Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r273554.
[Bug libstdc++/92906] New: [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Bug ID: 92906 Summary: [10 regression] FAIL: libstdc++-abi/abi_check Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Blocks: 91985 Target Milestone: --- After r278684 all targets that do not support DFP now fail the libstdc++ ABI check. 9 incompatible symbols 0 _ZTIPKDf typeinfo for decimal32 const* version status: unversioned type: object type size: 32 status: subtracted 1 _ZTIPDe typeinfo for decimal128* version status: unversioned type: object type size: 32 status: subtracted 2 _ZTIPDd typeinfo for decimal64* version status: unversioned type: object type size: 32 status: subtracted 3 _ZTIPKDe typeinfo for decimal128 const* version status: unversioned type: object type size: 32 status: subtracted 4 _ZTIDf typeinfo for decimal32 version status: unversioned type: object type size: 16 status: subtracted 5 _ZTIDe typeinfo for decimal128 version status: unversioned type: object type size: 16 status: subtracted 6 _ZTIDd typeinfo for decimal64 version status: unversioned type: object type size: 16 status: subtracted 7 _ZTIPKDd typeinfo for decimal64 const* version status: unversioned type: object type size: 32 status: subtracted 8 _ZTIPDf typeinfo for decimal32* version status: unversioned type: object type size: 32 status: subtracted Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985 [Bug 91985] Unsupported DFP not diagnosed with constants or built-in functions
[Bug rtl-optimization/92905] New: [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
Bug ID: 92905
Summary: [10 Regression] Spills float-int union to memory
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
gcc-10 branch regressed for code that needs bitwise operations on floats:
float f(float x)
{
union {float f; unsigned i;} u = {x};
u.i |= 0x8000;
return u.f;
}
float my_copysign(float x, float y)
{
union {float f; unsigned i;} ux = {x}, uy ={y};
ux.i &= 0x7fff;
ux.i |= 0x8000 & uy.i;
return ux.f;
}
For function 'f' gcc-10 -O2 -mtune=intel generates
f:
movd%xmm0, -4(%rsp)
movl$-2147483648, %eax
orl -4(%rsp), %eax
movd%eax, %xmm0
ret
while gcc-9 and earlier generate code without stack use, even without
-mtune=intel:
f:
movd%xmm0, %eax
orl $-2147483648, %eax
movd%eax, %xmm0
ret
Likewise for the more realistic my_copysign, where ux is spilled, but uy is
not.
Eventually it would be nicer to use SSE bitwise operations for this, for
example LLVM already generates
f:
orps.LCPI0_0(%rip), %xmm0
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 --- Comment #2 from Frederik Harwath --- Created attachment 47469 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47469=edit Committed fix
[Bug fortran/92896] [10 Regression] [DEC] ICE in reduce_unary, at fortran/arith.c:1283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92896 Martin Liška changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||mark.eggleston at codethink dot co ||m, marxin at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #2 from Martin Liška --- Confirmed, started with r277975.
[Bug fortran/92897] [9/10 Regression] [Coarray] ICE in gfc_set_array_spec, at fortran/array.c:864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92897 Martin Liška changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/92898] [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92898 Martin Liška changed: What|Removed |Added Priority|P3 |P4 CC||marxin at gcc dot gnu.org
[Bug fortran/92897] [9/10 Regression] [Coarray] ICE in gfc_set_array_spec, at fortran/array.c:864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92897 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||kargl at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |9.3 Ever confirmed|0 |1 Known to fail||10.0, 9.2.1 --- Comment #1 from Martin Liška --- Confirmed, started with r276254.
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 --- Comment #1 from Frederik Harwath --- Author: frederik Date: Wed Dec 11 08:26:18 2019 New Revision: 279215 URL: https://gcc.gnu.org/viewcvs?rev=279215=gcc=rev Log: Fix PR92901: Change test expectation for C++ in OpenACC test clause-locations.c The columns of the clause locations that are reported for C and C++ are different and hence we need separate test expectations for both languages. 2019-12-11 Frederik Harwath PR other/92901 /gcc/testsuite/ * c-c++-common/clause-locations.c: Adjust test expectation for C++. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/clause-locations.c
