[Bug c/44511] Misdetects missing return with non-void return type, but only if the function is static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511 eggert at cs dot ucla.edu changed: What|Removed |Added CC||eggert at cs dot ucla.edu --- Comment #4 from eggert at cs dot ucla.edu --- We recently ran into this bug in Gnulib, and this affects downstream GNU test programs with threads that never return, because POSIX thread functions return 'void *'. For example, with GNU grep 3.6, './configure --enable-gcc-warnings; make' fails to build; see: https://bugs.gnu.org/44535 I worked around the problem by adding '#pragma GCC diagnostic ignored "-Wreturn-type"' to the Gnulib test module in question. It would be nice if such a workaround weren't needed.
[Bug c++/97934] Adding an operator== breaks implicit operator== generation from defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Per [class.compare.default] (http://eel.is/c++draft/class.compare.default#5.sentence-1 ), the == operator is implicitly generated if the member-specification does not declare *any* operator==. So the current behavior seems correct?
[Bug libstdc++/97935] Missing subsumption in iterator category detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |10.3 Last reconfirmed||2020-11-22
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #1 from H.J. Lu --- Also: FAIL: 29_atomics/atomic_integral/wait_notify.cc
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-22 Status|UNCONFIRMED |NEW
[Bug libstdc++/97936] New: [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Bug ID: 97936
Summary: [11 Regression] 30_threads/latch/3.cc hangs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
On Linux/x86-64 with 96 cores, r11-5227 with -m32 compiles30_threads/latch/3.cc
into:
2850299 hjl 20 0 23804 2364 2192 R 99.7 0.0 240:37.77 3.exe
(gdb) bt
#0 0xf7f9155d in __kernel_vsyscall ()
#1 0xf7babd7b in syscall () from /lib/libc.so.6
#2 0x08049566 in std::__detail::__platform_wait (__val=,
__addr=)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:99
#3 std::__atomic_wait(int const*,
int, std::latch::wait() const::{lambda()#1}) (__addr=0xff85ea30, __old=1,
__pred=...)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:276
#4 0x08049883 in std::latch::wait (this=0xff85ea30)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/latch:75
#5 std::latch::arrive_and_wait (__update=1, this=0xff85ea30)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/latch:82
#6 test01 ()
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/30_threads/latch/3.cc:43
#7 0x080492ef in main ()
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/30_threads/latch/3.cc:66
(gdb)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xff85ea30, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
[Bug libstdc++/97935] New: Missing subsumption in iterator category detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935
Bug ID: 97935
Summary: Missing subsumption in iterator category detection
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
In :
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_randacc_iterator<_Iter>)
struct __cat<_Iter>
{ using type = random_access_iterator_tag; };
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_bidi_iterator<_Iter>)
struct __cat<_Iter>
{ using type = bidirectional_iterator_tag; };
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_fwd_iterator<_Iter>)
struct __cat<_Iter>
{ using type = forward_iterator_tag; };
The !requires part of the constraints do not subsume each other, so any
iterator that is a __cpp17_bidi_iterator or stronger causes an ambiguity. It
needs to be extracted into a concept.
[Bug c++/54278] [6 regression] __attribute__((noreturn)) called from destructor when another auto-scoped variable has a non-trivial dtor erroneously fails with "control reaches end of non-void functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278 --- Comment #9 from Andrew Pinski --- (In reply to danikiw542 from comment #8) > https://kodlogs.com/blog/852/warning-control-reaches-end-non-void-function- > wreturn-type values not defined in enum's are still valid and well defined, that is a different issue all together and unrelated to this bug. There are others which have been closed as invalid for the reason mentioned here.
[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r11-5034-g253c415a1acba50711c82693426391743ac18040
[Bug c++/97934] Adding an operator== breaks implicit operator== generation from defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-21 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Keywords||rejects-valid --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97934] New: Defaulting <=> breaks other equality operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934
Bug ID: 97934
Summary: Defaulting <=> breaks other equality operators
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced example:
#include
struct X
{
auto operator<=>(X const&) const = default;
auto operator==(int i) const;
};
bool f(X x) {
return x == x;
}
gcc trunk rejects this saying no matching candidate. The presence of the
unrelated operator== seems to prevent the generation of X::operator==(X const&)
const from the defaulted <=>.
[Bug c++/94695] Implement -Wrange-loop-analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Implemented in GCC 11.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 94695, which changed state. Bug 94695 Summary: Implement -Wrange-loop-analysis https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/94695] Implement -Wrange-loop-analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c51e31a06f2c740c55852a683aa7ffdc20417362
commit r11-5234-gc51e31a06f2c740c55852a683aa7ffdc20417362
Author: Marek Polacek
Date: Mon Nov 9 21:15:33 2020 -0500
c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]
This patch finishes the second half of -Wrange-loop-construct I promised
to implement: it warns when a loop variable in a range-based for-loop is
initialized with a value of a different type resulting in a copy. For
instance:
int arr[10];
for (const double : arr) { ... }
where in every iteration we have to create and destroy a temporary value
of type double, to which we bind the reference. This could negatively
impact performance.
As per Clang, this doesn't warn when the range returns a copy, hence the
glvalue_p check.
gcc/ChangeLog:
PR c++/94695
* doc/invoke.texi: Update the -Wrange-loop-construct description.
gcc/cp/ChangeLog:
PR c++/94695
* parser.c (warn_for_range_copy): Warn when the loop variable is
initialized with a value of a different type resulting in a copy.
gcc/testsuite/ChangeLog:
PR c++/94695
* g++.dg/warn/Wrange-loop-construct2.C: New test.
[Bug c++/97846] No diagnostic for use of identifier label in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97846 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/97846] No diagnostic for use of identifier label in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97846 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6f20c42cc162ac3725584547ab4933bae4c78665 commit r11-5233-g6f20c42cc162ac3725584547ab4933bae4c78665 Author: Marek Polacek Date: Mon Nov 16 19:59:35 2020 -0500 c++: Reject identifier label in constexpr [PR97846] [dcl.constexpr]/3 says that the function-body of a constexpr function shall not contain an identifier label, but we aren't enforcing that. This patch implements that. Of course, we can't reject artificial labels. gcc/cp/ChangeLog: PR c++/97846 * constexpr.c (potential_constant_expression_1): Reject LABEL_EXPRs that use non-artifical LABEL_DECLs. gcc/testsuite/ChangeLog: PR c++/97846 * g++.dg/cpp1y/constexpr-label.C: New test.
[Bug c++/97881] [11 Regression] ICE in warn_about_ambiguous_parse, at cp/parser.c:20800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/97839] Template lambda incorrectly requiring the optional lambda-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/97881] [11 Regression] ICE in warn_about_ambiguous_parse, at cp/parser.c:20800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:0999f26098598fe0a499c5b79ad23678ccfe583a commit r11-5232-g0999f26098598fe0a499c5b79ad23678ccfe583a Author: Marek Polacek Date: Tue Nov 17 13:39:39 2020 -0500 c++: Fix ICE-on-invalid with -Wvexing-parse [PR97881] This invalid (?) code broke my assumption that if decl_specifiers->type is null, there must be any type-specifiers. Turn the assert into an if to fix this crash. gcc/cp/ChangeLog: PR c++/97881 * parser.c (warn_about_ambiguous_parse): Only assume "int" if we actually saw any type-specifiers. gcc/testsuite/ChangeLog: PR c++/97881 * g++.dg/warn/Wvexing-parse9.C: New test.
[Bug c++/97839] Template lambda incorrectly requiring the optional lambda-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:78cd6a63ee67ed854fbe54dd7c0a500dc138459a commit r11-5230-g78cd6a63ee67ed854fbe54dd7c0a500dc138459a Author: Marek Polacek Date: Tue Nov 17 11:38:25 2020 -0500 c++: Allow template lambdas without lambda-declarator [PR97839] Our implementation of template lambdas incorrectly requires the optional lambda-declarator. This was probably required by an early draft of generic lambdas, but now the production is [expr.prim.lambda.general]: lambda-expression: lambda-introducer lambda-declarator [opt] compound-statement lambda-introducer < template-parameter-list > requires-clause [opt] lambda-declarator [opt] compound-statement Therefore, we should accept the following test. gcc/cp/ChangeLog: PR c++/97839 * parser.c (cp_parser_lambda_declarator_opt): Don't require (). gcc/testsuite/ChangeLog: PR c++/97839 * g++.dg/cpp2a/lambda-generic8.C: New test.
[Bug c++/97427] constexpr destructor for const object incorrectly rejected as modifying const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427 --- Comment #3 from Marek Polacek --- Fixed on trunk. I plan to backport to 10.
[Bug c++/97427] constexpr destructor for const object incorrectly rejected as modifying const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:caf17f3afa83623c0f538f6c91c7699c4fdd5674 commit r11-5228-gcaf17f3afa83623c0f538f6c91c7699c4fdd5674 Author: Marek Polacek Date: Thu Nov 19 17:56:39 2020 -0500 c++: Fix wrong error with constexpr destructor [PR97427] When I implemented the code to detect modifying const objects in constexpr contexts, we couldn't have constexpr destructors, so I didn't consider them. But now we can and that caused a bogus error in this testcase: [class.dtor]p5 says that "const and volatile semantics are not applied on an object under destruction. They stop being in effect when the destructor for the most derived object starts." so we have to clear the TREE_READONLY flag we set on the object after the constructors have been called to mark it as no-longer-under-construction. In the ~Foo call it's now an object under destruction, so don't report those errors. gcc/cp/ChangeLog: PR c++/97427 * constexpr.c (cxx_set_object_constness): New function. (cxx_eval_call_expression): Set new_obj for destructors too. Call cxx_set_object_constness to set/unset TREE_READONLY of the object under construction/destruction. gcc/testsuite/ChangeLog: PR c++/97427 * g++.dg/cpp2a/constexpr-dtor10.C: New test.
[Bug c++/54278] [6 regression] __attribute__((noreturn)) called from destructor when another auto-scoped variable has a non-trivial dtor erroneously fails with "control reaches end of non-void functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278 danikiw542 at bcpfm dot com changed: What|Removed |Added CC||danikiw542 at bcpfm dot com --- Comment #8 from danikiw542 at bcpfm dot com --- This warning is as the admonition portrayed In kind with no value. If control arrives at the end of a function and no return is encountered, GCC accepts an arrival with no arrival value. However, for this, the capacity requires an arrival value. Toward the finish of the function, return suitable value, regardless of whether control never comes there. Also you can solve that by doing follows: The problem is that other compilers have a warning about "unreachable code". If every switch case is handled, the compiler detects that the return statement cannot be reached. I have to suppress this warning or use the preprocessor to only have that return statement on certain compilers. Something like this piece of code. Link to the code. https://kodlogs.com/blog/852/warning-control-reaches-end-non-void-function-wreturn-type
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #8 from Mikael Morin --- (In reply to Mikael Morin from comment #7) > Well, it doesn’t fix comment #5. :-( Pilot error, it does fix it.
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #7 from Mikael Morin --- (In reply to Mikael Morin from comment #6) > rough patch > Well, it doesn’t fix comment #5. :-(
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #6 from Mikael Morin --- Created attachment 49609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49609=edit rough patch OK, I understand better the problem. It’s not a bug that the kind argument is not used to produce code. It is known to be a constant, and that constant can be used directly at compile time. So it is the walking functions that should be fixed. I attach a rough patch doing that, it should sit on top of a full revert of pr91651.
[Bug fortran/97818] PDT Parameterized Derived Type fails with SIGABRT at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97818 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-21
[Bug fortran/97818] PDT Parameterized Derived Type fails with SIGABRT at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97818 --- Comment #1 from Dominique d'Humieres --- Confirmed from GCC8 up to trunk (for -O1 only). The code doesN't compile with GCC7.
[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927 --- Comment #7 from Dominique d'Humieres --- >just checked with today's trunk and --enable-checking=yes,extra,rtl > working there. What was the failing version?
[Bug bootstrap/97933] New: [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 Bug ID: 97933 Summary: [11 Regression] Bootstrap failure on s390x-linux Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- ../configure --target s390x-linux-gnu --enable-languages=c,c++ --enable-checking=release --disable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-gnu-indirect-function --with-long-double-128 --with-arch=zEC12 --with-tune=z13 --enable-decimal-float fails both profiledbootstrap and bootstrap (no LTO in either case), while building stage2 libgcc. The ICE is e.g. on decDouble.c: Program received signal SIGSEGV, Segmentation fault. 0x014b4012 in ipa_sra_function_summaries::duplicate(cgraph_node*, cgraph_node*, isra_func_summary*, isra_func_summary*) () Missing separate debuginfos, use: dnf debuginfo-install gmp-6.2.0-5.fc34.s390x isl-0.16.1-12.fc33.s390x libmpc-1.2.1-1.fc34.s390x libzstd-1.4.5-6.fc34.s390x mpfr-4.1.0-2.fc33.s390x zlib-1.2.11-23.fc34.s390x (gdb) up #1 0x014bec9c in function_summary::symtab_duplication(cgraph_node*, cgraph_node*, void*) () (gdb) #2 0x012e7a34 in symbol_table::call_cgraph_duplication_hooks(cgraph_node*, cgraph_node*) () (gdb) down #1 0x014bec9c in function_summary::symtab_duplication(cgraph_node*, cgraph_node*, void*) () (gdb) #0 0x014b4012 in ipa_sra_function_summaries::duplicate(cgraph_node*, cgraph_node*, isra_func_summary*, isra_func_summary*) () (gdb) Bottom (innermost) frame selected; you cannot go down. (gdb) bt #0 0x014b4012 in ipa_sra_function_summaries::duplicate(cgraph_node*, cgraph_node*, isra_func_summary*, isra_func_summary*) () #1 0x014bec9c in function_summary::symtab_duplication(cgraph_node*, cgraph_node*, void*) () #2 0x012e7a34 in symbol_table::call_cgraph_duplication_hooks(cgraph_node*, cgraph_node*) () #3 0x012fd466 in cgraph_node::create_virtual_clone(vec, vec*, ipa_param_adjustments*, char const*, unsigned int) () #4 0x014b7b90 in (anonymous namespace)::pass_ipa_sra::execute(function*) () #5 0x01631dac in execute_one_pass(opt_pass*) () #6 0x01632dce in execute_ipa_pass_list(opt_pass*) () #7 0x012f7140 in symbol_table::compile() [clone .part.0] () #8 0x012f9610 in symbol_table::finalize_compilation_unit() () #9 0x01706ad6 in compile_file() () #10 0x011731bc in toplev::main(int, char**) () #11 0x011750d8 in main () stage1 cc1 doesn't ICE though, nor can reproduce it in a cross-compiler from x86_64-linux (not even with valgrind annotations under valgrind), so maybe stage2 is miscompiled.
[Bug preprocessor/97577] [11 Regression] ICE: Segmentation fault (in get_location_from_adhoc_loc) by r11-4128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[11 Regression] ICE:|[11 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |get_location_from_adhoc_loc |get_location_from_adhoc_loc |) |) by r11-4128 Last reconfirmed||2020-11-21 CC||nathan at acm dot org --- Comment #2 from H.J. Lu --- It is caused by r11-4128.
[Bug c/97932] [8/9/10/11 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 H.J. Lu changed: What|Removed |Added CC||dmalcolm at redhat dot com Summary|Preprocessor, generated |[8/9/10/11 Regression] |error dumps most of the |Preprocessor, generated |source file, not just one |error dumps most of the |line. |source file, not just one ||line by r6-5941 Target Milestone|--- |8.5 --- Comment #4 from H.J. Lu --- It is caused by r6-5941.
[Bug c/97932] Preprocessor, generated error dumps most of the source file, not just one line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 Lance de la Haye changed: What|Removed |Added Version|8.2.0 |10.2.0 --- Comment #3 from Lance de la Haye --- Also verified with mingw64 build from winlibs.com gcc --version gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/97932] Preprocessor, generated error dumps most of the source file, not just one line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 --- Comment #2 from Lance de la Haye --- Also verified with mingw64 build from winlibs.com gcc --version gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/97932] Preprocessor, generated error dumps most of the source file, not just one line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||diagnostic
Last reconfirmed||2020-11-21
--- Comment #1 from Andrew Pinski ---
Confirmed,
Min example:
#define container_of( P, T, M ) ( (void)((P) - &((T*)0)->M), (T*)((char*)(P) -
(int)&((T*)0)->M) )
typedef struct {
short a;
short b;
} test_t;
int main( int argc, const char *argv[] )
{
short c;
char b;
tptr = container_of( b, test_t, b );
return 0;
}
CUT
For some reason the preprocessor or the C front-end thinks the range goes all
the way to the closing ) on the container_of line.
Mobile app to manage your employee status
Hi, *Greetings from Travelize!!* Setting up a hassle free work environment is what makes the Company beneficial. So, we are delighted to introduce our product “Travelize” Travelize helps you to, *1.* *Get to know your field sales teamwork-status.* *2.* *Schedule the Meetings/Task from Desktop/ Mobile* *3.* *Mark attendance easily from anywhere with GPS* *4.* *Record Sales details digitally* *5.* *Calculate the distance travelled* *6.* *Claim your Expenses Instantly* *7.* *Instant Leave Application and Approvals* *8.Track the employees working in remote areas* *9. Number of hours spent at the workplace will be recorded* *10. Locate your field executive in real-time with GPS.* *11.Number of hours spent at different branches of the organization will be recorded.* I’m also happy to arrange a brief web session to bring you up to the speed. *Let me know if you’ve questions or want to schedule the time to talk. * Hope to hear from you soon. Best Regards, *Vivek* *9066634800* TRAVELIZE *If you are not interested please reply in subject line as UNSUBSCRIBE* [image: beacon]
[Bug c/97932] New: Preprocessor, generated error dumps most of the source file, not just one line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 Bug ID: 97932 Summary: Preprocessor, generated error dumps most of the source file, not just one line. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lance.delahaye at gmail dot com Target Milestone: --- Created attachment 49608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49608=edit Minimal source (too many comments maybe) but no #includes needed. When error generated originating expanding #define, entire source between line of #define and the line invoking the macro is listed as error line. Can be hundreds of lines, most of the source file. Verified on 6.3 and 8.2, not tried most recent. Attached source .c file, no #include dependancies. To reproduce: gcc -C _gcc_container_of_bug.c gcc --version gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0 Copyright (C) 2018 Free Software Foundation, Inc.
