[Bug c/98418] New: Valid integer constant expressions based on expressions that trigger -Wshift-overflow are treated as non-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418
Bug ID: 98418
Summary: Valid integer constant expressions based on
expressions that trigger -Wshift-overflow are treated
as non-constants
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
This causes things like:
struct foo { unsigned bit: (0xll<<40)!=0; };
to elicit a -pedantic warning about the bitfield width not being a proper
integer constant expression, even though it is.
In other contexts, a complete compilation error might ensue:
extern int bar[ (0xll<<40)!=0 ]; //seen as an invalid VLA
https://gcc.godbolt.org/z/7zfz96
Neither clang nor gcc <= 5 appear to have this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241 seems related.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #5 from Michael Briggs --- Created attachment 49835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49835=edit C portion of test case The second part of an additional test case.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Michael Briggs changed: What|Removed |Added CC||briggs.michaels at gmail dot com --- Comment #4 from Michael Briggs --- Created attachment 49834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49834=edit fortran portion of test case
[Bug c++/98419] New: wrong code when destructor of local variable modifies returned object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98419
Bug ID: 98419
Summary: wrong code when destructor of local variable modifies
returned object
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
Version:
g++ (Compiler-Explorer-Build) 10.2.0
Command line options:
-std=c++17 -O2 -pedantic-errors
```
struct A {
int i;
A(int ** iptrptr): i(1) {
*iptrptr =
}
};
struct B {
int* iptr;
B(): iptr(0) {}
~B() {
*iptr = 2;
}
};
A foo() {
B b;
return A();
}
```
Observed behavior:
foo() returns an object with its `i` member having the value 1.
https://godbolt.org/z/Yhcjo9
Expected behavior:
foo() to return an object with its `i` member having the value 2.
The destruction of `b` is sequenced before the initialization of the returned
object. The constructor of A sets the int* contained in `b` to point within the
returned object (there is no temporary created with type A, C++17's mandatory
copy elision is assumed here). ~B() then sets the `i` member of the returned
object to 2.
Other observations:
With command line options `-std=c++17 -O0 -pedantic-errors -fsanitize=address`
~B() tramples the stack:
https://godbolt.org/z/M5ETa9
When A has a user-defined copy-constructor or destructor then I get the
expected behavior:
https://godbolt.org/z/osqbfz
https://godbolt.org/z/ozzPaf
Presumably when the returned type is trivially copyable then the copy isn't
elided, with the assumption that it's not observable. In C++17 the copy elision
is mandatory, and it is observable even for trivially copyable types, as shown
in this example.
[Bug bootstrap/98318] libcody breaks DragonFly bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318 --- Comment #6 from Nathan Sidwell --- FWIW my build server is CentOS Stream release 8 (x86_64), so it seems something's different in your setup. The toplevel make knows that libcody must be built before gcc. Perhaps the libcody build is failing, but not being reported? What happens if you cd into the libcody obj directory and try a 'make' there? (after you've hit the failure). What does that dir's config.log look like?
[Bug c++/98419] wrong code when destructor of local variable modifies returned object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98419 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- It seems you invoke a use-after-scope: g++ pr98419.C -fsanitize=address,undefined && ./a.out = ==31013==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffdf30 at pc 0x00401532 bp 0x7fffdec0 sp 0x7fffdeb8 WRITE of size 4 at 0x7fffdf30 thread T0 #0 0x401531 in B::~B() (/home/marxin/Programming/testcases/a.out+0x401531) #1 0x401293 in foo() (/home/marxin/Programming/testcases/a.out+0x401293) #2 0x4012fb in main (/home/marxin/Programming/testcases/a.out+0x4012fb) #3 0x7676e151 in __libc_start_main (/lib64/libc.so.6+0x28151) #4 0x4010fd in _start (/home/marxin/Programming/testcases/a.out+0x4010fd) Address 0x7fffdf30 is located in stack of thread T0 at offset 48 in frame #0 0x4011b5 in foo() (/home/marxin/Programming/testcases/a.out+0x4011b5) This frame has 2 object(s): [48, 52) '' <== Memory access at offset 48 is inside this variable [64, 72) 'b' (line 17) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope (/home/marxin/Programming/testcases/a.out+0x401531) in B::~B() Shadow bytes around the buggy address: 0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7bc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10007fff7be0: f1 f1 f1 f1 f1 f1[f8]f2 00 f3 f3 f3 00 00 00 00 0x10007fff7bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007fff7c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==31013==ABORTING
[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98324 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Nathan Sidwell --- Please let me know if the attached patch works for you or not.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #7 from Michael Briggs --- Comment on attachment 49834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49834 fortran portion of test case First part of a two part test case, Fortran & C. The bug appears as: malloc: *** error for object 0x7fff695a8eb8: pointer being freed was not allocated The problem is observed in gcc/gfortran 9.3.0 and 10.2.0 If the intent of "array" is changed from "out" to "inout" the program runs without any problem.
[Bug c++/98417] ICE when using C++ modules and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98417 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-22 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Summary|-internal compiler error|ICE when using C++ modules |when using -g |and -g
[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #18 from Uroš Bizjak --- Created attachment 49833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49833=edit Proposed patch Proposed patch that removes the sign from a temporary with FE_DOWNWARD, where x - x = -0.0
[Bug bootstrap/98412] libcody does not compile with older GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98412 --- Comment #10 from Nathan Sidwell --- Gerald got their first: * 7e63d383b89 2020-12-22 | c++: Fix build with clang
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #6 from Michael Briggs --- Comment on attachment 49834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49834 fortran portion of test case An additional test case, in two parts: Fortran & C. The bug appears as: malloc: *** error for object 0x7fff695a8eb8: pointer being freed was not allocated The problem is observed for gcc/gfortran 9.3.0 and 10.2.0 If the intent of "array" is changed from "out" to "inout" the program runs without any problem.
[Bug c/98418] Valid integer constant expressions based on expressions that trigger -Wshift-overflow are treated as non-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418 --- Comment #1 from Andrew Pinski --- Shifting into the sign bit is problematic. I cant remember the exact rules. Using ull is valid though.
[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 --- Comment #13 from Hongtao.liu --- Created attachment 49832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49832=edit gcc11-pr98348_v3.patch 1. Use REAL_VALUE_TO_TARGET_SINGLE/DOUBLE in the "float_vector_all_ones_operands" predicate, it should be cheaper than lower_subreg? 2. Combine failed to match (vec_merge (vector_all_ones_operand) (const0_operand) (knot mask)) even the corresponding pattern exists, peephole2 could be ok for this but abviously not the best solution. IMHO the changes about knot should be functionality ok, and to avoid some potential performance issue, I extraly add some new define_insn_and_splits to negate the comparison code when there's not in the result(Dig the hole deeper and deeper:(). The patch survive regtest and bootstrap on both trunk and rlease/gcc-10 branch.
[Bug c++/98417] New: -internal compiler error when using -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98417
Bug ID: 98417
Summary: -internal compiler error when using -g
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.kox at commandoregel dot be
Target Milestone: ---
I'm new so I hope this is the correct way to report this.
When using the -g flag with the C++20 modules example from the wiki
(https://gcc.gnu.org/wiki/cxx-modules) the compiler gives an internal compiler
error.
This is with version (g++ (GCC) 11.0.0 20201220 (experimental)).
The output of the compiler is:
g++ -g -Wall -fmodules-ts -c -MMD -MP -o hello.o hello.cc
g++ -g -Wall -fmodules-ts -c -MMD -MP -o main.o main.cc
main.cc: In function ‘int main()’:
main.cc:11:3: internal compiler error: in gen_typedef_die, at dwarf2out.c:25373
11 | greeter ("world");
| ^~~
0x7471d6 gen_typedef_die
../.././gcc/dwarf2out.c:25373
0x7471d6 gen_typedef_die
../.././gcc/dwarf2out.c:25345
0xcef8fa gen_decl_die
../.././gcc/dwarf2out.c:26377
0xcf1b13 gen_member_die
../.././gcc/dwarf2out.c:25188
0xcf1b13 gen_struct_or_union_type_die
../.././gcc/dwarf2out.c:25284
0xcf1b13 gen_tagged_type_die
../.././gcc/dwarf2out.c:25485
0xd0c8d9 gen_tagged_type_die
../.././gcc/dwarf2out.c:25439
0xd0c8d9 gen_typedef_die
../.././gcc/dwarf2out.c:25399
0xd0c8d9 gen_typedef_die
../.././gcc/dwarf2out.c:25345
0xcef8fa gen_decl_die
../.././gcc/dwarf2out.c:26377
0xcf4426 gen_type_die
../.././gcc/dwarf2out.c:25735
0xcef3c2 gen_decl_die
../.././gcc/dwarf2out.c:26374
0xcf05b3 dwarf2out_decl
../.././gcc/dwarf2out.c:26929
0xcf0b41 dwarf2out_type_decl
../.././gcc/dwarf2out.c:26647
0xcf0b41 dwarf2out_type_decl
../.././gcc/dwarf2out.c:26642
0xfd75f4 rest_of_type_compilation(tree_node*, int)
../.././gcc/passes.c:339
0xa1ec9d trees_in::read_class_def(tree_node*, tree_node*)
../.././gcc/cp/module.cc:12161
0xa204d9 module_state::read_cluster(unsigned int)
../.././gcc/cp/module.cc:14901
0xa20cfd module_state::load_section(unsigned int, binding_slot*)
../.././gcc/cp/module.cc:18032
0xa20dbf module_state::lazy_load(unsigned int, binding_slot*)
../.././gcc/cp/module.cc:18681
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/98415] [11 Regression] GCC crashes on Linux kernel build after r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98415 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- It's gone after r11-6281-gd8aeee11af715507, I can reproduce it with the original revision.
[Bug target/97847] [11 Regression] ICE in insert_insn_on_edge, at cfgrtl.c:1976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847 --- Comment #5 from Martin Liška --- @Vladimir: Can you please take a look?
[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Build|powerpc64-linux-gnu | Host|powerpc64-linux-gnu | Target|powerpc64-linux-gnu |powerpc64-linux-gnu, ||*-*-solaris2.11 --- Comment #1 from Rainer Orth --- The test FAILs in the same way on Solaris 11, both sparc and x86, 32 and 64-bit.
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #2 from John Paul Adrian Glaubitz --- I have started to bisect this now. aa80d0650ce612d88a62d072b63c2523d547fca8 is still good while HEAD is broken. It will take a while until I have a result as I have to perform this bisecting on qemu-user.
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341
--- Comment #3 from Marius Hillenbrand ---
Potential duplicate: I have seen very similar errors on s390x while reproducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
There, bisecting lead back to d119f34c952f ("New modref/ipa_modref optimization
passes"). In my tests, the first stage that is compiled with -flto then later
fails with errors of that kind (e.g., stage3 with config bootstrap-lto-lean).
.../gcc/build-ada3/./prev-gcc/xgcc -B/.../gcc/build-ada3/./prev-gcc/
-fchecking=1 -c -g -O2 -fchecking=1 -flto=jobserver -frandom-seed=1 -gnatpg
-gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface
-I..
/../gcc/ada -I../../gcc/ada/gcc-interface -Iada/libgnat -I../../gcc/ada/libgnat
../../gcc/ada/libgnat/a-elchha.adb -o ada/libgnat/a-elchha.o
+===GNAT BUG DETECTED==+
| 11.0.0 20201218 (experimental) (s390x-linux-gnu) Storage_Error stack overflow
or erroneous memory access|
| Error detected at a-elchha.adb:144:20|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ . |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
../../gcc/ada/gcc-interface/system.ads
../../gcc/ada/libgnat/a-elchha.adb
../../gcc/ada/libgnat/a-elchha.ads
../../gcc/ada/libgnat/a-except.ads
../../gcc/ada/libgnat/ada.ads
../../gcc/ada/libgnat/s-parame.ads
../../gcc/ada/libgnat/s-stalib.ads
../../gcc/ada/libgnat/a-unccon.ads
../../gcc/ada/libgnat/s-traent.ads
../../gcc/ada/libgnat/s-soflin.ads
../../gcc/ada/libgnat/s-secsta.ads
../../gcc/ada/libgnat/s-stoele.ads
../../gcc/ada/libgnat/s-stache.ads
and
.../gcc/build-ada3/./prev-gcc/xgcc -B/.../gcc/build-ada3/./prev-gcc/
-fchecking=1 -c -g -O2 -fchecking=1 -flto=jobserver -frandom-seed=1 -gnatpg
-gnata -W -Wall -g -O1 -fno-inline \
-nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc/ada
-I../../gcc/ada/gcc-interface -Iada/libgnat -I../
../gcc/ada/libgnat ../../gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o
+===GNAT BUG DETECTED==+
| 11.0.0 20201218 (experimental) (s390x-linux-gnu) Storage_Error stack overflow
or erroneous memory access|
| Error detected at a-exexda.adb:472:23|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ . |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
../../gcc/ada/gcc-interface/system.ads
../../gcc/ada/libgnat/a-except.adb
../../gcc/ada/libgnat/a-except.ads
../../gcc/ada/libgnat/ada.ads
../../gcc/ada/libgnat/s-parame.ads
../../gcc/ada/libgnat/s-stalib.ads
../../gcc/ada/libgnat/a-unccon.ads
../../gcc/ada/libgnat/s-traent.ads
../../gcc/ada/libgnat/s-except.ads
../../gcc/ada/libgnat/s-excdeb.ads
../../gcc/ada/libgnat/s-soflin.ads
../../gcc/ada/libgnat/s-secsta.ads
../../gcc/ada/libgnat/s-stoele.ads
../../gcc/ada/libgnat/s-stache.ads
../../gcc/ada/libgnat/s-wchcon.ads
../../gcc/ada/libgnat/s-wchstw.ads
../../gcc/ada/libgnat/s-traceb.ads
../../gcc/ada/libgnat/s-trasym.ads
../../gcc/ada/libgnat/s-exctab.ads
../../gcc/ada/libgnat/a-excach.adb
../../gcc/ada/libgnat/a-exexda.adb
[Bug libstdc++/98421] New: std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421
Bug ID: 98421
Summary: std::span does not detect invalid range in Debug Mode
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#define _GLIBCXX_DEBUG 1
#include
#include
int main()
{
std::vector coll;
coll.reserve(10);
std::span first3{coll.begin(), 3}; // or coll.data(), 3
}
This should abort, because coll.begin()+3 is undefined, violating the
precondition of the std::span constructor.
[Bug middle-end/98420] New: Invalid simplification of x - x with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98420
Bug ID: 98420
Summary: Invalid simplification of x - x with -frounding-math
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Split out from PR96793, where Marc says in c13:
-q-
x-x does depend on the rounding mode (the transformation in match.pd gets it
wrong, by the way).
-/q-
The testcase:
--cut here--
#include
double
__attribute__((noinline))
foo (double a)
{
return a - a;
}
int
main ()
{
double res;
fesetround (FE_DOWNWARD);
res = foo (1.11);
if (__builtin_signbit (res) == 0)
__builtin_abort ();
return 0;
}
--cut here--
aborts with -O2 -ffinite-math-only -frounding-math
Please note that x - x with FE_DOWNWARD should result in -0.0.
The problem is in match.pd, where:
(simplify
(minus @0 @0)
(if (!FLOAT_TYPE_P (type) || !HONOR_NANS (type))
{ build_zero_cst (type); }))
should involve flag_rounding_math in some way.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 --- Comment #12 from Matthias Klose --- Fyi, this is still seen with LLVM 11.0.1 rc2
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #8 from Marius Hillenbrand --- Potential duplicate observed for m68k: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Very similar error messages during bootstrap with lto.
[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793 --- Comment #19 from Uroš Bizjak --- https://gcc.gnu.org/g:337ed0eb490b14899f4049bc4c8922eb1d8a2e67 commit r11-6303-g337ed0eb490b14899f4049bc4c8922eb1d8a2e67 Author: Uros Bizjak Date: Tue Dec 22 18:13:24 2020 +0100 i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793] x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which is unable to change the sign from - to +. When FE_DOWNWARD rounding direction is in effect, the expanded sequence that involves subtraction can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive fails to change the sign of the intermediate value, assumed to always be positive, back to positive. The patch adds one extra fabs that strips the sign from the intermediate value when flag_rounding_math is in effect. 2020-12-22 Uroš Bizjak gcc/ PR target/96793 * config/i386/i386-expand.c (ix86_expand_floorceil): Remove the sign of the intermediate value for flag_rounding_math. (ix86_expand_floorceildf_32): Ditto. gcc/testsuite/ PR target/96793 * gcc.target/i386/pr96793.c: New test.
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ffd454b92ba6ff5499cf57f82a2b0f4cee59978c commit r11-6305-gffd454b92ba6ff5499cf57f82a2b0f4cee59978c Author: Jakub Jelinek Date: Tue Dec 22 20:18:10 2020 +0100 c++: Handle array members in build_comparison_op [PR93480] http://eel.is/c++draft/class.compare.default#6 says for the expanded list of subobjects: "In that list, any subobject of array type is recursively expanded to the sequence of its elements, in the order of increasing subscript." but build_comparison_op just tried to compare the whole arrays, which failed and therefore the defaulted comparison was deleted. The following patch instead compares the array elements, and if info.defining, adds runtime loops around it so that it iterates over increasing subscripts. For flexible array members it punts, we don't know how large those will be, for zero sized arrays it doesn't even try to compare the elements, because if there are no elements, there is nothing to compare, and for [1] arrays it will not emit a loop because it is enough to use [0] array ref to cover everything. 2020-12-21 Jakub Jelinek PR c++/93480 * method.c (common_comparison_type): If comps[i] is a TREE_LIST, use its TREE_VALUE instead. (build_comparison_op): Handle array members. * g++.dg/cpp2a/spaceship-synth10.C: New test. * g++.dg/cpp2a/spaceship-synth-neg5.C: New test.
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for GCC 11.
[Bug fortran/85877] [8/9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #5 from anlauf at gcc dot gnu.org --- I doubt that the testcase in comment#0 is actually valid. In fact, it is empirically rejected by most compilers. E.g. Intel v21: pr85877.f90(2): error #8067: If any bind-entity in a bind-stmt is an entity-name, the bind-stmt shall appear in the specification part of a module. [F] bind(c) f --^ pr85877.f90(3): error #6410: This name has not been declared as an array or a function. [F] x = f() --^ The F2018 standard has a few things here, e.g. on the BIND statement ! 8.6.4 BIND statement ! ... ! The BIND statement specifies the BIND attribute for a list of variables ! and common blocks. ! 18.3.6 Interoperability of procedures and procedure interfaces ! A Fortran procedure is interoperable if and only if it has the BIND ! attribute, that is, if its interface is specified with a ! proc-language-binding-spec. Since there is no explicit interface, c.f. ! 15.4.2.2 Explicit interface ! Within the scope of a procedure identifier, the procedure shall have an ! explicit interface if it is not a statement function and ! ... ! (6) the procedure has the BIND attribute. While I'm not sure that Intel has all the wording right, the reason is almost right. ;-) Thus changing to ice-on-invalid.
[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #15 from Jason Merrill --- (In reply to Richard Biener from comment #11) Yes, any delete-expression ends the lifetime of the pointed-to object before calling the delete operator, so it seems appropriate to say that it doesn't escape.
[Bug c++/97597] [11 Regression] ICE in build_over_call, at cp/call.c:9034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97597 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793 --- Comment #20 from Uroš Bizjak --- https://gcc.gnu.org/g:0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6 commit r10-9164-g0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6 Author: Uros Bizjak Date: Tue Dec 22 21:11:51 2020 +0100 i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793] x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which is unable to change the sign from - to +. When FE_DOWNWARD rounding direction is in effect, the expanded sequence that involves subtraction can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive fails to change the sign of the intermediate value, assumed to always be positive, back to positive. The patch adds one extra fabs that strips the sign from the intermediate value when flag_rounding_math is in effect. 2020-12-22 Uroš Bizjak gcc/ PR target/96793 * config/i386/i386-expand.c (ix86_expand_floorceil): Remove the sign of the intermediate value for flag_rounding_math. (ix86_expand_floorceildf_32): Ditto. gcc/testsuite/ PR target/96793 * gcc.target/i386/pr96793.c: New test.
[Bug c++/96045] [11 Regression] Wrong line and column diagnostic message in a class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Nathan Sidwell --- There's two conflicting arguments. a) the end of the file is just after the last \n (the preprocessor makes sure the file ends in \n). That's the first column of a line that doesn't exist. b) the EOF is just before the last \n (at the \n itself if you like). IIRC cpplib was taking both positions, and leading to inconsistencies. My intent was #a, as that's the more logical position of being after the \n. But it may not be the best choice. We do have to do some rewinding to deal with that non-existent line #a creates.
[Bug c++/96333] [10/11 Regression] Regression on concepts constraint checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96333 Jason Merrill changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jason Merrill --- I agree with Jonathan's analysis.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Keywords||ice-on-valid-code,
||wrong-code
--- Comment #21 from anlauf at gcc dot gnu.org ---
There's also valid code that ICEs, and invalid code that is silently accepted.
Invalid code:
program p
implicit none
integer, parameter :: b = 1
data b / 2 /
print *, b
end
Instead of being rejected, this prints:
1
One could catch this one in gfc_assign_data_value, but I haven't found out
yet how to get this right with derived type components, so there's possibly
a better place.
And after fixing an obvious NULL pointer dereference,
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 37a0c85fa30..783a0bbddcc 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr, gfc_typespec
*ts, bool array,
return false;
cm = expr->ts.u.derived->components;
for (c = gfc_constructor_first (expr->value.constructor);
- c; c = gfc_constructor_next (c), cm = cm->next)
+ c && cm; c = gfc_constructor_next (c), cm = cm->next)
{
if (!c->expr || cm->attr.allocatable)
continue;
we arrive at wrong code on valid input:
program p
implicit none
type t
real :: a
end type t
type(t) :: z = t(4.0)
data z%a /3.0/
print *, z%a
end
This now prints
4.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #22 from anlauf at gcc dot gnu.org --- The -fdump-fortran-original of the last example in comment#21 contains symtree: 'z' || symbol: 'z' type spec : (DERIVED t) attributes: (VARIABLE IMPLICIT-SAVE DATA) value: t(4. , 3.) so perhaps we should properly overwrite or merge with the default initializer instead of appending?
[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416
--- Comment #4 from Andrew Pinski ---
You need to use the target atrribute on CPU_ProbePower9 so GCC won't use power9
instructions on it.
Something like:
bool CPU_ProbePower9() __attribute__((target("cpu=power7")));
bool CPU_ProbePower9()
[Bug c++/98332] [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527 since r6-7607-g52228180f1e50cbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98332 --- Comment #2 from Jason Merrill --- (In reply to Martin Liška from comment #1) > Started with r6-7607-g52228180f1e50cbb. Rather, with r10-986-g9b9eb42a4168c342e5cd71b13d21e63ba7e1b7ab.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #25 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #24) > (In reply to anlauf from comment #21) > Looks like the patch from comment #2 that I posted 9 years ago. LoL. > Bug must not hit real code too often as no one has fixed it. Well, there are multiple places with almost identical un-code.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #27 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #26) > (In reply to kargl from comment #23) > > (In reply to anlauf from comment #21) > > > There's also valid code that ICEs, and invalid code that is silently > > > accepted. > > > > > > Invalid code: > > > > > > program p > > > implicit none > > > integer, parameter :: b = 1 > > > data b / 2 / > > > print *, b > > > end > > > > > > Instead of being rejected, this prints: > > >1 > > > > You need know about gfortran's extensions. > > > > % gfcx -Wall -o z -std=f95 a.f90 > > a.f90:4:12: > > > > 4 | data b / 2 / > > |1 > > Error: GNU Extension: re-initialization of 'b' at (1) > > I hope you noticed the PARAMETER, which should have been caught by > -fno-writable-parameters ... ;-) Yes, I did. Hopefully, you noticed the word EXTENSION. As an extension, gfortran swallows the code. :-)
[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jason Merrill --- As mentioned in the commit message, this change is the result of CWG issue 2369: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2369 Which moved checking of non-dependent conversions after checking the constraints for satisfaction. The rationale is that checking non-dependent conversions can also cause unwanted instantiations, and unwanted instantiations from satisfaction checking can be worked around by adding additional constraints, but constraints can only prevent unwanted instantiations from conversion checking if the constraints are checked first. Probably the standard library needs to add some constraints.
[Bug c++/96045] [11 Regression] Wrong line and column diagnostic message in a class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045 --- Comment #3 from Jason Merrill --- Nathan, this PR points out that your change to EOF location means that we no longer show the last line of source to give context for the error. Why not give the EOF token a location of the end of the last line?
[Bug c++/98419] wrong code when destructor of local variable modifies returned object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98419 --- Comment #2 from Lénárd Szolnoki --- This is probably invalid, I wasn't aware of http://eel.is/c++draft/class.temporary#3 > When an object of class type X is passed to or returned from a function, if X > has at least one eligible copy or move constructor ([special]), each such > constructor is trivial, and the destructor of X is either trivial or deleted, > implementations are permitted to create a temporary object to hold the > function parameter or result object.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #22 from Ev Drikos --- Created attachment 49836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49836=edit module + driver A slightly modified example gives me the impression that some local objects that are class arrays share the same Array Specification, even if they have been declared in a different scope, even they have quite different names and size. But they have been declared with an explicit shape that turns to be common, perhaps accidentally. The Array Specification is retrieved like that: as = IS_CLASS_ARRAY (sym) ? CLASS_DATA (sym)->as : sym->as; Ev. Drikos
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #23 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #21) > There's also valid code that ICEs, and invalid code that is silently > accepted. > > Invalid code: > > program p > implicit none > integer, parameter :: b = 1 > data b / 2 / > print *, b > end > > Instead of being rejected, this prints: >1 You need know about gfortran's extensions. % gfcx -Wall -o z -std=f95 a.f90 a.f90:4:12: 4 | data b / 2 / |1 Error: GNU Extension: re-initialization of 'b' at (1)
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #24 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
>
> And after fixing an obvious NULL pointer dereference,
>
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 37a0c85fa30..783a0bbddcc 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr,
> gfc_typespec *ts, bool array,
> return false;
>cm = expr->ts.u.derived->components;
>for (c = gfc_constructor_first (expr->value.constructor);
> - c; c = gfc_constructor_next (c), cm = cm->next)
> + c && cm; c = gfc_constructor_next (c), cm = cm->next)
> {
> if (!c->expr || cm->attr.allocatable)
> continue;
>
Looks like the patch from comment #2 that I posted 9 years ago. LoL.
Bug must not hit real code too often as no one has fixed it.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #26 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #23) > (In reply to anlauf from comment #21) > > There's also valid code that ICEs, and invalid code that is silently > > accepted. > > > > Invalid code: > > > > program p > > implicit none > > integer, parameter :: b = 1 > > data b / 2 / > > print *, b > > end > > > > Instead of being rejected, this prints: > >1 > > You need know about gfortran's extensions. > > % gfcx -Wall -o z -std=f95 a.f90 > a.f90:4:12: > > 4 | data b / 2 / > |1 > Error: GNU Extension: re-initialization of 'b' at (1) I hope you noticed the PARAMETER, which should have been caught by -fno-writable-parameters ... ;-)
[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 --- Comment #3 from Martin Uecker --- It seems this does not happen anymore after fixing PR98047.
[Bug c++/98413] [11 Regression] ICE with placement new since r11-3827-g83685efd5fd1623c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98413 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||ice-on-valid-code
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 Kip Warner changed: What|Removed |Added CC||kip at thevertigo dot com --- Comment #5 from Kip Warner --- I am experiencing the same problem with GCC 10.2.0. I have included and I am attempting to rely on std::ceilf. g++(1) bails with: error: ‘ceilf’ is not a member of ‘std’; did you mean ‘ceil’ $ g++ --version g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0
[Bug c++/98422] New: C++ 20 module ICE with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98422
Bug ID: 98422
Summary: C++ 20 module ICE with lto
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
import hello;
int main()
{
greeter("hello world");
}
cqwrteur@Home-Server:~/w/module$ g++ -c main.cc -Ofast -std=c++20 -s -flto
-s -fmodules-ts
main.cc:5:1: error: type variant differs by TYPE_MODE
5 | }
| ^
constant 128>
unit-size constant 16>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f54a6bd87e0
fields
sizes-gimplified public unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f54a6bd4b28
pointer_to_this >
used unsigned virtual DI /usr/local/include/c++/11.0.0/typeinfo:88:9
size unit-size
align:64 warn_if_not_align:0 offset_align 128
offset
bit-offset context
chain
used protected unsigned nonlocal decl_3 DI
/usr/local/include/c++/11.0.0/typeinfo:174:17 size unit-size
align:64 warn_if_not_align:0 offset_align 128 offset bit-offset context
>> context
pointer_to_this reference_to_this
>
constant 128>
unit-size constant 16>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f54a6bd
fields
sizes-gimplified public unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f54a6bd4b28
pointer_to_this >
used unsigned virtual DI /usr/local/include/c++/11.0.0/typeinfo:88:9
size unit-size
align:64 warn_if_not_align:0 offset_align 128
offset
bit-offset context
chain
used protected unsigned nonlocal decl_3 DI
/usr/local/include/c++/11.0.0/typeinfo:174:17 size unit-size
align:64 warn_if_not_align:0 offset_align 128 offset bit-offset context
>> context
pointer_to_this reference_to_this
>
during IPA pass: *free_lang_data
main.cc:5:1: internal compiler error: 'verify_type' failed
0x13937e5 verify_type(tree_node const*)
../../gcc/gcc/tree.c:14906
0x1396b33 free_lang_data
../../gcc/gcc/tree.c:6436
0x1396b33 execute
../../gcc/gcc/tree.c:6481
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98370 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans-Peter Nilsson --- Good deed of the year: I'm closing this as it's fixed for cris-elf *and* I see posted test-results for aarch64-elf/mabi=32 post r11-6260 (the fix), like https://gcc.gnu.org/pipermail/gcc-testresults/2020-December/639753.html
[Bug c++/98423] New: The defaulted default constructor defined as deleted when one of variant member has a default member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98423
Bug ID: 98423
Summary: The defaulted default constructor defined as deleted
when one of variant member has a default member
initializer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct A{
A(){}
};
union C{
A a;
int b = 0;
};
int main(){
C c;
}
GCC reports the default constructor for union `C` is defined as
deleted. However, the relevant rule in the current c++ standard says
that:
> A defaulted default constructor for class X is defined as deleted if:
>> X is a union that has a variant member with a non-trivial default
>> constructor and no variant member of X has a default member initializer,
>> X is a non-union class that has a variant member M with a non-trivial
>> default constructor and no variant member of the anonymous union containing
>> M has a default member initializer
In simple, as long as one of these variant members has a default
member initializer, then the default constructor for the containing
class will not be defined as deleted. In this example, the variant
member `b` has a default member initializer, hence `C::C()` should be
defined rather than deleted. Is it a bug?
GCC only agrees this code is supported:
struct A{
A(){}
};
union C{
A a{};
int b;
};
int main(){
C c;
}
If it is the right behavior, then the relevant rule should be described as:
> X is a union that has a variant member with a non-trivial default constructor
> and no default member initializer is supplied for the variant member.
However, the rule does not say this.
[Bug c++/98424] New: The point of destroying temporary objects when initializing an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98424
Bug ID: 98424
Summary: The point of destroying temporary objects when
initializing an array
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
#include
struct A{
A(int id):id_(id){}
~A(){
std::cout<<"destroy A with id: "A temporary object bound to a reference parameter in a function call persists
>until the completion of the full-expression containing the call.
That means all temporary objects should be destroyed after the initialization
for `arr` has completed. Presumably, it is a bug of GCC that when to destroy
these temporary objects
[Bug bootstrap/98318] libcody breaks DragonFly bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318 --- Comment #7 from Hao Liu --- I found that: 1. "make -j1" can pass, but "make -j8" always fails. It seems something wrong with parallel build 2. When "make -j8" failed, if I try "make -j8" again, it can pass. > What happens if you cd into the libcody obj directory and try a 'make' there? > (after you've hit the failure). I tried "make -j8" and libcody.a can be built successfully. This is why the 2nd "make -j8" try can pass. > What does that dir's config.log look like? The config.log look OK, as "make -j1" can always work well. I compared config.log of Ubuntu vs Centos, they are similar. The tail lines of config.log: --- /* confdefs.h */ #define PACKAGE_NAME "codylib" #define PACKAGE_TARNAME "codylib" #define PACKAGE_VERSION "0.0" #define PACKAGE_STRING "codylib 0.0" #define PACKAGE_BUGREPORT "github.com/urnathan/libcody" #define PACKAGE_URL "" #define BUGURL "github.com/urnathan/libcody" #define NMS_CHECKING 0 configure: exit 0 --- > The toplevel make knows that libcody must be built before gcc. So the problem seems to be why libcody.a is not built. The build log of "make -j8" on CentOS is strange, as it enters build/libcody/ and then leave the dir without doing anything. The log is as following: --- $ grep "libcody" out-j8.log checking for memchr... mkdir -p -- ./libcody checking for unistd.h... Configuring in ./libcody checking bugurl... github.com/urnathan/libcody checking for strtol... make[2]: Entering directory '.../build/libcody' checking whether gcc hidden aliases work... make[2]: Leaving directory '.../build/libcody' make[2]: *** No rule to make target '../libcody/libcody.a', needed by 'cc1-checksum.c'. Stop. --- It seems nothing happenend afer entering build/libcody, no building is triggered in build/libcody (If it is triggered, it should success just as manually run "make -j8" in build/libcody). The log of success job is: --- $ grep "libcody" out-j1.log mkdir -p -- ./libcody Configuring in ./libcody checking bugurl... github.com/urnathan/libcody make[2]: Entering directory '/home/ec2-user/gcc_tmp/build/libcody' g++ -g -O2 -fno-enforce-eh-specs -fno-stack-protector -fno-threadsafe-statics -fno-exceptions -fno-rtti -fdebug-prefix-map=../../gcc/libcody/= -W -Wall -include config.h -I../../gcc/libcody \ -MMD -MP -MF buffer.d -c -o buffer.o ../../gcc/libcody/buffer.cc ... ar -cr libcody.a buffer.o client.o fatal.o netclient.o netserver.o resolver.o packet.o server.o ranlib libcody.a make[2]: Leaving directory '.../build/libcody' --- Nathan, do you have any idea why libcody.a is not built with "make -j8"? It seems configure is OK but something wrong with parallel build. Other libraries (e.g. gmp, libdecnumber) don't have such problem. Thanks very much.
[Bug bootstrap/98318] libcody breaks DragonFly bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318 --- Comment #8 from Hao Liu --- Hi Nathan, The problem is related to use another make binary, which is 4.2.0 and built by ourselves. Maybe there is a strange bug. Anyway, after using the system installed make (which is 4.2.1 and under /usr/bin/), the problem is solved. Thanks for your help!
