[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=gcc=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 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 --- 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 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].
[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 #2 from Nicolas Lesser --- 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?
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
Actually no this is invalid code at least according to the standard. Since N
definition has to be the same when used and at the end of the scope. In this
case, you have a different one.
The error message is very clear about that too:
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;
^
Maybe just the use of N is not in the error message.
[Bug c++/87035] New: Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Bug ID: 87035
Summary: Can't shadow global const int with unnamed enum in
class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
const int N = 5;
struct X {
int Array[N]; // int[5]
enum { N }; // fails, redeclaration
};
This is well-formed, as the enum value N is in another scope and so shadows
::N. Removing the array declaration makes the code also compile.
