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
37 matches
Mail list logo
