Hello world,
when an ICE occurs somewhere when building a complex software package,
it can be cumbersome for the user to obtain the preprocessed file
that we ask people to submit to us.
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error me
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> when an ICE occurs somewhere when building a complex software package,
> it can be cumbersome for the user to obtain the preprocessed file
> that we ask people to submit to us.
>
> Would it be reasonable to dump a preprocesse
On Jan 07 2025, Thomas Koenig via Gcc wrote:
> Would it be reasonable to dump a preprocessed file (if any) on an ICE,
> and point the user to it? The error message could then be something
> like "Please submit the preprocessed file at /home/foo/bar/baz.i".
Like -freport-bug?
--
Andreas Schwab,
Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html
I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?
Am 07.01.25 um 16:14 schrieb Jakub Jelinek via Gcc:
It is "debug information" in the sense that it is everything needed
to debug the ICE.
Which isn't just preprocessed source, but also used compiler options,
and details on how the compiler has been configured and what ICE has been
emitted. Plus,
On Tue, Jan 07, 2025 at 04:04:22PM +0100, Thomas Koenig wrote:
> Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
> > On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> > > Would it be reasonable to dump a preprocessed file (if any) on an ICE,
> > > and point the user to it? The e
Am 07.01.25 um 16:41 schrieb Thomas Koenig via Gcc:
Thanks for the explanation. I think it might be good to add a bit
of this to the docs. I will prepare a patch.
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
Best regards
Thomas
On Tue, Jan 07, 2025 at 05:46:48PM +0100, Thomas Koenig via Gcc wrote:
> Am 07.01.25 um 16:41 schrieb Thomas Koenig via Gcc:
> > Thanks for the explanation. I think it might be good to add a bit
> > of this to the docs. I will prepare a patch.
>
> Side remark (which I will also address): https://
Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error message could then be something
like "Please submit the preprocessed file
I am a newbie, but if you want my opinion you are welcome to it.
My thoughts are that for growth to happen you often need creative
destruction. That is to destroy or tear down the old ways and create
something better. In that respect the old way of doing things will never
agree to self destructi
On Jan 07 2025, Thomas Koenig via Gcc wrote:
> Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
> not mention -freport-bug.
But the ICE message does.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now
On Tue, Jan 07, 2025 at 07:19:34PM +0100, Thomas Koenig via Gcc wrote:
> Am 07.01.25 um 18:04 schrieb Andreas Schwab:
> > On Jan 07 2025, Thomas Koenig via Gcc wrote:
> >
> > > Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
> > > not mention -freport-bug.
> >
> > But the
Am 07.01.25 um 18:04 schrieb Andreas Schwab:
On Jan 07 2025, Thomas Koenig via Gcc wrote:
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
But the ICE message does.
Hm, OK.
Question: Would it make sense to enable -freport-bug by default on
Am 07.01.25 um 17:52 schrieb Jakub Jelinek via Gcc:
But the compiler does in every ICE message in which -freport-bug isn't
enabled.
It seems that -freport-bug does nothing for Fortran, or at least the
Fortran front end (which why it was unfamiliar to me). Grabbing a
random ICE off bugzilla, sli
Thank you.
My plan is to make a higher compatibility version of ELF.
You may be able to call it ELF2.0
Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html
I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?
* Jonathan Wakely via Gcc:
> On Tue, 7 Jan 2025, 03:09 M Chhapgar via Gcc, wrote:
>
>> Hello,
>>
>> I am learning about memory alignment and noticed that on my x86-64 machine
>> with GCC 14, a `complex double` has a size of 16 bytes, but an alignment of
>> only 8 bytes. I am curious as to why thi
17 matches
Mail list logo
