https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179
--- Comment #3 from Paul Robinson
---
(In reply to Andrew Pinski from comment #2)
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576#c10 gives an example of
> how to use the new feature which was added for GCC 14.
Thanks!
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paul_robinson at playstation dot sony.com
Target Milestone: ---
Is there a way to capture a method address in inline asm that works in
-fPIC mode? Specifically I want to capture the address of a static
method that&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
Paul Robinson changed:
What|Removed |Added
CC||paul_robinson at playstation
dot s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761
--- Comment #7 from Paul Robinson
---
Okay. I'm persuaded this is not a great idea, and I'll solve the customer's
problem another way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761
--- Comment #5 from Paul Robinson
---
Modifying the syntax of the attribute won't help users who are importing
code from a third party, but still want to do dead-stripping/deduplication.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761
Paul Robinson changed:
What|Removed |Added
CC||paul_robinson at playstation
dot s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #5 from Paul Robinson
---
(In reply to David Blaikie from comment #4)
> What I'm saying is consumers already have to parse it to match up the same
> type name between compilers.
Consumers of objects produced by gcc or unmodified cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #3 from Paul Robinson
---
Admittedly the function parameter analogy is a bit of a stretch.
Making consumers parse names on the off chance they contain semantically
significant information seems like a bit much, though. Especially i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #1 from Paul Robinson
---
David and I have differing opinions on this one, but he was kind enough
to cc me on the bug so I'll offer up my take on it.
It's inarguable that omitting information makes the information smaller.
The quest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852
--- Comment #10 from Paul Robinson
---
I thought I had heard your name before! Howdy...
Granted this is an obscure corner case, but they are legal filenames,
using a leading # is less horrifying than a leading space, and the
depfile that gcc p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852
--- Comment #8 from Paul Robinson
---
(In reply to Andrew Pinski from comment #7)
> Hmm, I thought \ would be converted into / by the time we reach here for
> windows. I wonder if that is the better fix.
Admittedly the gcc I have on Windows is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852
--- Comment #6 from Paul Robinson
---
(In reply to Andrew Pinski from comment #4)
> Really for portability using \ and/or # should be avoided.
I accept that, however we do have Windows clients trying to use Make,
so \ is a fact of life.
These a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852
--- Comment #5 from Paul Robinson
---
Compare how space and # are handled, to see the problem.
They need to be handled the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852
Paul Robinson changed:
What|Removed |Added
Version|unknown |4.8.2
--- Comment #1 from Paul Robinson
Assignee: unassigned at gcc dot gnu.org
Reporter: paul_robinson at playstation dot sony.com
When gcc creates a depfile, and a target or dependency has a space or # in it,
the filespec in the depfile is escaped with a backslash so GNU Make won't
interpret it as a delimit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65820
Paul Robinson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: paul_robinson at playstation dot sony.com
gcc should escape backslashes when writing a .d file, because that's
what GNU make expects.
(Yes, I know special characters in filenames are a bad idea...)
There are various scenarios, thi
17 matches
Mail list logo
