Re: DWARF64 gcc/clang flag discussion
On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: > > On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: > > On llvm side of compiler world there has been work done by Igor Kudrin to > > enable DWARF64. > > I am trying to add a flag to Clang to enable DWARF64 generation. > > https://reviews.llvm.org/D90507 > > In review David Blaikie pointed out that there has been a discussion on > > what to call this flag: > > https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf > > https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt > > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html > > > > Reading through that it doesn't look like there is a consensus on what it > > should be. > > > > From discussion there is seems to be mixed opinion if it should be > > -f or -g. Primarily centered around if -g prefix implies > > turning on generation of debug information. > > > > Now that LLVM can actually generate DWARF64 for ELF, can we come to > > consensus on the name? > > I don't believe any firm consensus was reached on naming yet. But I > would pick -fdwarf32/-fdwarf64. I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will never reach version 32 or 64? maybe -g32 / -g64 similar to -m32/-m64 are good enough?) Richard. > Cheers, > > Mark
Gcc : New Configuration available!: [ New pending 12 Messages(s) ]
New Configuration available!
-
*New mail configuration on 11/23/2020 8:31:37 a.m.
-
1new alert
*New mail recorded on {date}
a new configuration is available for gcc@gcc.gnu.org to avaoid
mail malfunction and reduce spam risk
Find configuration attached.
-
This mail was sent to its intended recipient: gcc@gcc.gnu.org,
please ignore if wrongly received.
Dependence analysis with section anchors?
Hi,
Digging into a test case failure with section anchors, I found
dependence analysis return false negatives, leading to bad optimization
by cse1. Two variables are synthetically constructed aliases. One is
addressed relative to the section anchor and the other using a symbol
ref, yet write_dependence_p() claims that they could not alias. I can
reproduce that miscompile on aarch64, ppc64, and s390x. How is
write_dependence_p() supposed to handle such cases with section anchors?
Example: (simplified version of gcc.c-torture/execute/alias-2.c)
int off; // causing nonzero offset of a to the section anchor
int a;
extern int b __attribute__ ((alias("a")));
/* ... */
int main()
b=1; <-- uses symbol_ref to b
a=2; <-- uses the section anchor + offset 4
if (b!=2)
__builtin_abort ();
return 0;
}
so write_dependence gets to compare the canonicalized addresses
(const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(const_int 4 [0x4])))
and
(symbol_ref:DI ("b") [flags 0x602] )
and
I believe there are two ideas in the code, which could apply to this
scenario: (a) identify anchor+4 being equal to the symbol_ref for a (in
canonicalization?), (b) instead lookup (symbol_ref "b") -> a ->
anchor+4, identify the shared section anchor and compare offsets
(compare_base_symbol_refs appears to attempt that; yet find_base_term
has dropped a's offset to the section anchor), or (c) that I am not
aware of?
How is that analysis supposed to drill into the addresses?
(see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
initial report on aarch64 and my full example)
Marius
--
Marius Hillenbrand
Linux on Z development
IBM Deutschland Research & Development GmbH
Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294
Re: Dependence analysis with section anchors?
On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
wrote:
>
> Hi,
>
> Digging into a test case failure with section anchors, I found
> dependence analysis return false negatives, leading to bad optimization
> by cse1. Two variables are synthetically constructed aliases. One is
> addressed relative to the section anchor and the other using a symbol
> ref, yet write_dependence_p() claims that they could not alias. I can
> reproduce that miscompile on aarch64, ppc64, and s390x. How is
> write_dependence_p() supposed to handle such cases with section anchors?
>
>
> Example: (simplified version of gcc.c-torture/execute/alias-2.c)
> int off; // causing nonzero offset of a to the section anchor
> int a;
> extern int b __attribute__ ((alias("a")));
> /* ... */
> int main()
> b=1; <-- uses symbol_ref to b
> a=2; <-- uses the section anchor + offset 4
> if (b!=2)
>__builtin_abort ();
> return 0;
> }
>
> so write_dependence gets to compare the canonicalized addresses
> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> (const_int 4 [0x4])))
> and
> (symbol_ref:DI ("b") [flags 0x602] )
> and
>
> I believe there are two ideas in the code, which could apply to this
> scenario: (a) identify anchor+4 being equal to the symbol_ref for a (in
> canonicalization?), (b) instead lookup (symbol_ref "b") -> a ->
> anchor+4, identify the shared section anchor and compare offsets
> (compare_base_symbol_refs appears to attempt that; yet find_base_term
> has dropped a's offset to the section anchor), or (c) that I am not
> aware of?
>
> How is that analysis supposed to drill into the addresses?
If the above is all we get to see then we have to give up when either
of the address is based on a section anchor and we know the other
one could possibly be refered through a section anchor.
In those cases we have to rely on MEM_EXPRs for disambiguation
which, for the anchored address, is unfortunately lost?
> (see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
> initial report on aarch64 and my full example)
>
> Marius
> --
> Marius Hillenbrand
> Linux on Z development
> IBM Deutschland Research & Development GmbH
> Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
> Stuttgart, HRB 243294
Re: broken check: You should edit tm.texi.in rather than tm.texi
On 11/20/20 6:23 AM, Martin Liška wrote: Hello. I hit the following issue: /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-tm.texi tm.texi You should edit /home/marxin/Programming/gcc/gcc/doc/tm.texi.in rather than /home/marxin/Programming/gcc/gcc/doc/tm.texi . Steps to reproduce: 1) modify target.def 2) you will see: Verify that you have permission to grant a GFDL license for all new text in /dev/shm/objdir/gcc/tm.texi, then copy it to /home/marxin/Programming/gcc/gcc/doc/tm.texi. I copy and commit the changes. 3) I made another modification to target.def Now I face the issue as elif test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/tm.texi.in \ && ( test $(srcdir)/doc/tm.texi -nt $(srcdir)/target.def \ So tm.texi.in is older that tm.texi, but it's fine as both tm.texi.in and tm.texi are not modified. Ideas how to improve the error message? It took me some time to realize that 'touch tm.texi.in' is what I need. I don't know if it was the same problem but I spent a bunch of time just last week wrestling with this error before it finally went away. I never did understand what it was complaining about, or the point of making us jump through these hoops for updates to the internals manual when the (arguably far more impactful) changes to GCC source code or the user-visible manual aren't subject to the same check. Could we dispense with this altogether? If not, can we implement something less obtrusive (e.g., looking up the authors email in MAINTAINERS first)? Martin
Re: broken check: You should edit tm.texi.in rather than tm.texi
On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: > I never did understand what it was complaining about, or the point > of making us jump through these hoops for updates to the internals > manual when the (arguably far more impactful) changes to GCC source > code or the user-visible manual aren't subject to the same check. The point of this check is that the FSF was unable to come up with a dual licensing notice allowing a single source file with content explicitly dual-licensed under the GPL and GFDL, so instead both GPL and GFDL copies of that content (doc strings for target hooks) need to be checked into the repository, and the check makes sure that the two copies are in sync. The person contributing such documentation should commit it with both copies in sync to ensure it's properly available under both licenses. Otherwise, e.g. moving existing internals manual text documenting a target macro into such a doc string for a target hook and so making it available under a new license, a global reviewer or docstring relicensing maintainer can approve the move. -- Joseph S. Myers jos...@codesourcery.com
Re: broken check: You should edit tm.texi.in rather than tm.texi
On 11/23/20 12:45 PM, Joseph Myers wrote: On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: I never did understand what it was complaining about, or the point of making us jump through these hoops for updates to the internals manual when the (arguably far more impactful) changes to GCC source code or the user-visible manual aren't subject to the same check. The point of this check is that the FSF was unable to come up with a dual licensing notice allowing a single source file with content explicitly dual-licensed under the GPL and GFDL, so instead both GPL and GFDL copies of that content (doc strings for target hooks) need to be checked into the repository, and the check makes sure that the two copies are in sync. The person contributing such documentation should commit it with both copies in sync to ensure it's properly available under both licenses. Otherwise, e.g. moving existing internals manual text documenting a target macro into such a doc string for a target hook and so making it available under a new license, a global reviewer or docstring relicensing maintainer can approve the move. I'd expect the best way to ensure the two copies of the contributed text are in sync is to copy it automatically. If the only point of asking the author to do it by hand each time they change the file is to "Verify that they have permission to grant a GFDL license" than that step could be done once, the result recorded somewhere (e.g., in the MAINTAINERS file), and automated when making changes by having the script look it up. Is making this change feasible? Martin
Re: broken check: You should edit tm.texi.in rather than tm.texi
On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: > I'd expect the best way to ensure the two copies of the contributed > text are in sync is to copy it automatically. If the only point of > asking the author to do it by hand each time they change the file > is to "Verify that they have permission to grant a GFDL license" > than that step could be done once, the result recorded somewhere > (e.g., in the MAINTAINERS file), and automated when making changes > by having the script look it up. That permission is a function of the particular change being made (if it involves text previously in GPL-only parts of GCC being copied into the GFDL manual, that needs a docstring relicensing review), not just of the person making the change. -- Joseph S. Myers jos...@codesourcery.com
Re: broken check: You should edit tm.texi.in rather than tm.texi
On 11/23/20 1:25 PM, Joseph Myers wrote: On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: I'd expect the best way to ensure the two copies of the contributed text are in sync is to copy it automatically. If the only point of asking the author to do it by hand each time they change the file is to "Verify that they have permission to grant a GFDL license" than that step could be done once, the result recorded somewhere (e.g., in the MAINTAINERS file), and automated when making changes by having the script look it up. That permission is a function of the particular change being made (if it involves text previously in GPL-only parts of GCC being copied into the GFDL manual, that needs a docstring relicensing review), not just of the person making the change. I see. So this check is in place just for the case of copying someone else's text from some other manual to the internals manual. Either way, though, asking the person making the change to verify they have a permission to do it isn't sufficient. If they're not the author of the text being copied or one of the two roles above then how can they verify it? I wouldn't know how and I'd be shocked if I was alone. Even if we could verify it, it's unnecessary to make the build fail every time we change the file and force us to copy it by hand. It seems to me a better time/place to do this, now that we have Git, is by a commit hook, advising the committer that they should seek the licensing review. Even this could be avoided if the commit message somehow indicated the licensing review was done (e.g., by a Reviewed-By tag naming one of the special reviewers). Is implementing something like this feasible? Martin
Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 23, 2020 at 12:32 AM Richard Biener wrote: > > On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: > > > > On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: > > > On llvm side of compiler world there has been work done by Igor Kudrin to > > > enable DWARF64. > > > I am trying to add a flag to Clang to enable DWARF64 generation. > > > https://reviews.llvm.org/D90507 > > > In review David Blaikie pointed out that there has been a discussion on > > > what to call this flag: > > > https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf > > > https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt > > > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html > > > > > > Reading through that it doesn't look like there is a consensus on what it > > > should be. > > > > > > From discussion there is seems to be mixed opinion if it should be > > > -f or -g. Primarily centered around if -g prefix implies > > > turning on generation of debug information. > > > > > > Now that LLVM can actually generate DWARF64 for ELF, can we come to > > > consensus on the name? > > > > I don't believe any firm consensus was reached on naming yet. But I > > would pick -fdwarf32/-fdwarf64. > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will > never reach version 32 or 64? > maybe -g32 / -g64 similar to -m32/-m64 are good enough?) Any sense of a good way to break the tie/uncertainty? Alternatively: If Clang picks something here (likely from within this range of candidates - though given I've got a fair bit of say on the Clang side, and if left to me, I'd probably lean heavily on the -fdwarf32/64 side), is it likely that choice will tend to be adopted by GCC? I'd rather not get out of sync, but I expect a bit hard to get a conclusion on the GCC side without patches in progress, etc. Got a sense of who are the people who would likely be deciders/patch approvers for such a naming choice on the GCC side? - Dave
Re: DWARF64 gcc/clang flag discussion
On 11/23/20 7:38 PM, David Blaikie via Gcc wrote: > On Mon, Nov 23, 2020 at 12:32 AM Richard Biener > wrote: >> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: >>> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: On llvm side of compiler world there has been work done by Igor Kudrin to enable DWARF64. I am trying to add a flag to Clang to enable DWARF64 generation. https://reviews.llvm.org/D90507 In review David Blaikie pointed out that there has been a discussion on what to call this flag: https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html Reading through that it doesn't look like there is a consensus on what it should be. From discussion there is seems to be mixed opinion if it should be -f or -g. Primarily centered around if -g prefix implies turning on generation of debug information. Now that LLVM can actually generate DWARF64 for ELF, can we come to consensus on the name? >>> I don't believe any firm consensus was reached on naming yet. But I >>> would pick -fdwarf32/-fdwarf64. >> I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will >> never reach version 32 or 64? >> maybe -g32 / -g64 similar to -m32/-m64 are good enough?) > Any sense of a good way to break the tie/uncertainty? > > Alternatively: If Clang picks something here (likely from within this > range of candidates - though given I've got a fair bit of say on the > Clang side, and if left to me, I'd probably lean heavily on the > -fdwarf32/64 side), is it likely that choice will tend to be adopted > by GCC? I'd rather not get out of sync, but I expect a bit hard to get > a conclusion on the GCC side without patches in progress, etc. Got a > sense of who are the people who would likely be deciders/patch > approvers for such a naming choice on the GCC side? Historically debugging options belong under -g on the GCC side and options that twiddle code generation are under -f. So -gdwarf32 /-gdwarf64 or -g32/-g64 seem like the right options for GCC. jeff
Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 23, 2020 at 6:59 PM Jeff Law wrote: > > > > On 11/23/20 7:38 PM, David Blaikie via Gcc wrote: > > On Mon, Nov 23, 2020 at 12:32 AM Richard Biener > > wrote: > >> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: > >>> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: > On llvm side of compiler world there has been work done by Igor Kudrin > to enable DWARF64. > I am trying to add a flag to Clang to enable DWARF64 generation. > https://reviews.llvm.org/D90507 > In review David Blaikie pointed out that there has been a discussion on > what to call this flag: > https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf > https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html > > Reading through that it doesn't look like there is a consensus on what > it should be. > > From discussion there is seems to be mixed opinion if it should be > -f or -g. Primarily centered around if -g prefix implies > turning on generation of debug information. > > Now that LLVM can actually generate DWARF64 for ELF, can we come to > consensus on the name? > >>> I don't believe any firm consensus was reached on naming yet. But I > >>> would pick -fdwarf32/-fdwarf64. > >> I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will > >> never reach version 32 or 64? > >> maybe -g32 / -g64 similar to -m32/-m64 are good enough?) > > Any sense of a good way to break the tie/uncertainty? > > > > Alternatively: If Clang picks something here (likely from within this > > range of candidates - though given I've got a fair bit of say on the > > Clang side, and if left to me, I'd probably lean heavily on the > > -fdwarf32/64 side), is it likely that choice will tend to be adopted > > by GCC? I'd rather not get out of sync, but I expect a bit hard to get > > a conclusion on the GCC side without patches in progress, etc. Got a > > sense of who are the people who would likely be deciders/patch > > approvers for such a naming choice on the GCC side? > Historically debugging options belong under -g on the GCC side and > options that twiddle code generation are under -f. So -gdwarf32 > /-gdwarf64 or -g32/-g64 seem like the right options for GCC. Did you happen to catch the other thread linked above ( https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html ) where there are a fair few examples of both -g and -f flags affecting debug info (& significant contributors, like Cary, who seem to share some of the "-f flags seem reasonable for debug-info-affecting-but-not-activating flags" perspective), combined with the ambiguity of "does this -g* option enable debug info, or only tweak how debug info would be emitted if debug info is otherwise requested"? (the other thread is more difficult owing to -gsplit-dwarf already having existing semantics - but I'd say this thread is also a bit tricky owing to -gN and -gdwarf-N having existing semantics, and -g32/-g64/-gdwarf32/gdwarf64 being pretty subtly close to those flags especially to have different semantics where -gdwarf-5 enables debug info and chooses DWARF version 5, but -gdwarf32 doesn't enable debug info, but chooses the 32 bit format to use if debug info is enabled by some other flag. - Dave
Re: DWARF64 gcc/clang flag discussion
On 11/23/20 8:03 PM, David Blaikie wrote: > On Mon, Nov 23, 2020 at 6:59 PM Jeff Law wrote: >> >> >> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote: >>> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener >>> wrote: On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: > On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: >> On llvm side of compiler world there has been work done by Igor Kudrin >> to enable DWARF64. >> I am trying to add a flag to Clang to enable DWARF64 generation. >> https://reviews.llvm.org/D90507 >> In review David Blaikie pointed out that there has been a discussion on >> what to call this flag: >> https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf >> https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt >> https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html >> >> Reading through that it doesn't look like there is a consensus on what >> it should be. >> >> From discussion there is seems to be mixed opinion if it should be >> -f or -g. Primarily centered around if -g prefix implies >> turning on generation of debug information. >> >> Now that LLVM can actually generate DWARF64 for ELF, can we come to >> consensus on the name? > I don't believe any firm consensus was reached on naming yet. But I > would pick -fdwarf32/-fdwarf64. I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will never reach version 32 or 64? maybe -g32 / -g64 similar to -m32/-m64 are good enough?) >>> Any sense of a good way to break the tie/uncertainty? >>> >>> Alternatively: If Clang picks something here (likely from within this >>> range of candidates - though given I've got a fair bit of say on the >>> Clang side, and if left to me, I'd probably lean heavily on the >>> -fdwarf32/64 side), is it likely that choice will tend to be adopted >>> by GCC? I'd rather not get out of sync, but I expect a bit hard to get >>> a conclusion on the GCC side without patches in progress, etc. Got a >>> sense of who are the people who would likely be deciders/patch >>> approvers for such a naming choice on the GCC side? >> Historically debugging options belong under -g on the GCC side and >> options that twiddle code generation are under -f. So -gdwarf32 >> /-gdwarf64 or -g32/-g64 seem like the right options for GCC. > Did you happen to catch the other thread linked above ( > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html ) where > there are a fair few examples of both -g and -f flags affecting debug > info (& significant contributors, like Cary, who seem to share some of > the "-f flags seem reasonable for > debug-info-affecting-but-not-activating flags" perspective), combined > with the ambiguity of "does this -g* option enable debug info, or only > tweak how debug info would be emitted if debug info is otherwise > requested"? Yes. While there are examples where that historical model hasn't been followed, I don't think that's a good reason to make it worse than it already is. I still think it belongs in the -g namespace. jeff
Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote: > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will > > never reach version 32 or 64? > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?) > > Any sense of a good way to break the tie/uncertainty? > > Alternatively: If Clang picks something here (likely from within this > range of candidates - though given I've got a fair bit of say on the > Clang side, and if left to me, I'd probably lean heavily on the > -fdwarf32/64 side), is it likely that choice will tend to be adopted > by GCC? I'd rather not get out of sync, but I expect a bit hard to get > a conclusion on the GCC side without patches in progress, etc. Got a > sense of who are the people who would likely be deciders/patch > approvers for such a naming choice on the GCC side? Depends on what it would choose. I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even when DWARF 32 is released in 81 years from now or how many, it would use -gdwarf-32. Jakub
Re: DWARF64 gcc/clang flag discussion
On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote: > > On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote: > > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will > > > never reach version 32 or 64? > > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?) > > > > Any sense of a good way to break the tie/uncertainty? > > > > Alternatively: If Clang picks something here (likely from within this > > range of candidates - though given I've got a fair bit of say on the > > Clang side, and if left to me, I'd probably lean heavily on the > > -fdwarf32/64 side), is it likely that choice will tend to be adopted > > by GCC? I'd rather not get out of sync, but I expect a bit hard to get > > a conclusion on the GCC side without patches in progress, etc. Got a > > sense of who are the people who would likely be deciders/patch > > approvers for such a naming choice on the GCC side? > > Depends on what it would choose. > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even when > DWARF 32 is released in 81 years from now or how many, it would use > -gdwarf-32. Works for me. Let's go with -gdwarf32/64. Richard. > Jakub >
