[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #21 from Iain Sandoe --- (In reply to Eric Gallager from comment #20) > (In reply to Jack Howarth from comment #16) > > (In reply to howarth from comment #15) > > > (In reply to howarth from comment #14) > > > > Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case > > > > correction of the overflow tests eliminates this bug. > > > > > > The proposed patch for correcting overflows doesn't eliminate this bug. > > > > With Jan's patch the failure still appears as... > > > > #0 0x7fff96238286 in __pthread_kill () > > #1 0x7fff9488042f in pthread_kill () > > #2 0x7fff8e9c1b53 in abort () > > #3 0x000100f32170 in linemap_lookup (set=0x10175e0f0, line=651) at > > ../../gcc-5-20150326/libcpp/line-map.c:806 > > Since the crash is in libcpp, cc-ing libcpp maintainers As per my current analysis, the crash is in the GC/PCH code. * This is repeatable outside the testsuite (between 4 and 400 attempts to trigger), so not an issue with the test framework. * It does not appear to affect Linux (10,000 attempts, no fail). There are two different failure modes: (1) it crashes with some error reported from within ggc_pch_read() (2) it hangs with either a signal caused by, or a crash within, ggc_pch_read() * When the hang occurs it appears to be a deadlock in memory management related to the diagnostic messages. 2 Thread_56911430 DispatchQueue_1: com.apple.main-thread (serial) 2 start (in libdyld.dylib) + 1 [0x142809235] 2 main (in cc1) + 47 [0x101085d4f] main.c:39 2 toplev::main(int, char**) (in cc1) + 320 [0x100c90ce0] toplev.c:2311 2 do_compile() (in cc1) + 269 [0x100c911ad] toplev.c:2176 2 compile_file() (in cc1) + 58 [0x100c92caa] toplev.c:456 2 c_common_parse_file() (in cc1) + 97 [0x1000f0911] c-opts.c:1151 2 c_parse_file() (in cc1) + 169 [0x100068999] c-parser.c:19760 2 c_common_pch_pragma(cpp_reader*, char const*) (in cc1) + 82 [0x1000f15a2] c-pch.c:433 2 c_common_read_pch(cpp_reader*, char const*, int, char const*) (in cc1) + 167 [0x1000f1437] c-pch.c:368 2 gt_pch_restore(__sFILE*) (in cc1) + 480 [0x1008df630] ggc-common.c:631 2 ggc_pch_read(__sFILE*, void*) (in cc1) + 751 [0x1006a47ff] ggc-page.c:2588 2 fatal_error(unsigned int, char const*, ...) (in cc1) + 196 [0x1010a60c4] diagnostic.c:1488 2 diagnostic_impl(rich_location*, int, char const*, __va_list_tag (*) [1], diagnostic_t) (in cc1) + 128 [0x1010a4b30] diagnostic.c:1138 As for the bug: it seems related to the two different call arcs for ggc_pch_read() A) when called 'normally' * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0001006a452a cc1`ggc_pch_read(f=0x7fffbbfd9148, addr=0x0001018e9000) at ggc-page.c:2557 [opt] frame #1: 0x0001008df630 cc1`gt_pch_restore(f=0x7fffbbfd9148) at ggc-common.c:631 [opt] frame #2: 0x0001000f1437 cc1`c_common_read_pch(pfile=0x000143001a00, name="./save-temps-1.h.gch", fd=, orig_name=) at c-pch.c:368 [opt] frame #3: 0x0001010df8d4 cc1`should_stack_file(pfile=0x000143001a00, file=0x000142f04e80, import=false, loc=4975) at files.c:814 [opt] frame #4: 0x0001010df758 cc1`::_cpp_stack_file(pfile=0x000143001a00, file=0x000142f04e80, import=, loc=) at files.c:900 [opt] frame #5: 0x0001010dfb4c cc1`::_cpp_stack_include(pfile=0x000143001a00, fname="save-temps-1.h", angle_brackets=0, type=IT_INCLUDE, loc=) at files.c:1049 [opt] frame #6: 0x0001010d92fd cc1`do_include_common(pfile=0x000143001a00, type=IT_INCLUDE) at directives.c:848 [opt] frame #7: 0x0001010d6a28 cc1`::_cpp_handle_directive(pfile=0x000143001a00, indented=) at directives.c:543 [opt] frame #8: 0x0001010e31b2 cc1`::_cpp_lex_token(pfile=0x000143001a00) at lex.c:2609 [opt] frame #9: 0x0001010eb488 cc1`cpp_get_token_1(pfile=0x000143001a00, location=0x7fff5fbff4bc) at macro.c:2703 [opt] frame #10: 0x0001000e24fe cc1`c_lex_with_flags(value=0x7fff5fbff4c0, loc=0x7fff5fbff4bc, cpp_flags="", lex_flags=0) at c-lex.c:405 [opt] frame #11: 0x0001000658b1 cc1`c_lex_one_token(parser=0x7fff5fbff4b0, token=0x7fff5fbff4b8) at c-parser.c:249 [opt] frame #12: 0x00010006585a cc1`c_parser_peek_token(parser=0x7fff5fbff4b0) at c-parser.c:436 [opt] frame #13: 0x000100068981 cc1`c_parse_file() at c-parser.c:19759 [opt] frame #14: 0x0001000f0911 cc1`c_common_parse_file() at c-opts.c:1151 [opt] frame #15: 0x000100c92caa cc1`compile_file() at toplev.c:456 [opt] frame #16: 0x000100c911ad cc1`do_compile() at toplev.c:2176 [opt] frame #17: 0x000100c90ce0 cc1`toplev::main(this=0x7fff5fbff690, argc=, argv=) at toplev.c:2311 [opt] B) when called for "-save-temps" it's triggered by processing #pragma GCC pch_preprocess "./save-temps-1.h.gch" * thread #1, queue = 'com.apple.main-thr
[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880 --- Comment #8 from Iain Sandoe --- I can see this on x86_64-darwin15 .. but not on darwin16, 17 or 18. please can you confirm that you definitely see this on darwin18? (and what your bootstrap compiler / config is). my tests were on 267418 with GCC5 as the bootstrap compiler on x86-64-darwin15 (for Ada support). On darwin16 it makes no difference if I use GCC or clang as the bootstrap compiler, on darwin17 and 18 I've only tried with clang as the bootstrap so far. Do you have SIP enabled, and did you install the target libs before running the tests?
[Bug c++/88628] New: lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
Bug ID: 88628
Summary: lambda expression in static_assert in if constexpr is
not evaluated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: merukun1125 at docomo dot ne.jp
Target Milestone: ---
The following code should fail to compile.
#include
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert([]{return false;}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
wandbox
https://wandbox.org/permlink/9FWcmSTY6uPEF09r
[Bug demangler/88629] New: Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88629 Bug ID: 88629 Summary: Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: wcventure at 126 dot com Target Milestone: --- Created attachment 45294 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45294&action=edit POC1 Hi, there. A Heap-buffer-overflow problem was discovered in function function d_expression_1 in cp-demangle.c of binutils latest code base, too. A crafted ELF input can cause segment faults and I have confirmed them with address sanitizer too. Please use the "./c++filt -t < $POC" to reproduce the bug. Note that this error only occurs in the last code base, maybe this is a regression error. I will show you the commit ID. > $ git log > commit ebb8004a18a3808d7197762faf3c5aaeae82371f > Author: GDB Administrator > Date: Wed Dec 19 00:00:21 2018 + > > Automatic date update in version.in The ASAN dumps the stack trace as follows: > = > ==83311==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x60200059 at pc 0x00ac9a4b bp 0x7ffeedce2490 sp 0x7ffeedce2488 > READ of size 1 at 0x60200059 thread T0 > #0 0xac9a4a in d_expression_1 > /binutils-gdb/libiberty/./cp-demangle.c:3356:12 > #1 0xab4724 in d_expression /binutils-gdb/libiberty/./cp-demangle.c:3531:9 > #2 0xaacdbe in cplus_demangle_type > /binutils-gdb/libiberty/./cp-demangle.c:2615:9 > #3 0xaaab09 in cplus_demangle_type > /binutils-gdb/libiberty/./cp-demangle.c:2411:10 > #4 0xaac400 in cplus_demangle_type > /binutils-gdb/libiberty/./cp-demangle.c:2568:26 > #5 0xaac400 in cplus_demangle_type > /binutils-gdb/libiberty/./cp-demangle.c:2568:26 > #6 0xab8dc1 in d_demangle_callback > /binutils-gdb/libiberty/./cp-demangle.c:6289:7 > #7 0xab7d4f in d_demangle /binutils-gdb/libiberty/./cp-demangle.c:6343:12 > #8 0xab7b66 in cplus_demangle_v3 > /binutils-gdb/libiberty/./cp-demangle.c:6500:10 > #9 0xa75571 in cplus_demangle /binutils-gdb/libiberty/./cplus-dem.c:881:13 > #10 0xa904ba in demangle_template_value_parm > /binutils-gdb/libiberty/./cplus-dem.c:2146:12 > #11 0xa8a190 in demangle_template > /binutils-gdb/libiberty/./cplus-dem.c:2331:14 > #12 0xa849c8 in demangle_signature > /binutils-gdb/libiberty/./cplus-dem.c:1709:18 > #13 0xa9715e in iterate_demangle_function > /binutils-gdb/libiberty/./cplus-dem.c:2761:14 > #14 0xa81759 in demangle_prefix > /binutils-gdb/libiberty/./cplus-dem.c:2989:14 > #15 0xa7a694 in internal_cplus_demangle > /binutils-gdb/libiberty/./cplus-dem.c:1254:14 > #16 0xa75cbb in cplus_demangle /binutils-gdb/libiberty/./cplus-dem.c:919:9 > #17 0x51518c in demangle_it /binutils-gdb/binutils/cxxfilt.c:66:12 > #18 0x5149e7 in main /binutils-gdb/binutils/cxxfilt.c:288:4 > #19 0x7f702142782f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #20 0x41ab28 in _start (/binutils-gdb/build/bin/c++filt+0x41ab28) > > 0x60200059 is located 0 bytes to the right of 9-byte region > [0x60200050,0x60200059) > allocated by thread T0 here: > #0 0x4daa50 in malloc > /home/tangyun/Documents/Git/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88 > #1 0xb0740f in xmalloc /binutils-gdb/libiberty/./xmalloc.c:147:12 > #2 0xa903af in demangle_template_value_parm > /binutils-gdb/libiberty/./cplus-dem.c:2138:18 > #3 0xa8a190 in demangle_template > /binutils-gdb/libiberty/./cplus-dem.c:2331:14 > #4 0xa849c8 in demangle_signature > /binutils-gdb/libiberty/./cplus-dem.c:1709:18 > #5 0xa9715e in iterate_demangle_function > /binutils-gdb/libiberty/./cplus-dem.c:2761:14 > #6 0xa81759 in demangle_prefix > /binutils-gdb/libiberty/./cplus-dem.c:2989:14 > #7 0xa7a694 in internal_cplus_demangle > /binutils-gdb/libiberty/./cplus-dem.c:1254:14 > #8 0xa75cbb in cplus_demangle /binutils-gdb/libiberty/./cplus-dem.c:919:9 > #9 0x51518c in demangle_it /binutils-gdb/binutils/cxxfilt.c:66:12 > #10 0x5149e7 in main /binutils-gdb/binutils/cxxfilt.c:288:4 > #11 0x7f702142782f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > SUMMARY: AddressSanitizer: heap-buffer-overflow > /binutils-gdb/libiberty/./cp-demangle.c:3356:12 in d_expression_1 > Shadow bytes around the buggy address: > 0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c047fff7ff0: 00
[Bug demangler/88629] Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88629 --- Comment #1 from Cheng Wen --- Created attachment 45295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45295&action=edit POC2
[Bug demangler/88629] Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88629 --- Comment #2 from Cheng Wen --- Created attachment 45296 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45296&action=edit POC3
[Bug libstdc++/88607] forward_list.h contains utf-8 charactor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607 --- Comment #4 from Jakub Jelinek --- Created attachment 45297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45297&action=edit gcc9-pr88607.patch Untested patch. Another option is do these changes (transliterations or removals) during make install, so that the UTF-8 characters are still used e.g. in the doxygen generated documentation. echo 'fi—éö§’' | iconv -f UTF-8// -t ASCII//TRANSLIT fi--eo?' so unlike my patch — is replaced by -- rather than just - and § is not removed, but ? used instead, though for the latter case I think removing of the section symbol is better. And we can't use iconv in make install, because not all hosts will have it.
[Bug demangler/88629] Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88629 --- Comment #3 from Cheng Wen --- That 's because "d_advance (di, 2);" in function d_expression_1, it change di->n = di + 2; leading to buffer-over-flow problem. > 3353 d_advance (di, 2); > 3354 if (peek == 't') > 3355 type = cplus_demangle_type (di); > 3356 if (!d_peek_next_char (di)) > 3357 return NULL;
[Bug tree-optimization/88621] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88621 --- Comment #2 from Jakub Jelinek --- The expander is unprepared to deal with MEM_REFs for bitfields, it really wants to see a COMPONENT_REF for those cases, but the r267296 code happily creates those. *mem is COMPONENT_REF with first argument VAR_DECL e and second argument FIELD_DECL b, (*slot)->mem.ref is a COMPONENT_REF with first argument MEM_REF[&e, 0] and second argument FIELD_DECL b and the code happily creates a MEM_REF out of this. So, either we need to punt for the bitfield cases, or e.g. handle the case where we have the same FIELD_DECL by creating a MEM_REF for the base and use COMPONENT_REF on top of that and punt otherwise.
[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87089 --- Comment #6 from Dmitry G. Dyachenko --- r267445 PASS
[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87089 --- Comment #7 from Dmitry G. Dyachenko --- (In reply to Dmitry G. Dyachenko from comment #6) > r267445 PASS sorry for noise 1. testcase from PR FAIL for me with r267445 2. real-world-code-compilation not FAIL
[Bug ipa/88586] ICE: Segmentation fault (in free_lang_data_in_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88586 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45298&action=edit gcc9-pr88586.patch Untested fix.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why do you think it should fail to compile? The static_assert in your example is a discarded statement.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628 --- Comment #2 from Jakub Jelinek --- clang++ agrees with g++ here. The lambda expression needs to be instantiated so that it can be evaluated and expressions in discarded statements are not instantiated.
[Bug c++/88613] [9 Regression] ICE in size_binop_loc at fold-const.c:1900 since r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88613 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The b should have been folded to 5 in the FE, but isn't and the lambda is for some reason not laid out and therefore it doesn't have DECL_FIELD_OFFSET computed.
[Bug ipa/88626] __builtin_constant_p should be as cheap as dead code for inlining purposes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88626 --- Comment #1 from Marc Glisse --- In my application (quite a bit bigger than the testcase...), looking at the optimized dump, I see that the function is inlined without the __builtin_constant_p code, but when I add the __builtin_constant_p code (__builtin_constant_p should essentially always be false in this case), a lot of calls remain. Writing __attribute__((always_inline)) on the function "fixes" the performance issue, it has no measurable impact on the original code, and gives the _bcp code the same perf as the code without _bcp. However, the attribute is not a real solution, "always" is too strong...
[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88624 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8.
[Bug c++/88613] [9 Regression] ICE in size_binop_loc at fold-const.c:1900 since r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88613 --- Comment #2 from Jakub Jelinek --- Seems it is fold_cache related, we are cp_folding (int) VIEW_CONVERT_EXPR != 5 and for the VIEW_CONVERT_EXPR for some reason find an entry in fold_cache that it is equivalent to a VAR_DECL x and thus undo the folding. I think the VCE is a location wrapper, and when being entered into the fold cache, org_x has been unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea94b930 precision:32 min max > public arg:0 used SI pr88613.C:5:13 size unit-size align:32 warn_if_not_align:0 context value-expr readonly arg:0 arg:0 > arg:1 pr88613.C:5:13 start: pr88613.C:5:13 finish: pr88613.C:5:13>> pr88613.C:5:13 start: pr88613.C:5:13 finish: pr88613.C:5:13> and x the VAR_DECL the location wrapper has as the argument. But later on mark_use modifies the VCE in place and nothing invalidates the fold cache.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
--- Comment #3 from merukun1125 at docomo dot ne.jp ---
(In reply to Jakub Jelinek from comment #2)
> clang++ agrees with g++ here. The lambda expression needs to be
> instantiated so that it can be evaluated and expressions in discarded
> statements are not instantiated.
#include
template
constexpr bool false_v = false;
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(false_v, "...");
}
int main() {
get();
}
This code does not fail to compile.
https://wandbox.org/permlink/jQB3P93GWTA2b4xs
But
#include
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(std::false_type{}, "...");
}
int main() {
get();
}
This code fail to compile.
https://wandbox.org/permlink/MyyxwVGorihFGW2G
So, I think that constexpr if is a function to suppress instantiation of
templates of unselected branches. In other words, the first phase of two-phase
name lookup is supposed to be executed.
So, I thought that lambda expressions without dependency names should be
evaluated.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
--- Comment #4 from Jakub Jelinek ---
lambda is AFAIK a local class, so you need to instantiate it. So it is more
similar to:
#include
template
constexpr bool run() { return false; }
template
T get() {
struct S {};
if constexpr (std::is_same_v) return 0;
else static_assert(run (), "Lambda expression is evaluated.");
}
int main() {
get();
}
which also compiles fine (and doesn't compile if you use say int or something
non-dependent in run template-id).
[Bug sanitizer/88619] [9 Regression] ICE in asan_emit_stack_protection, at asan.c:1574 since r266664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88619
--- Comment #2 from Martin Liška ---
Ok, so the problem was latent, for:
$ cat /tmp/ice.i
typedef int aligned __attribute__((aligned(64)));
int main () {
aligned b;
int *p = &b;
*(p - 1) = 123;
__builtin_alloca(b);
}
if I apply following debugging patch:
diff --git a/gcc/asan.c b/gcc/asan.c
index 45906bf8fee..3bf956c0aef 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1423,6 +1423,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
prev_offset = base_offset;
for (l = length; l; l -= 2)
{
+ fprintf (stderr, "RZ: %d - %d\n", offsets[l-1], offsets[l-2]);
if (l == 2)
cur_shadow_byte = ASAN_STACK_MAGIC_RIGHT;
offset = offsets[l - 1];
I see before the revision:
RZ: -96 - -64
RZ: -60 - -64
and:
This frame has 1 object(s):
[32, 36) 'b' (line 3) <== Memory access at offset 28 underflows this ...
0x10007fff7b60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1[f1]
0x10007fff7b80: 04 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
which is problematic as -60 > -64, the ranges should be increasing. As seen we
end with a wrong red zone ending with f2. That's caused by the old code that
emits always 4B of shadow memory at once.
So the problem is the alignment manipulation in expand_stack_vars that causes
the discrepancy. Jakub any idea how to fix that?
[Bug c++/88630] New: Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 Bug ID: 88630 Summary: Incorrect float negating together with convertion to int on SH4 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zavadovsky.yan at gmail dot com Target Milestone: --- Created attachment 45299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45299&action=edit main.cpp: code to trigger the bug Hello. I have some strange behavior with such simple code: float float_val = ; int int_val = -float_val; Problem is in "losing" negation. Real result of code execution looks like int int_val = float_val; E.g. if float_val==12.0f I am awaiting that int_val will be equal -12; And vice versa. But I got int_val==12 when float_val==12.0f; I.e. there was no negation. There is no such bug in GCC-4.x (checked 4.7.3 and 4.9.4). It begins since 5.x(I checked 5.4.0, 6.3.0, 7.4.0, 8.2.0). There is no such bug on x86-64, mips and arm with 4.6/4.7 and 6.3.0 compiler versions. Assembler from GCC-8.2.0 - works bad: sts fpscr,r1 mov.l .L2,r2 fnegfr5 xor r2,r1 lds r1,fpscr ftrcfr5,fpul sts fpul,r0 xor r2,r1 lds r1,fpscr rts Assembler from GCC-4.9.4 - works good: mov.l .L2,r1 lds.l @r1+,fpscr add #-4,r1 fnegfr5 add #4,r1 ftrcfr5,fpul sts fpul,r0 rts lds.l @r1+,fpscr I can see that FPU 'calculation' commands wasn't changed between compiler versions. But there was change of work with FPU status/control register. Can somebody say is it compiler bug or there is a problem with my code?
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #1 from Zavadovsky Yan --- Rewriting code as float float_val = ; int int_val = -(int)float_val; avoids bug. And rewriting code as double float_val = ; int int_val = -float_val; also avoids bug.
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #2 from Zavadovsky Yan --- Created attachment 45300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45300&action=edit main494.s: assembler output from GCC-4.9.4
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #3 from Zavadovsky Yan --- Created attachment 45301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45301&action=edit main820.s: assembler output from GCC-8.2.0
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #4 from Zavadovsky Yan --- Compilation command: sh4-unknown-linux-gnu-g++ --sysroot=../8.2.0/sh4-unknown-linux-gnu/sysroot -static -Os -o test820 main.cpp GCC info: Using built-in specs. COLLECT_GCC=../000_sh4_gcc/820/bin/sh4-unknown-linux-gnu-g++ COLLECT_LTO_WRAPPER=/yan/000_sh4_gcc/820/bin/../libexec/gcc/sh4-unknown-linux-gnu/8.2.0/lto-wrapper Target: sh4-unknown-linux-gnu Configured with: /yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=sh4-unknown-linux-gnu --prefix=/yan/000_sh4_gcc/ct-ng/../sh4-unknown-linux-gnu --with-sysroot=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot --enable-languages=c,c++ --with-pkgversion='crosstool-NG 1.23.0.580-eb72b4e' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libmpx --with-gmp=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-mpfr=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-mpc=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-isl=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --disable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++ -lm' --enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls --enable-multiarch --with-local-prefix=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot --enable-long-long Thread model: posix gcc version 8.2.0 (crosstool-NG 1.23.0.580-eb72b4e)
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #5 from Zavadovsky Yan --- Created attachment 45302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45302&action=edit main.ii: -save-temps output
[Bug c++/88613] [9 Regression] ICE in size_binop_loc at fold-const.c:1900 since r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88613 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-28 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- The modification-in-place in mark_use rather than returning a new tree instead has been added in https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
--- Comment #5 from merukun1125 at docomo dot ne.jp ---
(In reply to Jakub Jelinek from comment #4)
> lambda is AFAIK a local class, so you need to instantiate it. So it is more
> similar to:
> #include
>
> template
> constexpr bool run() { return false; }
>
> template
> T get() {
> struct S {};
> if constexpr (std::is_same_v) return 0;
> else static_assert(run (), "Lambda expression is evaluated.");
> }
>
> int main() {
> get();
> }
> which also compiles fine (and doesn't compile if you use say int or
> something non-dependent in run template-id).
I'm sorry, I was mistaken.
If a lambda expression is defined as a local class, it becomes as follows:
#include
template
T get() {
struct S {
auto operator()() const -> decltype(false) {
return false;
}
};
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
This code does not fail to compile because the compiler seems to need T to
determine the type of S.
https://wandbox.org/permlink/QtGF6wpvPr9rlhQ1
I was misunderstood as follows:
#include
struct S { // A type that does not depend on template parameter T
auto operator()() const -> decltype(false) {
return false;
}
};
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
This code fail to compile.
https://wandbox.org/permlink/628XClL8M3dnkD1Q
If you do not mind, please tell me the place if there is a place where lambda
expressions are defined as local classes in n4659 or n4791.
[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87089
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #8 from Martin Liška ---
It's still present for the following test-case:
$ cat 1.ii
namespace itpp {
template void b(a *c) { c[0].~a(); }
class CFix;
template class d {
void e(const char *);
CFix *data;
};
class CFix {
public:
virtual ~CFix();
};
template <> void d::e(const char *) { b(data); }
} // namespace itpp
$ cat 2.ii
namespace itpp {
enum a { b };
class CFix {
public:
virtual ~CFix();
};
template class c : CFix {
~c() {}
};
template class c<>;
} // namespace itpp
$ g++ -flto 1.ii 2.ii -shared -fPIC -O2
during IPA pass: devirt
lto1: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (namespace_decl) in type_with_linkage_p, at ipa-utils.h:185
0x6c7d51 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9856
0xa3a7fd tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3555
0xa3a7fd type_with_linkage_p(tree_node const*)
/home/marxin/Programming/gcc/gcc/ipa-utils.h:185
0xa3a7fd type_in_anonymous_namespace_p(tree_node const*)
/home/marxin/Programming/gcc/gcc/ipa-utils.h:221
0xa311ba maybe_record_node
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2531
0xa31c7c record_target_from_binfo
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2675
0xa31b4a record_target_from_binfo
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2687
0xa31fbd possible_polymorphic_call_targets_1
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2730
0xa37794 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:3351
0xa39559 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
/home/marxin/Programming/gcc/gcc/ipa-utils.h:118
0xa39559 ipa_devirt
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:3770
0xa39559 execute
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:4088
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
merukun1125 at docomo dot ne.jp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from merukun1125 at docomo dot ne.jp ---
(In reply to Jakub Jelinek from comment #4)
> lambda is AFAIK a local class, so you need to instantiate it. So it is more
> similar to:
> #include
>
> template
> constexpr bool run() { return false; }
>
> template
> T get() {
> struct S {};
> if constexpr (std::is_same_v) return 0;
> else static_assert(run (), "Lambda expression is evaluated.");
> }
>
> int main() {
> get();
> }
> which also compiles fine (and doesn't compile if you use say int or
> something non-dependent in run template-id).
I'm sorry, I was mistaken.
If a lambda expression is defined as a local class, it becomes as follows:
#include
template
T get() {
struct S {
auto operator()() const -> decltype(false) {
return false;
}
};
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
This code does not fail to compile because the compiler seems to need T to
determine the type of S.
https://wandbox.org/permlink/QtGF6wpvPr9rlhQ1
I was misunderstood as follows:
#include
struct S { // A type that does not depend on template parameter T
auto operator()() const -> decltype(false) {
return false;
}
};
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
This code fail to compile.
https://wandbox.org/permlink/628XClL8M3dnkD1Q
If you do not mind, please tell me the place if there is a place where lambda
expressions are defined as local classes in n4659 or n4791.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628 --- Comment #7 from Jakub Jelinek --- http://eel.is/c++draft/expr.prim.lambda.closure says: The type of a lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type, called the closure type, whose properties are described below. The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression. As the lambda expression in this case is contained in a block scope within the get function template, the closure type is declared there.
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628 --- Comment #8 from merukun1125 at docomo dot ne.jp --- (In reply to Jakub Jelinek from comment #7) > http://eel.is/c++draft/expr.prim.lambda.closure says: > > The type of a lambda-expression (which is also the type of the closure > object) is a unique, unnamed non-union class type, called the closure type, > whose properties are described below. > > The closure type is declared in the smallest block scope, class scope, or > namespace scope that contains the corresponding lambda-expression. > > As the lambda expression in this case is contained in a block scope within > the get function template, the closure type is declared there. Thank you, Jakub Jelinek!
[Bug c++/88628] lambda expression in static_assert in if constexpr is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88628
--- Comment #9 from merukun1125 at docomo dot ne.jp ---
Tn Comment 6, not
#include
struct S { // A type that does not depend on template parameter T
auto operator()() const -> decltype(false) {
return false;
}
};
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
It is right here:
#include
struct S {
constexpr S() = default;
constexpr auto operator()() const -> decltype(false) {
return false;
}
};
template
T get() {
if constexpr (std::is_same_v) return 0;
else static_assert(S{}(), "Lambda expression is evaluated.");
}
int main() {
get();
}
[Bug target/88616] ICE in gimplify_expr at gcc/gimplify.c:13363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616 --- Comment #1 from sudi at gcc dot gnu.org --- Started somewhere between r264874 and r266250. (I know the window is too big :()
[Bug target/88620] [7/8/9 Regression] ICE in assign_stack_temp_for_type, at function.c:837
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88620 sudi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/88620] [7/8/9 Regression] ICE in assign_stack_temp_for_type, at function.c:837
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88620 --- Comment #2 from sudi at gcc dot gnu.org --- Haven't looked very closely to PR82564 but it was marked as a possible duplicate to an already resolved ticket a year ago. In any case I can confirm this failure is still occurring for aarch64 trunk and last couple of release branches.
[Bug c++/88631] New: CTAD cannot deduce from () value initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88631
Bug ID: 88631
Summary: CTAD cannot deduce from () value initialization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
#include
template
class A {};
// A() -> A<>;
int main()
{
auto x = A(); // #1
auto x2 = A{}; // #2
A y;// #3
}
#1 fails, #2 and #3 succeeds, adding or removing the deduction guide doesn't
matter (thankfully). This causes users not able to write std::less().
[Bug libfortran/81984] NULL string pointer dereferencing forces undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81984 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Dec 28 18:26:09 2018 New Revision: 267452 URL: https://gcc.gnu.org/viewcvs?rev=267452&root=gcc&view=rev Log: 2018-12-28 Steven G. Kargl PR fortran/81984 * intrinsics/string_intrinsics_inc.c: Placate the sanitizer. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics_inc.c
[Bug libfortran/81984] NULL string pointer dereferencing forces undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81984 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 --- Comment #6 from Marc Glisse --- Created attachment 45303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45303&action=edit example patch (untested) Making the meaning of shuffles visible in GIMPLE could help a bit (although it wouldn't solve the problem completely because IIRC we don't dare combine shuffles, since it is hard to find an optimal expansion for a shuffle and we might pessimize some cases). This patch is one simple way to make _mm_shuffle_pd less opaque. _mm_shuffle_ps would be a bit longer but still manageable. It has the drawback that it does not diagnose when the mask is not a constant, or not between 0 and 3, and I am not sure how to do that from the C code. An alternative would be to keep the current builtin but turn it into a vec_perm_expr in ix86_gimple_fold_builtin, which could include diagnostics.
[Bug c++/86648] [9 Regression] ICE on class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648 --- Comment #6 from Alexandre Oliva --- https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01740.html
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 --- Comment #11 from Frédéric Buclin --- (In reply to Jonathan Wakely from comment #8) > Frédéric, any idea why your comment above caused Bugzilla to send the next > ten emails with your name on? They were old emails stuck in the queue, as you correctly guessed.
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- (In reply to Marc Glisse from comment #6) > Created attachment 45303 [details] > example patch (untested) > > Making the meaning of shuffles visible in GIMPLE could help a bit (although > it wouldn't solve the problem completely because IIRC we don't dare combine > shuffles, since it is hard to find an optimal expansion for a shuffle and we > might pessimize some cases). > This patch is one simple way to make _mm_shuffle_pd less opaque. > _mm_shuffle_ps would be a bit longer but still manageable. It has the > drawback that it does not diagnose when the mask is not a constant, or not > between 0 and 3, and I am not sure how to do that from the C code. An > alternative would be to keep the current builtin but turn it into a > vec_perm_expr in ix86_gimple_fold_builtin, which could include diagnostics. I think doing it in ix86_gimple_fold_builtin is better.
[Bug c++/88538] parse error with class nontype template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538 --- Comment #2 from Marek Polacek --- It seems though that the current grammar doesn't allow braced-init-list as a template-argument. Should we raise a DR?
[Bug c++/88631] CTAD cannot deduce from () value initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88631 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-28 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug fortran/88632] New: [F08] function contained in module invisible to submodule unless declared public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88632 Bug ID: 88632 Summary: [F08] function contained in module invisible to submodule unless declared public Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: joerg.stil...@tu-dresden.de Target Milestone: --- A function is declared in the contains-part of a module to provide a common functionality to different submodules. To make this function invisible to exterior program units using this module, the function is kept private. Nonetheless it should be visible to the submodules. However, with `gfortran` the function remains invisible to the submodule(s), which becomes apparent in the form of an `ld` error. This behavior can be fixed by declaring the the function public. To my understanding this is an error: The function should be visible to submodules even when private. Required information 1) Version of GCC $ gfortran --version GNU Fortran (MacPorts gcc8 8.2.0_3) 8.2.0 2) System type Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix 3) Options given when GCC was configured/built --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1 4) Complete command line that triggers the bug gfortran -o main parent.f90 decendent.f90 main.f90 5) Output of `gfortran -v -save-temps -o main parent.f90 decendent.f90 main.f90` Driving: gfortran-mp-8 -v -save-temps -o main parent.f90 decendent.f90 main.f90 -mmacosx-version-min=10.14.0 -asm_macosx_version_min=10.14 -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-mp-8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin18/8.2.0/lto-wrapper Target: x86_64-apple-darwin18 Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc8/gcc8/work/gcc-8.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin18 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc8 --includedir=/opt/local/include/gcc8 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-8 --with-gxx-include-dir=/opt/local/include/gcc8/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc8 8.2.0_3' --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk Thread model: posix gcc version 8.2.0 (MacPorts gcc8 8.2.0_3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'main' '-mmacosx-version-min=10.14.0' '-asm_macosx_version_min=10.14' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin18/8.2.0/f951 parent.f90 -fPIC -quiet -dumpbase parent.f90 -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase parent -version -fintrinsic-modules-path /opt/local/lib/gcc8/gcc/x86_64-apple-darwin18/8.2.0/finclude -o parent.s GNU Fortran (MacPorts gcc8 8.2.0_3) version 8.2.0 (x86_64-apple-darwin18) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (MacPorts gcc8 8.2.0_3) version 8.2.0 (x86_64-apple-darwin18) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'main' '-mmacosx-version-min=10.14.0' '-shared-libgcc' '-mtune=core2' /opt/local/bin/as -v -arch x86_64 -force_cpusubtype_ALL -o parent.o parent.s Apple Inc version cctools-921, GNU assembler version 1.38 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'main' '-mmacosx-version-min=10.14.0' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin18/8.2.0/f951 decendent.f90 -fPIC -quiet -dumpbase decendent.f90 -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase decendent -version -fintrinsic-modules-path /opt/local/lib/gcc8/gcc/x86_64-apple-darwin18/8.2.0/finclude -o decendent.s GNU Fortran (MacPorts gcc8 8.2.0_3) version 8.2.0 (x86_64-apple-darwin18) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100
[Bug c++/88572] error: braces around scalar initializer - should be a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #1 from Will Wray ---
This bug is straightforward to confirm.
Compile this snippet (-std=c++11 / 14 / 17 / 2a):
struct S { int i; };
S s{{0}};
Gives error: braces around scalar initializer for type 'int'
Should be a warning
(Or, follow the provided compiler explorer link to the test code
which includes two more failing cases - array and array member.)
The standard is clear that scalar brace init should be accepted:
C++14 [dcl.init.aggr]/2 says:
"Each member is copy-initialized from the corresponding initializer-clause.
[...] [ Note: If an initializer-clause is itself an initializer list, the
member is list-initialized, which will result in a recursive application of the
rules in this section if the member is an aggregate. — end note ]"
C++14 [dcl.init.list]/3.5:
"Otherwise, if the initializer list has a single element of type E and
either T is not a reference type or its referenced type is reference-related to
E, the object or reference is initialized from that element;"
Some historical links leading up to the wording fixes:
DR 155. Brace initializer for scalar
Explains it was a C/C++ incompatibility pre-11 and points to:
DR 632. Brace-enclosed initializer for scalar member of aggregate
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#632
"The initializer-list proposal will resolve this issue..."
As stated, it was resolved in C++11 by Initializer Lists:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm
1501. Nested braces in list-initialization
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1501
DR1467 List-initialization of aggregate from same-type object
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1467
Submitter: Jason Merrill Date: 2012-02-06
[Moved to DR at the November, 2014 meeting.]
Please CONFIRM this bug.
[Bug libstdc++/88607] forward_list.h contains utf-8 charactor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607 --- Comment #5 from Jonathan Wakely --- These characters come from copying & pasting text from the PDF of the C++ standard, which uses ligatures. We should just replace the ligature.
[Bug libstdc++/88607] forward_list.h contains utf-8 charactor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607 --- Comment #6 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #4) > Created attachment 45297 [details] > gcc9-pr88607.patch > > Untested patch. Another option is do these changes (transliterations or > removals) during make install, so that the UTF-8 characters are still used > e.g. in the doxygen generated documentation. > echo 'fi—éö§’' | iconv -f UTF-8// -t ASCII//TRANSLIT > fi--eo?' > so unlike my patch — is replaced by -- rather than just - and § is not > removed, but ? used instead, though for the latter case I think removing of > the section symbol is better. And we can't use iconv in make install, > because not all hosts will have it. That seems like overkill. The ligatures can be replaced. Paragraph symbols can be removed. Accents in names are the only valid reason to use non-ascii characters.
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 --- Comment #12 from Frédéric Buclin --- Created attachment 45304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45304&action=edit patch, v1 Patch applied.
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 Frédéric Buclin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Frédéric Buclin --- Tested and working fine.
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 Frédéric Buclin changed: What|Removed |Added Attachment #45304|0 |1 is obsolete|| --- Comment #14 from Frédéric Buclin --- Created attachment 45305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45305&action=edit patch, v1.1 Forgot to include the new template in the patch.
[Bug web/88108] Remove misleading "raw unified" link from Bugzilla patch viewer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88108 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-29 Assignee|unassigned at gcc dot gnu.org |LpSolit at gmail dot com Ever confirmed|0 |1
[Bug web/88108] Remove misleading "raw unified" link from Bugzilla patch viewer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88108 Frédéric Buclin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Frédéric Buclin --- Done
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #11 from Shafik Yaghmour --- Bumping, it has been a while. I ran into this reviewing [diff.cpp11.expr] https://timsong-cpp.github.io/cppwp/n4659/diff.cpp11.expr and noticed the code in the example similar to the reduced sample fails to compile with current gcc trunk godbolt: https://godbolt.org/z/Ihm9Ps
[Bug debug/49167] dwarf marker for function return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167 --- Comment #5 from Alexandre Oliva --- I've been working on an off on this specific issue, and on various surrounding infrastructure issues, for a very long time. Right now I'm not specifically working on it.
[Bug ada/88591] [9 regression] libada install fails with --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88591
jamespharvey20 at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from jamespharvey20 at gmail dot com ---
Apologies. Those 2 errors were red herrings that got me by looking for where
things first went wrong. These 2 errors appear the way Arch build gcc, even on
8.2.1. They're not fatal errors. Per the revision's comments, "make...
install-gnatlib" just needed to be changed to "make... install-libada". This
command comes just after the "make ada-install-{common,info}" which is what
threw me.
[Bug bootstrap/88633] New: stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88633 Bug ID: 88633 Summary: stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org Target Milestone: --- This has been repeatable and while configure and stage 1 seems fine the process fails in stage 2 thus : arm7$ uname -a Linux arm7 4.4.132+ #1 SMP Tue Oct 23 18:03:49 CST 2018 armv7l GNU/Linux arm7$ cat /etc/debian_version 9.6 arm7$ date -u Fri Dec 28 12:42:15 UTC 2018 A set of essential tools and libs are already built, tested and installed into the path /opt/bw and that includes libiconv and gettext. arm7$ LD_RUN_PATH=/opt/bw/lib LD_FLAGS=\-L/opt/bw/lib \ > RUNPATH=/opt/bw/lib \ > ../gcc-8.2.0/configure \ > --build=armv7l-linux-gnueabihf \ > --target=armv7l-linux-gnueabihf \ > --host=armv7l-linux-gnueabihf \ > --prefix=/opt/intermediate/gcc8 \ > --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap \ > --enable-linker-build-id --libexecdir=/opt/bw/lib --libdir=/opt/bw/lib \ > --with-system-zlib --with-target-system-zlib \ > --enable-multiarch --with-arch=armv7-a --with-fpu=vfpv4-d16 \ > --with-float=hard --with-mode=thumb --enable-checking=release \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-__cxa_atexit \ > --with-long-double-128 --enable-stage1-languages=c,c++ \ > --enable-stage1-checking=misc --with-as=/usr/bin/as --with-ld=/usr/bin/ld \ > --enable-languages=c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix intermediate Fri Dec 28 12:42:15 UTC 2018' checking build system type... armv7l-unknown-linux-gnueabihf checking host system type... armv7l-unknown-linux-gnueabihf checking target system type... armv7l-unknown-linux-gnueabihf checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libmpx support... no checking for libhsail-rt support... no checking for armv7l-linux-gnueabihf-gcc... /usr/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for armv7l-linux-gnueabihf-gnatbind... no checking for gnatbind... no checking for armv7l-linux-gnueabihf-gnatmake... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check *** This configuration is not supported in the following subdirectories: zlib target-libmpx gnattools target-libada target-libhsail-rt target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... /opt/bw/bin/m4 checking for flex... no checking for lex... no checking for flex... no checking for makeinfo... no /opt/bw/build/gcc-8.2.0/missing: 81: /opt/bw/build/gcc-8.2.0/missing: makeinfo: not found checking for expect... no checking for runtest... no checking for ar... (cached) /usr/bin/ar checking for armv7l-linux-gnueabihf-ar... (cached) /usr/bin/ar checking for as... (cached) /usr/bin/as checking for armv7l-linux-gnueabihf-as... (cached) /usr/bin/as checking for armv7l-linux-gnueabihf-dlltool... no checking for dlltool... no checking for ld... (cached) /usr/bin/ld checking for armv7l-linux-gnueabihf-ld... (cached) /usr/bin/ld checking for armv7l-linux-gnueabihf-lipo... no checking for lipo... no checking for armv7l-linux-gnueabihf-nm... no checking for nm... nm checking for ranlib... (cached) /usr/bin/ranlib checking for armv7l-linux-gnueabihf-ranlib... (cached) /usr/bin/ranlib checking for strip... (cached) /usr/bin/strip checking for armv7l-linux-gnueabihf-strip... (cached) /usr/bin/strip checking for armv7l-linux-gnueabihf-windres... no checking for windres... no checking for armv7l-linux-
