https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
--- Comment #2 from Ulrich Drepper ---
(In reply to Andrew Pinski from comment #1)
> So this is due to differences in the languages themselves rather than due to
> C vs C++ front-end ...
This is certainly true for the validation.
But the
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this source and run it through a trunk version or earlier of the C++
frontend.
#include
int main() {
puts(“hello world”);
return 0;
}
This is the same
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this code which in a similar form was taken from a text document where the
smart quote handling used the U201c
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
The assume attribute is meant to help expressing more complex assumptions which
involve function calls. Given that interfaces should use std::optional
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Here is another example where with the help of the FP ranger capabilities the
compiler should generate better code than it does today (trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
--- Comment #4 from Ulrich Drepper ---
Actually, Jakub was right. This is a gdb issue. The gdb maintainers pointed
me to the trunk version and this indeed works with this simple code sequence.
There might have been a bug as in 107012 but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
--- Comment #2 from Ulrich Drepper ---
OK, I submitted:
https://sourceware.org/bugzilla/show_bug.cgi?id=29725
Let's see what they say.
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this code:
union node {
struct {
int a;
} l;
} x;
#define memory l.a
int main()
{
return x.memory;
}
When compiled with -gdwarf-4 -g3 and run in gdb, it is possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
--- Comment #2 from Ulrich Drepper ---
My original example and Andrew's g0 are handled by Aldy's patches
2022-09-26 Aldy Hernandez
PR tree-optimization/107009
* range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This code could be compiled to a simple return of the value 1 but it isn't
because the range information for n does not survive long enough.
int g(int n)
{
n
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Given an annotated saxpy function:
#include
void saxpy(size_t n, float* __restrict res, float a, const float* __restrict x,
const float* __restrict y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #9 from Ulrich Drepper ---
Created attachment 53419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419=edit
diff -y of current and proposed output
To compare the results more easily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
Ulrich Drepper changed:
What|Removed |Added
Attachment #53410|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #6 from Ulrich Drepper ---
Created attachment 53410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53410=edit
consistent pretty printing of contains
How about this patch?
I used the attached test case. With the current code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #5 from Ulrich Drepper ---
Or should the std::pair output even be
p1 = std::pair = {[0] = 0, [1] = 0}
??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #4 from Ulrich Drepper ---
Ugh, this one is a pasto:
v1 = std::vector of length 0, capacity 0 = { }
instead of
v1 = std::vector of length 0, capacity 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #3 from Ulrich Drepper ---
Actually, I think for the std::pair definition I'd like to see
p1 = {[0] = 0, [1] = 0}
instead of
p1 = {first = 0, second = 0}
Again, more uniform and I'd say it should be encouraged to use std::get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #6 from Ulrich Drepper ---
(In reply to Marek Polacek from comment #5)
> Fixed for GCC 13. I could probably backport to GCC 12, if desirable.
Thanks. And I certainly would appreciate a backport since this is an annoying
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #2 from Ulrich Drepper ---
Could something like this be added, it seems to have few chances if any to
disrupt any meaningful diagnostic while handling this specific case.
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
The discussion about this topic on gcc@
(https://gcc.gnu.org/pipermail/gcc/2022-May/238673.html) ended with the
conclusion that gcc should not disregard the cast in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
One use of 'if constexpr' is to handle different type sizes. This is a simple
example:
#include
using some_type = int;
some_type f();
bool foo()
{
if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103857
--- Comment #2 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #1)
> I don't think that's equivalent.
You're right, I tried to generalize the code and failed. I my actual case this
was a single variable the compiler saw the
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This test case is derived from actual code and I expect it to be not uncommon
in general. Maybe not exactly in this form but perhaps the matcher can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103749
--- Comment #4 from Ulrich Drepper ---
(In reply to Marek Polacek from comment #3)
> Hopefully that's a bit better.
This indeed looks as good as one can hope for. Thanks.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This problem isn't new in the trunk version, it exists in all versions I
tested.
This is the code in question
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile the following code:
struct foo {
virtual void f();
};
struct bar final : foo {
void f() final override;
};
It is correct and should compile but the function bar::f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #8 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #7)
> The sub fix won't be the same as would add, perhaps xor/or/and can be
> handled by the same peephole2, but even for that I'm not sure.
Just a proposal, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #6 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 50058 [details]
> gcc11-pr98737.patch
>
> Untested fix.
This only handles sub?
The same applies to add, or, and, xor. Maybe nand? Can
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Consider the following code:
long a;
_Bool f(long b)
{
return __atomic_sub_fetch(, b, __ATOMIC_RELEASE) == 0;
}
_Bool g(long b)
{
return (a -= b) == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97397
Ulrich Drepper changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This simple code
const char s[][3] = { "aa", "bb", "cc", "dd", "ee" };
unsigned f(unsigned x)
{
return s[x][1];
}
translate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92867
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this code
__attribute__((noinline))
int f(int a, int b)
{
return b - a + 5;
}
int foo(int a, int b)
{
return 1 + f(b, a);
}
int main()
{
return foo(39, 3
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
int foo(int a, int b)
{
if (b < a)
__builtin_unreachable();
if (a < 0)
ret
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile the following on x86-64:
unsigned f(long a)
{
return a == LONG_MIN;
}
The result for -O3 is:
f: movabs $0x8000,%rax
cmp%rax,%rdi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
With the introduction of char8_t there is a new error case in the printf format
checks:
#include
int main() {
auto s = u8"hello world";
#pragma GCC diagnostic error
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile the following code on x86-64 with -Ofast -march=haswell:
int f(__uint128_t m)
{
if (m < 64000)
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738
--- Comment #6 from Ulrich Drepper ---
(In reply to Martin Sebor from comment #5)
> If it did we could have GCC apply it implicitly to
> all such functions or operators defined in namespace std, and provide a new
> attribute to disable it in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738
--- Comment #3 from Ulrich Drepper ---
Created attachment 45416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45416=edit
Add nodiscard support
As Martin suggested, we could indeed use existing attributes in library code to
warn about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738
--- Comment #1 from Ulrich Drepper ---
BTW, this also applies to the "unused variable" warning as in the code below
but clang doesn't warn about that either.
#include
using type = std::shared_ptr;
type g;
int f(int a) {
auto p = g;
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
The implementations are obviously more complicated but the warning handling the
current implementation allows is less than optimal
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
I don't think the following should work and clang indeed complains. gcc 8.2.1
and current trunk both accept it without warning, even with -pedantic.
#include
int
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
When using
gcc -c -Q -O --help=optimizers
the driver leaves behind the help-dummy.o file. This happens with gcc trunk
and all prior versions I was able to test.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
int f(unsigned b)
{
int r;
if (b >= 2)
__builtin_unreachable();
switch (b) {
case 0:
r = 1;
break;
case 1:
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile the following code with the current trunk or gcc 8.2.1:
#include
#include
int rs(int s) {
std::array ar;
std::iota(ar.begin(), ar.end(), s);
return
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This is actually something I deliberate used if constexpr for to avoid warnings
but gcc creates a new kind of error. Take this silly code:
template
int foo(int a, int b
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Stroustrup in [1] §20.3.4 writes the compilers should issue warnings about
inconsistent use of explicit override controls.
struct foo {
virtual int one(int
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
This applies to gcc 7.3.1 as well, I tested the current 8 top of the tree as
well. Compile with g++:
#include
using T = std::tuple<int,int,int>;
T g() { return std::make_tuple
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compiling the invalid code at the bottom produces the following message:
y.cc: In function ‘auto bar::foo(int))(int)’:
y.cc:7:12: error: inconsistent deduction for auto return type
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
typedef double c_t;
typedef int a_t;
int f(a_t a1, a_t a2) {
return (c_t) a1 < (c_t) a2;
}
With IEEE 754 double we have a 52 bits mantissa wh
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
int f(unsigned a)
{
if ((a & 2) == 0)
return 0;
a += 4;
return (a & 2) != 0;
}
The addition clearly cannot affect th
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Consider the following code:
#define isnan(x) __builtin_isnan(x)
#define isfinite(x) __builtin_isfinite(x)
int f(double a, double b)
{
if (!isfinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80577
--- Comment #3 from drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at
gmail dot com> ---
(In reply to drepper.fsp+r...@gmail.com from comment #2)
> final isn't necessary in this case. An object is used and the type is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80577
--- Comment #2 from drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at
gmail dot com> ---
final isn't necessary in this case. An object is used and the type is known.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80660
--- Comment #2 from drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at
gmail dot com> ---
final shouldn't be needed in this case. It's an object that is used, the type
is known.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Consider the following code:
struct foo final {
int a = 0;
int b = 0;
void set_a(int p) { a = p; }
void set_b
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Consider the following code:
struct foo final {
int a = 0, b = 0;
int get1() const { return a; }
int get2() const { return a + b; }
};
foo f;
int (foo::*mfp)() const
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Created attachment 41288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41288=edit
example for ineffectiveness of fi
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Here is another case where the error message emitted by gcc (albeit, 6.2.1, I
don't have a more recent version handy
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile this code with a recent trunk gcc:
~~
int zero;
int one;
int two
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Created attachment 39701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39701=edit
Test case to show get_time vs strptime
Currently the get_time function s
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
With a declaration of 'f' as in the following code the function implementation
can assume that at least the given number of elements are available in the
array
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
When specifying a wrong command line option gcc reports the error as being on
the first line of the file and also prints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at gmail dot com> changed:
What|Removed |Added
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
For some architectures functions with different interfaces generate identical
code. For instance, on x86-64 (not the old x86 ABI):
double f1(int a, double b)
{
return a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912
--- Comment #2 from drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at
gmail dot com> ---
If it is accepted that this code should work (as I also expect) then this bug
should also be marked as a regression to 5.x. 6.1 at least is bro
: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
I haven't researched in detail what the accepted wisdom about this code is but
at the very least it is completely unnecessary to reject it, as the code shows.
Code like this is actually from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206
drepper.fsp+rhbz at gmail dot com drepper.fsp+rhbz at gmail dot com changed:
What|Removed |Added
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206
--- Comment #9 from drepper.fsp+rhbz at gmail dot com drepper.fsp+rhbz at
gmail dot com ---
Created attachment 35307
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35307action=edit
Little hello world
Probably copied from the documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206
drepper.fsp+rhbz at gmail dot com drepper.fsp+rhbz at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
The target attribute named default is handled special and this causes a
problem in error reporting. If I have code like this:
__attribute__((target(sse2,avx2)))
void foo(double *__restrict r
Assignee: dmalcolm at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Some users of the DSO created by the JIT (probably mostly debuggers) might have
a hard time getting to the file before it gets unlinked. For some gdb
versions, for instance, this is fatal. Try gdb
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Created attachment 33376
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33376action=edit
program to measure difference of the original and proposed optimized code
I've
: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
This happens with older versions as well and the problem is worse in more
complicated situations. This is the boiled-down version. Take this source:
struct c {
c(int a) : aa(a {}
int aa;
};
c v(1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59565
Ulrich Drepper drepper.fsp+rhbz at gmail dot com changed:
What|Removed |Added
CC||jason
++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
I see an ICE with both 4.8.2 and the trunk version on the following code when
compiled like this:
g++ -std=gnu++1y -c bug.cc -g
The backtrace is seen below. The code is simple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087
Ulrich Drepper drepper.fsp+rhbz at gmail dot com changed:
What|Removed |Added
CC
79 matches
Mail list logo
