https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119765
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119558
--- Comment #3 from Peter Damianov ---
the -fdeclone-ctor-dtor ICE is PR108383
I put a reduced testcase there but unfortunately no one confirmed it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119544
Bug ID: 119544
Summary: gcc does not figure out variable is unused when
incremented in while loop
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512
--- Comment #3 from Peter Damianov ---
Created attachment 60913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60913&action=edit
Original unreduced testcase
(I reduced this badly in the bug report - this doesn't diagnose at any
optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512
--- Comment #2 from Peter Damianov ---
Andrew is correct that I reduced it too much, and replacing the attempt at
providing deque with #include does diagnose it.
But the original source I reduced it out of doesn't diagnose at any
optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512
Bug ID: 119512
Summary: -Wuninitialized does not diagnose use of uninitialized
member in constructor initialization list
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119321
Bug ID: 119321
Summary: Jump threading causing false positive warnings with
integer ranges
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042
--- Comment #9 from Peter Damianov ---
Unfortunately my patch causes ICEs in functions that optimize separate sin+cos
calls to sincos/cexpi, for reasons I'm not completely sure of.
Like the following:
typedef struct { float x,y; } Vector2;
//
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042
--- Comment #8 from Peter Damianov ---
Patch sent:
https://inbox.sourceware.org/gcc-patches/20250218005001.2266781-1-peter0...@disroot.org/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #9 from Peter Damianov ---
build this testcase with:
$ x86_64-w64-mingw32-g++ simplecpp.cpp clangimport.cpp -flto -Os
and observe an ICE
build with:
$ x86_64-w64-mingw32-g++ simplecpp.cpp clangimport.cpp -flto -Os
-fno-declone-ctor-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #8 from Peter Damianov ---
Created attachment 60518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60518&action=edit
reduced testcase reproducing the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118375
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #10 from Peter Damianov ---
Currently binutils does not install windres into the "tooldir" where gcc
typically seems to be searching, which is likely why the behavior Pali was
observing was happening.
in binutils/Makefile.in simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118602
--- Comment #5 from Peter Damianov ---
I meant to say:
1011
is -65 in the previous comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118602
--- Comment #4 from Peter Damianov ---
>From what I can tell this applies to all integers:
bool f (int c)
{
return (0xc000 & c) == 0x8000;
}
has the same transformation applied
What clang does is valid because the function is chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118602
--- Comment #3 from Peter Damianov ---
Clang is also able to figure it out for:
bool test(char c)
{
return ((0xe0 & c) == 0x80);
}
And signed or unsigned doesn't make a difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118602
Bug ID: 118602
Summary: Missed optimization for (0xc0 & c) == 0x80
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118572
--- Comment #4 from Peter Damianov ---
It gets optimized correctly with `-funsigned-char`, so I think this is
something signedness related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118572
Bug ID: 118572
Summary: wrong code for expression ((0x80 & c) != 0) && ((0xc0
& c&) == 0x80))
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342
--- Comment #5 from Peter Damianov ---
This still happens on current gcc 15 trunk.
This also applies in to instances like:
```
struct s {};
void f (s) {}
void foo() {
f(2.0f);
};
```
Which results in:
: In function 'void foo()':
:5:7: err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #6 from Peter Damianov ---
Another testcase:
not an ICE, but I think rejects-valid
```
typedef void f(struct s1);
struct s1 {
int f1;
};
typedef void f(struct s1);
```
:5:14: error: conflicting types for 'f'; have 'void(struct s1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116377
--- Comment #2 from Peter Damianov ---
I know the testcase contains infinite recursion, what I was reporting was the
warning about the strncpy repeating multiple times, with progressively more
"inlined from" notes.
I couldn't find a way to cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116377
Bug ID: 116377
Summary: Warnings emit repeatedly when inlining occurs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102061
--- Comment #6 from Peter Damianov ---
I confirmed this is the case. Compiling the example from the testcase
independent-cloneids-1.c confirms that lhd_decl_printable_name is also used for
-fdump-rtl-final, my patch results in:
;; Function bar (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102061
--- Comment #5 from Peter Damianov ---
I finally got some time to look at the test failures this patch causes.
https://gcc.gnu.org/cgit/gcc/tree/gcc/testsuite/gcc.dg/independent-cloneids-1.c
Perhaps decl_printable_name is also used when writing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102061
--- Comment #3 from Peter Damianov ---
diff --git a/gcc/langhooks.cc b/gcc/langhooks.cc
index 61f2b676256..89a89b74535 100644
--- a/gcc/langhooks.cc
+++ b/gcc/langhooks.cc
@@ -223,6 +223,8 @@ lhd_get_alias_set (tree ARG_UNUSED (t))
const char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #8 from Peter Damianov ---
The suggested fix works for g++, but not clang++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #5 from Peter Damianov ---
I checked clang's behavior, and it does CRLF -> LF from non-comments, but it
leaves them intact in comments. I'm not really sure if this behavior is worth
emulating or not. I think it would be better to remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #4 from Peter Damianov ---
All of the non-commments are turned to LF line endings.
So it must be something specifically to do with comment processing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #3 from Peter Damianov ---
Looking in a hex editor, what gcc is doing is changing the CRLF to LFLF, there
is no CR in the output.
/* If the file is using old-school Mac line endings (\r only),
terminate with another \r, not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190
--- Comment #8 from Peter Damianov ---
I have been totally unable to reproduce this outside of MSYS2, with any
compilers I built myself. The "MSYS2 MSYS" shell also doesn't have this
problem.
I can't explain why. I tried investigating, but didn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
--- Comment #10 from Peter Damianov ---
https://sourceware.org/bugzilla/show_bug.cgi?id=31761
Bug report for binutils here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
Peter Damianov changed:
What|Removed |Added
Assignee|peter0x44 at disroot dot org |unassigned at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
--- Comment #8 from Peter Damianov ---
This might arguably actually be a BFD linker problem. Both lld and mold don't
have the problem for the example. Gold also has the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
--- Comment #6 from Peter Damianov ---
Unfortuantely, this patch fails to bootstrap on linaro CI, but it bootstraps
fine on my machine. All my attempts to reproduce this failed, and I am really
not sure what to do from here.
https://patchwork.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
Peter Damianov changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
--- Comment #5 from Peter Damianov ---
I submitted a patch for this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651340.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951
Bug ID: 114951
Summary: Incorrect documentation link emitted for warning
options ending in =
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #13 from peter0x44 at disroot dot org ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648427.html
Patch submitted. Couldn't figure out how to assign myself in bugzilla.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #12 from peter0x44 at disroot dot org ---
diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 5186d040ce0..7119157d830 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -2024,9 +2024,7 @@ cont:
trunca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #11 from peter0x44 at disroot dot org ---
.I did some digging into why lto-wrapper.cc is emitting these commands
It seems that they are not essential.
/* If we are not preserving the ltrans input files then
truncate them as soon a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Bug ID: 114353
Summary: ICE when passing LTO object files compiled for
x86_64-pc-linux-gnu to x86_64-w64-mingw32-gcc
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #10 from peter0x44 at disroot dot org ---
> For a workaround, I would recommend busybox-w32. It's what w64devkit uses.
> You can just put it on your PATH and see if it solves that issue.
Just to be completely explicit, what I mean t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #9 from peter0x44 at disroot dot org ---
That sent twice... sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #8 from peter0x44 at disroot dot org ---
The way make works is it prefers using an sh.exe if it finds it on the PATH.
https://git.savannah.gnu.org/cgit/make.git/tree/src/variable.c#n1637
(see variable.c of GNU make)
Otherwise, cmd.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44854
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #37 from peter0x44 at disroot dot org ---
Sorry, comment got sent by accident, before I was done typing.
And you replied before I finished, too.
Thanks for pointing me in the correct direction.
===
IRRELEVANT
Executables with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
58 matches
Mail list logo
