This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497

--- Comment #16 from Valeriy E. Ushakov <uwe at netbsd dot org> ---
(In reply to Eric Gallager from comment #15)
> (In reply to Valeriy E. Ushakov from comment #11)
> > Created attachment 44668 [details]
> > Diff against gcc-6.4.0
> > 
> > This is essentially the same diff except gcc now provides its own
> > HOST_WIDE_INT_C() macro, so the patch uses that instead of defining its own.
> 
> can you please send it to the gcc-patches mailing list for review?

This patch has been sitting in your bugtracker for 11 years.  Anything I know
about this bug is written in this bug report and swapped out of my active
memory, so I cannot meaningfully answer any questions about that patch on
gcc-patches@ other than by referring people to what's written here in this bug
report.   Why do I have to go through this strange ritual of taking this patch
out of gcc's own bugtracker and sending it to gcc's own list for proposed
patches?  This is not some proposed change that I can meaningfully advocate
(like a new feature or something).

I.e. what that action is going to change from the standpoint of communication
setup?  As I see it, it can only make things worse b/c if I'm actually asked
any questions I can't answer them, or someone replies to that patch only to the
mailing list and I miss that reply (and it's not recorded here too).  And then
it will just look as my fault, not engaging in a proper discussion.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]