https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #32 from joseph at codesourcery dot com ---
I concur that passing CL_DRIVER instead of CL_LANG_ALL is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #31 from Martin Liška ---
(In reply to Richard Earnshaw from comment #30)
> Makes sense. I'm going to wait now until Joseph gets back and has had a
> chance to comment.
@Joseph: May I please remind you this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #30 from Richard Earnshaw ---
Makes sense. I'm going to wait now until Joseph gets back and has had a chance
to comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #29 from Jakub Jelinek ---
CL_DRIVER should be covering all languages too, after all, if it is not, then
the gcc.c CL_DRIVER option processing would complain on options for specific
languages.
So I'd expect both CL_LANG_ALL in lto-wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #28 from Richard Earnshaw ---
Not sure. I presumed the LANG_ALL was about handing all language-specific
options, rather than say, just fortran as would be done if gcc were invoked as
g95.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #26 from Richard Earnshaw ---
On the basis that COLLECT_GCC_OPTIONS are the options to add if reinvoking gcc,
then that environment variable is really a set of driver options. As such, I
suspect the right fix for this is to add CL_DR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #25 from Richard Earnshaw ---
Created attachment 46608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46608&action=edit
possible patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #24 from Richard Earnshaw ---
It would appear that the handling of -MMD is the same on both Arm and X86 - in
both cases it swallows the subsequent -MF option when digested by lto-wrapper.
I'm not sure yet why the two compilers then d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #22 from Andreas Schwab ---
-MMD doesn't take an argument as a driver option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #21 from Richard Earnshaw ---
FWIW in the environment:
COLLECT_GCC_OPTIONS = '-B' '.' '-v' '-flto' '-MMD' '-MF' ''
'-mcpu=cortex-a72' '-mfloat-abi=hard' '-mtls-dialect=gnu' '-marm'
'-march=armv8-a+crc+simd'
So is this correct, o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #20 from Richard Earnshaw ---
Running under gdb I see:
(gdb)
decode_cmdline_option (argv=0x15170c, lang_mask=4095, decoded=0x1506e8)
at /home/rearnsha/gnusrc/gcc/gcc-9.1.0/gcc/opts-common.c:523
...
gdb) p *option
$5 = {opt_text =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #19 from Jakub Jelinek ---
So the first interesting difference appears in the options lto-wrapper.c
(run_gcc) emits it seems to me (based on -xlto being the very first option).
So I'd do a debugging session of lto-wrapper in both cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #18 from Martin Liška ---
Created attachment 46607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46607&action=edit
Debugging patch
Using the patch, I see the following difference:
https://www.diffchecker.com/J7lpu1Kv
But to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #17 from Jakub Jelinek ---
No idea, that has to be debugged.
But I'd suggest in the two spots that cl_driver_no_arg is tested to add
debugging printout of what the next argv is and whether CL_DRIVER is in
lang_mask or not, and run it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #16 from Andreas Schwab ---
Then why does it only happen on arm? All the LTO option handling should be
target independent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #15 from Jakub Jelinek ---
My bet is that this has something to do with the -MMD option, which is one of
the 4? NoDriverArg options, where supposedly the user when using that option
doesn't supply the argument but the specs add it. P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #13 from Martin Liška ---
(In reply to Richard Earnshaw from comment #10)
Thank you Richard for help.
> I'm not particularly familiar with how LTO is supposed to work. I can
> reproduce the crash on ARM as Martin described (but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #12 from Richard Earnshaw ---
How do I invoke lto-wrapper inside gdb? it seems to pick up some magic options
via the environment...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #11 from Richard Earnshaw ---
Some pass in the compilation process must create that temporary file with the
options to gcc; but whichever pass this is doesn't appear in the output of "gcc
-v"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #10 from Richard Earnshaw ---
I'm not particularly familiar with how LTO is supposed to work. I can
reproduce the crash on ARM as Martin described (but not on AArch64). The
problem seems to be an assert that the number of files to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #8 from Martin Liška ---
It's not related to .d FE as it fails also with a different file name:
$ echo "int main() {}" > main.c && gcc -c -flto main.c && gcc -o a.out main.o
-flto -MMD -MF deps
gcc: error: deps: No such file or direc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #7 from Martin Liška ---
Ok, we have a -dumpspecs option. If I use it for x86_64 and aarch64 I get a
small difference that should be fine:
--- x86_64.spec 2019-07-16 16:48:03.923522778 +0200
+++ aarch64.spec2019-07-16 16:47:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #6 from Martin Liška ---
(In reply to Andreas Schwab from comment #5)
> Why does it clash only on arm and aarch64?
I'll debug that, it's really strange.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Andreas Schwab changed:
What|Removed |Added
Target|aarch64-linux-gnu |aarch64-*-* arm*-*-*
Host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #1 from Martin Liška ---
It's interesting that:
echo "int main() {}" > main.c && gcc -c -flto main.c && gcc main.o -flto -MF
deps/a.d -MMD
is fine. I really suspect:
$ cat ./gcc/d/lang-specs.h
...
{".d", "@d", 0, 1, 0 },
{".dd", "@d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Martin Liška changed:
What|Removed |Added
Target||aarch64-linux-gnu
Last reconfirmed|
34 matches
Mail list logo
