[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- Confirmed. Clang warns consistently, even at -O0: 87038.c:5:30: warning: variable 'foo' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized] case 0: ^ 87038.c:6:55: note: uninitialized use occurs here printf("foo is %d\n", foo); ^~~ 87038.c:4:25: note: variable 'foo' is declared here int foo = 3; ^ 1 warning generated.
[Bug c/87038] New: diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 Bug ID: 87038 Summary: diagnostics: Please add warning for jumping over initializers with switch/case in C mode Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: steinar+gcc at gunderson dot no Target Milestone: --- The other day, I had to debug (production!) code that essentially did this: void func(int x) { switch (x) { case 1: { int foo = 3; case 0: printf("foo is %d\n", foo); } } } If func is called with 0, “foo” is uninitialized, even though it doesn't look like it. There's a similar construction with goto: void func2(int x) { if (x == 0) goto lbl; int foo = 3; lbl: printf("foo is %d\n", foo); } In C++ mode, both constructs are rightfully rejected as an error. However, when compiling as C, there's not even a warning; sometimes, control flow analysis may detect that foo is used uninitialized, but not always. Would it be possible to have a warning in C mode that mirrors the C++ error? Ie. “jump to case label crosses initialization of 'int foo'”.
[Bug middle-end/86121] [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121 --- Comment #4 from Bernd Edlinger --- Author: edlinger Date: Tue Aug 21 08:56:11 2018 New Revision: 263693 URL: https://gcc.gnu.org/viewcvs?rev=263693&root=gcc&view=rev Log: 2018-08-21 Bernd Edlinger PR middle-end/86121 * tree-ssa-strlen.c (adjust_last_stmt): Avoid folding away undefined behaviour. testsuite: 2018-08-21 Bernd Edlinger PR middle-end/86121 * gcc.dg/Wstringop-overflow-6.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-6.c trunk/gcc/tree-ssa-strlen.c
[Bug c++/87035] Add "note: used here" to permerror about redeclaration changing the meaning of a name at class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|RESOLVED|NEW Last reconfirmed||2018-08-21 Resolution|INVALID |--- Summary|Can't shadow global const |Add "note: used here" to |int with unnamed enum in|permerror about |class |redeclaration changing the ||meaning of a name at class ||scope Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Jonathan Wakely --- Yup, this is ill-formed; no diagnostic required.(In reply to Andrew Pinski from comment #1) > Actually no this is invalid code at least according to the standard. Since Yup, ill-formed; no diagnostic required. GCC has been getting smarter about diagnosing these cases. > Maybe just the use of N is not in the error message. Yes, maybe a note pointing to the use of the name would be useful. t8.cc:5:10: error: declaration of ‘N’ [-fpermissive] enum { N }; // fails, redeclaration ^ t8.cc:1:11: error: changes meaning of ‘N’ from ‘const int N’ [-fpermissive] const int N = 5; ^ t8.cc:4:13: note: used here int Array[N]; // int[5] ^ Re-opening as a diagnostic bug.
[Bug libstdc++/87037] vector :: erase return value should be marked "must use"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87037 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- There's nothing strange about that at all. There are plenty of uses for erase where it's totally fine to ignore the return value. auto iter = std::find(v.begin(), v.end(), val); if (iter != v.end()) { do_something(*iter); v.erase(iter); } How do you propose to mark it so it only complains when you have a bug?
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 --- Comment #3 from Matthias Klose --- On 21.08.2018 09:53, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 > > --- Comment #1 from Andrew Pinski --- > For powerpc at least this is due to fma. Use -ffp-contract=off to turn it off. yes, -ffp-contract=off helps.
[Bug libstdc++/87037] New: vector :: erase return value should be marked "must use"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87037 Bug ID: 87037 Summary: vector :: erase return value should be marked "must use" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Given the following C++ source code # include using namespace std; void f( vector < int > & vec) { for (auto i = vec.begin(); i != vec.end(); ++i) { vec.erase( i); } } then there is an obvious bug that the return value from the erase isn't used for loop control. gcc seems strangely silent on the issue: $ ~/gcc/results.263644/bin/gcc -c -g -O2 -Wall -Wextra aug21a.cc $
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- For x86, this is due to using 80bit fp. See PR 323 for that one.
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Thomas Preud'homme changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Preud'homme --- As pointed by Jakub, commit was reverted in r263252. New iteration of the patch (currently still in testing) has been checked it doesn't have this regression. Best regards, Thomas
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 --- Comment #1 from Andrew Pinski --- For powerpc at least this is due to fma. Use -ffp-contract=off to turn it off.
[Bug jit/86845] libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86845 Richard Biener changed: What|Removed |Added Keywords||build CC||dmalcolm at gcc dot gnu.org --- Comment #1 from Richard Biener --- Well, looks like all the static libs of the in-tree prerequesites have to be compiled with -fPIC. We have host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true; extra_configure_flags='--disable-shared @extra_mpfr_configure_flags@'; extra_make_flags='AM_CFLAGS="-DNO_ASM"'; no_install= true; }; host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true; extra_configure_flags='--disable-shared @extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@ --disable-maintainer-mode'; no_install= true; }; host_modules= { module= isl; lib_path=.libs; bootstrap=true; extra_configure_flags='--disable-shared @extra_isl_gmp_configure_flags@'; extra_make_flags='V=1'; no_install= true; }; David? This is really only required for libjit ... :/
[Bug other/87036] New: -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 Bug ID: 87036 Summary: -O1/-O2 affects floating point precision on at least i686 and ppc64el Product: gcc Version: 6.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- [forwarded from http://bugs.debian.org/906753] no difference in the results on x86_64-linux-gnu, the bug submitter claims that clang 6.0 is working as expected. Seen on at least i686 and ppc64el. Same behaviour down to GCC 5 on both archs. on ppc64el: $ g++ -O0 tst.cc && ./a.out $ g++ -O2 tst.cc && ./a.out different mass sq values: 2.42 2.42 difference is : 3.55271e-15 on i686: $ g++ -O0 tst.cc && ./a.out $ g++ -O2 tst.cc && ./a.out different mass sq values: 2.42 2.42 difference is : 1.77636e-15 $cat tst.cc #include #include // for swap #include namespace HepMC { class FourVector { public: double m_x, m_y, m_z, m_t; FourVector( double xin, double yin, double zin, double tin=0) : m_x(xin), m_y(yin), m_z(zin), m_t(tin) {} inline double m2() const { return m_t*m_t - (m_x*m_x + m_y*m_y + m_z*m_z); } inline double m() const { double mm = m2(); return mm < 0.0 ? -std::sqrt(-mm) : std::sqrt(mm); } }; } // HepMC int main() { double eps = 1.e-15; // allowed differnce between doubles // FourVector HepMC::FourVector vector(1.1,2.2,3.3,4.4); HepMC::FourVector v4(1.1,2.2,3.3,4.4); //vector = v4; double masssq1 = v4.m2(); double mass1 = v4.m(); double masssq2 = vector.m2(); double mass2 = vector.m(); if( fabs( masssq1 - masssq2 ) > eps ) { std::cout << "different mass sq values: " << masssq1 << " " << masssq2 << std::endl; std::cout << "difference is : " << ( masssq1 - masssq2 ) << std::endl; } return 0; }
[Bug tree-optimization/86844] [8/9 regression] wrong code caused by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug middle-end/86840] __attribute__((optimize("exceptions"))) is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86840 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Richard Biener --- Hmm, we have DECL_FUNCTION_PERSONALITY which is used for keying. I guess "late" processing of -fexceptions doesn't cause that to be "set". So likely the optimize attributes are not processed at the time the personality is set.
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Richard Biener changed: What|Removed |Added Known to work||9.0 --- Comment #9 from Richard Biener --- Fixed on trunk(?). Is this a regression?
[Bug tree-optimization/86835] [8 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Has this been fixed? If so please close.
[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/86987] ICE in simplify_binary_operation_1, at simplify-rtx.c:3515 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86987 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #18 from Segher Boessenkool --- I have a patch.
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #4 from Nicolas Lesser --- Nice, thank you!
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #5 from Andrew Pinski --- [basic.scope.class] p2: "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule."
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #3 from Andrew Pinski --- (In reply to Nicolas Lesser from comment #2) > Huh, interesting. TIL. Where's that rule in the standard? Because I can't > find it in [class.mem]. Is it somewhere else or did I just overlook it? C++98 paragraph numbers: See 3.3.6/1 [...] 2) A name N used in a class S shall refer to the same declaration in its context and when reevaluated in the completed scope of S. No diagnostic is required for a violation of this rule. I think that is the same as [basic.scope.class].