[Bug c++/108262] New: Spurious [Wignored-attributes] on vector intrinsic types, even in constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108262
Bug ID: 108262
Summary: Spurious [Wignored-attributes] on vector intrinsic
types, even in constexpr contexts
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
We've been running into a peculiar issue where [Wignored-attributes] is
triggering on apparently benign uses of vector intrinsic types. Consider the
following example:
#include
template struct Wrap { T val; };
using WrapT = Wrap<__m128>;
This will produce (compiled with no arguments, which is a bit surprising; one
might expect "-std=c++17 -Wignored-attributes"):
:3:26: warning: ignoring attributes on template argument '__m128'
[-Wignored-attributes]
3 | using WrapT = Wrap<__m128>;
| ^
You can get a similar error with another test case:
#include
#include
constexpr inline bool b = std::is_same_v< int, __m128 >;
Clang, MSVC, and ICC all compile these examples cleanly, but GCC produces the
warning.
I believe the warning is erroneous. `__m128`, etc. are of course aligned,
which I assume is the "attribute" to which GCC is referring (bonus bug: it
would be helpful if this were specified!), however the attribute is not being
ignored in any way. In the first example, the alignment of `Wrap` inherits
from its members (easily confirmable with
`static_assert(alignof(WrapT)==16);`). In the second example, we're just using
`__m128` as a template argument, in the standard library no less.
The warning can be silenced with "-Wno-ignored-attributes".
This issue seems to have existed for a long time; the first example is a
distillation of https://stackoverflow.com/q/41676311/, and I have tested it as
reproducing all the way back to GCC 6.1.
Version: 13.0.0 20230101
System + Options: x86_64-linux-gnu
[Bug c++/107864] New: Internal Compiler Error (Large Project, C++20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864 Bug ID: 107864 Summary: Internal Compiler Error (Large Project, C++20) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at geometrian dot com Target Milestone: --- Created attachment 53962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53962&action=edit ".zip" file containing "main.cpp", the repro Using g++ built from source yesterday, getting internal compiler error (segfault) on a large C++20 project. A preprocessed file (lightly edited and zipped for file size limit) reproducing the error is attached. Compiled with: g++ main.cpp -std=c++20 -mavx2 The output begins with: In file included from /path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx/matr.hpp:7, from /path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx.hpp:254, from /path/to/mycodedistr/include/mycode/grfx/_cpu/../color/tuples.hpp:3, from /path/to/mycodedistr/include/mycode/grfx/_cpu/framebuffer.hpp:3, from /path/to/mycodedistr/src/mycode/grfx/_cpu/framebuffer.cpp:1: /path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx/_math.hpp: In instantiation of ‘T BR::Math::round(const T&) requires is_floating_point_v [with T = float]’: /path/to/mycodedistr/include/mycode/grfx/color/convert.hpp:132:29: required from here /path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx/_math.hpp:111:23: internal compiler error: Segmentation fault 0x7f3e5c1be51f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x7f3e5c1a5d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f3e5c1a5e3f __libc_start_main_impl ../csu/libc-start.c:392 Please submit a full bug report "gcc -v" includes: Target: x86_64-pc-linux-gnu Configured with: ../gcc-src/configure --enable-languages=c,c++ --enable-multiarch --program-suffix=-trunk gcc version 13.0.0 20221124 (experimental) (GCC)
[Bug tree-optimization/58926] -Wstrict-overflow unwanted warning comparing variables initialized from one of static duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58926 Ian Mallett changed: What|Removed |Added CC||ian at geometrian dot com --- Comment #2 from Ian Mallett --- Note that for this second example, the warning seems expected since there is no way to provide that `foobar(...)` wouldn't be called with e.g. `INT_MAX`, which would indeed cause a signed overflow (which would break the optimization, since the function would then be "expected" to return `true`).
[Bug c++/87129] New: -Wsign-conversion Erroneously Triggered When Dereferencing Pointer From Implicit User Conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87129
Bug ID: 87129
Summary: -Wsign-conversion Erroneously Triggered When
Dereferencing Pointer From Implicit User Conversion
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
When dereferencing a pointer created from calling an implicit user conversion,
g++ erroneously produces a warning from -Wsign-conversion about (inexplicably)
converting `size_t` into a signed integer type. If a pointer of the same type
is used instead, (correctly) no warning is generated.
Minimal sample:
//Compile with `-Wsign-conversion`
#include //`size_t`
extern float* data;
struct Accessor {
operator float*() {
return data;
}
};
float foo(Accessor accessor, size_t i) {
return accessor[i];
}
Output (9.0.0 20180824 x86-64):
: In function 'float foo(Accessor, size_t)':
:13:20: warning: conversion to 'long int' from 'size_t' {aka 'long
unsigned int'} may change the sign of the result [-Wsign-conversion]
13 | return accessor[i];
|^
Tested as occurring in many versions of g++, from 9.0 back to at least 4.4.
[Bug preprocessor/47857] Pragma once warning when compiling PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Ian Mallett changed: What|Removed |Added CC||ian at geometrian dot com --- Comment #7 from Ian Mallett --- I can also confirm this bug still exists in GCC 7.1.
[Bug c++/80157] New: Spurious "Wsign-conversion" warning with const, size_t, array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80157
Bug ID: 80157
Summary: Spurious "Wsign-conversion" warning with const,
size_t, array.
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
Minimal example (compile GCC >= ~6.1 with -Wsign-conversion):
#include
bool f(size_t const xy[2], int z) {
return xy[0] + xy[1] < static_cast(z);
}
Produces an erroneous warning:
: In function 'bool f(const size_t*, int)':
:3:25: warning: conversion to 'long unsigned int' from 'int' may
change the sign of the result [-Wsign-conversion]
return xy[0] + xy[1] < static_cast(z);
^~
Compiler exited with result code 0
Taking the const out, using unsigned, or passing x and y separately rather than
as an array resolves the warning. Doesn't occur on Clang, MSVC, or earlier
GCC.
May be related to bug 66170.
[Bug c++/77340] New: Invalid (Stack Smashing) Code Generated In Simple Cases With Debug-Mode Vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77340
Bug ID: 77340
Summary: Invalid (Stack Smashing) Code Generated In Simple
Cases With Debug-Mode Vectors
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
Simple test case:
//func.hpp
#define _GLIBCXX_DEBUG
#include
std::vector func();
//func.cpp
#include "func.hpp"
std::vector func() { return std::vector(); }
//main.cpp
#include //Necessary to cause error
#include "func.hpp"
int main(int /*argc*/, char* /*argv*/[]) {
func(); return 0;
}
Compile with "g++ *.cpp" and run ("./a.out"). Produces:
*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)
[Bug c++/77314] New: Allows C++11 POD types in anonymous structures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77314
Bug ID: 77314
Summary: Allows C++11 POD types in anonymous structures.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
Consider the following in >= C++11:
#include
struct MyType {
int val;
MyType(void) = default;
MyType(int v) : val(v) {}
}; static_assert(std::is_pod::value,"");
This POD type cannot be used in an anonymous structure. E.g.:
/* "error: member 'MyType Wrappert' with constructor
not allowed in anonymous aggregate" */
struct Wrapper { struct { MyType t; }; };
GCC is not required by standard to support anonymous structures at all (it need
only support unnamed structures), but since it does, it seems strange to limit
it in this way (it is unclear what conditions are disallowed, even). This
enhancement would relax the rules for anonymous structures, allowing any POD
type.
[Bug c++/70881] -Wunused-parameter incorrect for macro case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70881 Ian Mallett changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ian Mallett --- Indeed, that trailing \ is erroneous. This is a bug in the original code as well. Thanks and sorry for the noise.
[Bug c++/70881] New: -Wunused-parameter incorrect for macro case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70881 Bug ID: 70881 Summary: -Wunused-parameter incorrect for macro case Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at geometrian dot com Target Milestone: --- Created attachment 38380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38380&action=edit Simple example. In the attached example, adapted from real-world image-processing code, a macro is used to paste a case statement that contains a parameter. However, -Wunused-parameter reports that it is not used, erroneously. Produces: macro-example.cpp: In function 'ImageBase* get_new_diffabs(const ImageBase*, const ImageBase*)': 35 : warning: unused parameter 'img1' [-Wunused-parameter]
[Bug c++/70318] `std::sqrt(int)` Produces -Wfloat-conversion Warning, Erroneous After C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70318 --- Comment #2 from Ian Mallett --- "Did you interpret the standard as providing int sqrt(int);" Yes; I did. You're right; what is supposed to exist is just "double sqrt(int);". Sorry for the noise.
[Bug c++/70318] New: `std::sqrt(int)` Produces -Wfloat-conversion Warning, Erroneous After C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70318
Bug ID: 70318
Summary: `std::sqrt(int)` Produces -Wfloat-conversion
Warning, Erroneous After C++11.
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
Target Milestone: ---
Created attachment 38032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38032&action=edit
Sample given in text, as a file.
As required by the C++ standard, after C++11, the `std::sqrt` function in
`` is required to have "A set of overloads or a function template
accepting an argument of any integral type."
Consider the following command-line tool for computing integer-square root:
//Compile like so: g++ isqrt.cpp -std=c++11 -Wfloat-conversion -o isqrt
#include
#include
int main(int argc, char* argv[]) {
if (argc!=2) {
std::cout << "Usage: \"./isqrt [integer]\"" << std::endl;
return -1;
} else {
int arg = atoi(argv[1]);
int isqrt = std::sqrt(arg);
std::cout << isqrt << std::endl;
return isqrt;
}
}
When compiling as the comment says, a warning is produced:
isqrt.cpp: In function ‘int main(int, char**)’:
isqrt.cpp:10:33: warning: conversion to ‘int’ from
‘__gnu_cxx::__enable_if::__type {aka double}’ may alter its value
[-Wfloat-conversion]
int isqrt = std::sqrt(arg);
^
Internally, the argument is indeed converted to `double`, before doing the
square root with `double`s (at it should be). However, since the overload is
required to exist separately and explicitly (and it evidently doesn't), I think
this warning is erroneous.
For your convenience, my sample is also attached as a file.
[Bug c++/63391] New: Erroneous -Wsign-conversion with offsetof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63391
Bug ID: 63391
Summary: Erroneous -Wsign-conversion with offsetof
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
//Bug report:
//by Ian Mallett
//Compile with "g++ -std=c++11 -Wsign-conversion
#include
#include
struct Foo {
char data;
};
int main(int /*argc*/, char* /*argv*/[]) {
int num = 6;
#if 0 //No warning
size_t offset = offsetof(struct Foo,data);
delete [] new char[offset*static_cast(num)];
#else //warning
delete [] new char[offsetof(struct Foo,data)*static_cast(num)];
#endif
return 0;
}
[Bug c++/57793] New: Cross-Compiler Templates and Bitfields Ask to Report Problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Bug ID: 57793 Summary: Cross-Compiler Templates and Bitfields Ask to Report Problem Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at geometrian dot com Created attachment 30432 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30432&action=edit Self-contained example of problem Compile attached example: "i586-elf-gcc manager.cpp" Output from attached example: manager.cpp: In member function 'void* Block::malloc(size_t) [with unsigned int n = 2147483648u; size_t = unsigned int]': manager.cpp:71:4: internal compiler error: in get_bit_range, at expr.c:4562 info.allocated = true; ^ 0x7036e6 get_bit_range ../../gcc-4.8.1/gcc/expr.c:4562 0x7036e6 expand_assignment(tree_node*, tree_node*, bool) ../../gcc-4.8.1/gcc/expr.c:4703 0x655532 expand_gimple_stmt_1 ../../gcc-4.8.1/gcc/cfgexpand.c:2208 0x655532 expand_gimple_stmt ../../gcc-4.8.1/gcc/cfgexpand.c:2304 0x656436 expand_gimple_basic_block ../../gcc-4.8.1/gcc/cfgexpand.c:4138 0x65831e gimple_expand_cfg ../../gcc-4.8.1/gcc/cfgexpand.c:4657 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. The example is being developed from a kernel, so some operations may look strange. However, the example is self-contained. Platform: Ubuntu 12.04 x86-64, all updated Compiler: Cross compiler as described here: http://wiki.osdev.org/GCC_Cross-Compiler for i586-elf. Compiled for x86. Error does not occur with standard GCC (this may be because the standard GCC on the platform is x64-64).
