RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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 message could then be something
like "Please submit the preprocessed file at /home/foo/bar/baz.i".

As gcc usually does not invoke cpp directly any more (correct?) it
might be possible to dump the source code, if it is still held
in memory, or alternatively invoke the preprocessor on the
original source file.

This has the potential of getting more reasonable bug reports
into bugzilla, I think.

What do you think?  Good/bad idea? Should I open a PR for this?
Should this kind of thing maybe be restricted to checking mode?

Best regards

Thomas

Re: RFC: Leave preprocessed files on ICE

[Jakub Jelinek via Gcc]

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 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".
> 
> As gcc usually does not invoke cpp directly any more (correct?) it
> might be possible to dump the source code, if it is still held
> in memory, or alternatively invoke the preprocessor on the
> original source file.
> 
> This has the potential of getting more reasonable bug reports
> into bugzilla, I think.
> 
> What do you think?  Good/bad idea? Should I open a PR for this?
> Should this kind of thing maybe be restricted to checking mode?

You mean what the -freport-bug option does?

Jakub

Re: RFC: Leave preprocessed files on ICE

[Andreas Schwab via Gcc]

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, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Link-time resolved constant

[The Cuthour via Gcc]

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?

Re: RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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, the driver actually tests it multiple times whether the ICE
is reproduceable and it isn't just some hw misbehavior.


Thanks for the explanation.  I think it might be good to add a bit
of this to the docs. I will prepare a patch.

Best regards

Thomas

Re: RFC: Leave preprocessed files on ICE

[Jakub Jelinek via Gcc]

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 error message could then be something
> > > like "Please submit the preprocessed file at /home/foo/bar/baz.i".
> 
> > You mean what the -freport-bug option does?
> 
> I had actually looked at that before I sent my e-mail. The most recent
> docs say
> 
> # Collect and dump debug information into a temporary file if an
> # internal compiler error (ICE) occurs.
> 
> which sounds like something different; I would not have thought
> that "debug information" refers to preprocessed source.

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, the driver actually tests it multiple times whether the ICE
is reproduceable and it isn't just some hw misbehavior.

Jakub

Re: RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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

Re: RFC: Leave preprocessed files on ICE

[Jakub Jelinek via Gcc]

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://gcc.gnu.org/bugs/ does
> not mention -freport-bug.

But the compiler does in every ICE message in which -freport-bug isn't
enabled.

...
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

and with additional -freport-bug

...
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccv0AONd.out file, please attach this to 
your bugreport.

Jakub

Re: RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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 at /home/foo/bar/baz.i".



You mean what the -freport-bug option does?


I had actually looked at that before I sent my e-mail. The most recent
docs say

# Collect and dump debug information into a temporary file if an
# internal compiler error (ICE) occurs.

which sounds like something different; I would not have thought
that "debug information" refers to preprocessed source.

Best regards

Thomas

Re: Link-time resolved constant

[Trampas Stern via Gcc]

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 destruction.

Therefore create a new file format for the elf and call it elf2 or any name
you want, then let the results be so good that no one can ignore them.  Do
not ask permission from the old way as it will resist change.  Fork and
move forward, when done let the results and quality speak for themself.

Dennis Ritchie built C not Ada++.  Basically tore down the past and
recreated a better future.  He did it so well that no one could ignore his
results.  By the growth of new languages like Rust and Zig, it is appearing
that C will be around forever, but needs a replacement.  If
elf format needs a replacement as well, then so be it.  Just do not expect
rapid adoption until there is monetary value in doing so.  For example,
even with Zig and Rust, C will be around for decades to come in the
embedded world because the old programmers know C.  As such the old elf
files and old ways of doing things will be around for a long time.

The change from the old ways will happen only when the new ways are more
profitable and/or easier for the guy doing the work.





On Tue, Jan 7, 2025 at 11:36 AM The Cuthour via Gcc  wrote:

> 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?
>

Re: RFC: Leave preprocessed files on ICE

[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.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: RFC: Leave preprocessed files on ICE

[Jakub Jelinek via Gcc]

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 ICE message does.
> > 
> 
> Hm, OK.
> 
> Question: Would it make sense to enable -freport-bug by default on
> non-release builds?  I would see no real harm in doing so, because
> additional files are only generated when an ICE occurs.

Some distros enable it by default in their packages.
On the other side, I think one doesn't want to enable it in development
builds for usual testing, you don't want to have all ICEs take 3 times as
long to compile and dump garbage into /tmp all the time.
You want to enable it only if you use such built compiler for testing other
stuff later.

Jakub

Re: RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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
non-release builds?  I would see no real harm in doing so, because
additional files are only generated when an ICE occurs.

Best regards

Thomas

Re: RFC: Leave preprocessed files on ICE

[Thomas Koenig via Gcc]

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, slightliy modifying it so the preprocessor
is actually invoked, one gets:

$ cat z1.F90
#define N 1

program p
   type t
  character :: a
  integer :: b
  integer :: c(t(N))
   end type
   type(t) :: z = t('a', 2, [3])
end
$ gfortran -freport-bug -c z1.F90
z1.F90:9:28:

9 |type(t) :: z = t('a', 2, [3])
  |1
Error: Bad array spec of component 'c' referenced in structure 
constructor at (1)

f951: internal compiler error: Segmentation fault
0x276239f internal_error(char const*, ...)
../../trunk/gcc/diagnostic-global-context.cc:517
0x11f33b6 crash_signal
../../trunk/gcc/toplev.cc:322
[...]
0xaec6d8 gfc_parse_file()
../../trunk/gcc/fortran/parse.cc:7368
0xb48d0f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.cc:241
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

That's the bug, presumably.  I've filed PR 118336 for this.
(And mentioning -freport-bug in the docs is PR 104254, but
it is better to leave that as is because gfortran's
error message points there).

Best regards

Thomas

Re: Link-time resolved constant

[The Cuthour via Gcc]

Thank you.

My plan is to make a higher compatibility version of ELF.
You may be able to call it ELF2.0

RFC: Link-time resolved constant

[The Cuthour via Gcc]

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?

Re: Alignment of `complex double`

[Florian Weimer via Gcc]

* 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 this is.
>
>
> Because it's roughly equivalent to:
>
> double arr[2];
>
> This also has size 16 and alignment 8.

Well, the story is a bit more complicated.  Array variables that are at
least 16 bytes large have 16 byte alignment.  This rule does not apply
to struct members.

The x86-64 ABI currently does not specify alignment for _Complex or
_Atomic types.

Thanks,
Florian