On Jul 24, 2020, Thomas Schwinge wrote:
> Please merge in the attached incremental patch to resolve syntax errors.
Thanks, sorry about those. I found out about lset after I posted the
proposed patch, and I switched to it over set from [lreplace] to avoid
further embarrassing myself ;-) That was
On Jul 24, 2020, Thomas Schwinge wrote:
> we also need to move the '-dump*' arguments later in one place, so that
> they'll override those that appear via the loop over 'argv', which also
> contains '-dump*' arguments. With that changed, it appears to work fine.
Aah, thanks. Here's the combine
Hi!
On 2020-06-30T18:35:36+0200, I wrote:
> On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/lib/scanoffload.exp
>
>> +# Utility for scanning offloading dump output, used by libgomp.exp.
>
> ;-) Yeah, I was about to say that having this file in
> 'gcc/te
On Thu, 23 Jul 2020, Alexandre Oliva wrote:
> The testglue object file gets interpreted as another input file,
> changing the dump and aux output names in GCC unless it is protected
> by -Wl, like board file-named extra inputs.
>
> Refactor the code that modifies the board settings so that it can
Hi Alexandre!
On 2020-07-14T02:46:32-0300, Alexandre Oliva wrote:
> On Jun 30, 2020, Thomas Schwinge wrote:
>> See 'gcc/config/i386/intelmic-mkoffload.c'. ;-)
>> Can you easily adjust that file as you did for the GCN and nvptx
>> 'mkoffload's? Due to other workload, resolving it myself would
Hi Alexandre!
On 2020-07-14T01:48:41-0300, Alexandre Oliva wrote:
> Sorry it took me so long to get back to you.
Well, likewise. :-|
> On Jun 30, 2020, Thomas Schwinge wrote:
>
>> For example, if there are two 'offload_targets' configured, and you do a:
>
>> PASS: libgomp.c++/scan-offloa
The testglue object file gets interpreted as another input file,
changing the dump and aux output names in GCC unless it is protected
by -Wl, like board file-named extra inputs.
Refactor the code that modifies the board settings so that it can be
used to modify regular variables as well, and do so
FWIW, I spotted two bugs in the completely untested patch by running it
through the compiler. s/dmp_filename/dump_filename/g will fix it.
--
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU T
On Jun 30, 2020, Thomas Schwinge wrote:
>>> I looked for a mkoffload
>>> program for it in the GCC source tree and couldn't find one.
> See 'gcc/config/i386/intelmic-mkoffload.c'. ;-)
Thanks!
> :-) Yes, I quickly tested, and found that similar changes are required
> there, too.
> Can you eas
Hello, Thomas,
Sorry it took me so long to get back to you.
Thanks for the patches you posted a couple of weeks ago, I'm merging
them into my aux-dump-revamp branch, where I'm accumulating the patches
related with this change.
On Jun 30, 2020, Thomas Schwinge wrote:
> For example, if there ar
Hi Alexandre!
On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
> Here's a consolidated patch, [...]
Another small issue here:
> --- /dev/null
> +++ b/gcc/testsuite/lib/scanoffload.exp
> +# Utility for scanning offloading dump output, used by libgomp.exp.
> +
> +# Format an offload dump suff
Hi!
On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
> Here's a consolidated patch, [...]
Again, many thanks for working through this, with Tobias' help.
> --- /dev/null
> +++ b/gcc/testsuite/lib/scanoffload.exp
> +# Utility for scanning offloading dump output, used by libgomp.exp.
;-) Yea
Hi!
On 2020-06-18T14:06:10+0200, Tobias Burnus wrote:
> On 6/18/20 12:39 PM, Alexandre Oliva wrote:
>>> and intelmic.
>> How does intelmic get into the picture?
>
> No idea – I just know that it counts as offloading platform,
> ENABLE_OFFLOAD is set for it (but not for has).
> I just wanted to me
Hi!
Many thanks, Alexandra and Tobias for working this out together!
On 2020-06-23T06:50:26-0300, Alexandre Oliva wrote:
> On Jun 9, 2020, Thomas Schwinge wrote:
>
>> Previously, for '-foffload=nvptx-none -foffload=-fdump-rtl-mach
>> -save-temps -o ./nvptx-merged-loop.exe', GCC produced the e
Hi,
On Tue, Jun 23 2020, Alexandre Oliva wrote:
> Hello, Thomas,
>
> On Jun 9, 2020, Thomas Schwinge wrote:
>
>> We're trying to scan 'variables.hsail.brig.*', but for input file name
>> 'variables.hsail.brig', we're now creating:
>
> I understand this was fixed by Martin Jambor's last week's pa
On Jun 9, 2020, Thomas Schwinge wrote:
> Previously, for '-foffload=nvptx-none -foffload=-fdump-rtl-mach
> -save-temps -o ./nvptx-merged-loop.exe', GCC produced the expected
> 'nvptx-merged-loop.o.307r.mach'.
I believe the patch I've just installed fixes the UNRESOLVED results
caused by not fin
Hello, Thomas,
On Jun 9, 2020, Thomas Schwinge wrote:
> We're trying to scan 'variables.hsail.brig.*', but for input file name
> 'variables.hsail.brig', we're now creating:
I understand this was fixed by Martin Jambor's last week's patch for
brig.exp; can you please confirm whether the problem
On Mon, 22 Jun 2020, Alexandre Oliva wrote:
> On Jun 22, 2020, Tobias Burnus wrote:
>
> > On 6/22/20 8:08 AM, Alexandre Oliva wrote:
> >>> I additionally did run the test case manually → files.log for the
> >>> produced files.
> >> This is with -save-temps, right?
>
> > Yes. Without, there are
On Jun 22, 2020, Tobias Burnus wrote:
> On 6/22/20 8:08 AM, Alexandre Oliva wrote:
>>> I additionally did run the test case manually → files.log for the
>>> produced files.
>> This is with -save-temps, right?
> Yes. Without, there are no files left under /tmp and only
> nvptx-merged-loop.xnvpt
On 6/22/20 8:08 AM, Alexandre Oliva wrote:
I additionally did run the test case manually → files.log for the
produced files.
This is with -save-temps, right?
Yes. Without, there are no files left under /tmp and only
nvptx-merged-loop.xnvptx-none.mkoffload.309r.mach
nvptx-merged-loop.exe
in
On Jun 19, 2020, Tobias Burnus wrote:
> Done; nvptx compiled but for AMDGCN I got a compile error:
> in one function 'argv_obstack' was lacking a 'cc_' prefix ('cc_argv_obstack'),
> see attached patch (vs. mainline, not vs. either of your patches).
Ah, I see, cut&pasto, different obstacks. Than
On 6/19/20 11:53 AM, Alexandre Oliva wrote:
Here's an incremental patch, on top of the one you kindly tested the
other day (thanks!), that attempts to introduce per-offload-target dump
name variation.
Could you possibly give it a spin with the offloading targets you've
got?
Done; nvptx compil
On Jun 18, 2020, Tobias Burnus wrote:
> Thus, without the offload_target prefix, they would dump into the same file!
Here's an incremental patch, on top of the one you kindly tested the
other day (thanks!), that attempts to introduce per-offload-target dump
name variation.
Could you possibly gi
On 6/18/20 12:39 PM, Alexandre Oliva wrote:
Thanks. I see the main problem besides the dumppfx constness is the
double dot before target, fixed in the revised patch below.
With this, I think the libgomp testsuite might work with offloading
again.
Thanks. I have only tried the first one of the
On Jun 18, 2020, Tobias Burnus wrote:
> On 6/18/20 8:10 AM, Alexandre Oliva wrote:
>> Could you possibly give this *completely* untested patch a try and let
>> me know whether it does any good?
> Otherwise, see attachment. I now added also the @/tmp file which is
> passed to mkoffload.
Thanks.
On 6/18/20 8:10 AM, Alexandre Oliva wrote:
Could you possibly give this *completely* untested patch a try and let
me know whether it does any good?
gcc/lto-wrapper.c:1473:41: error: invalid conversion from 'const char*' to
'char*' [-fpermissive]
incoming_dumppfx = dumppfx = option->arg;
On Jun 9, 2020, Thomas Schwinge wrote:
> Are you able to easily create/suggest patches for these? (You're
> probably not set up for offloading compilation...) Can you suggest
> how/where to adjust: producer-side (GCC driver, 'mkoffload's?), or
> consumer-side (testsuite: offload tree scanning
On Jun 17, 2020, Tobias Burnus wrote:
> I hope it helps.
Thanks! Not quite as much as I'd hoped, because I forgot much of the
arg passing in lto land is through @files, but I think I've got enough
to take a shot at fixing this.
Two questions that come to mind:
- do we wish to preserve the te
On 6/11/20 12:24 AM, Alexandre Oliva wrote:
Let's see how far I can get by just looking at the code ;-)
If I were to get something like a -v compile and link session, from
someone all set for offloading compilation, with the command line passed
to lto-wrapper and the full commands it runs, I mi
On Jun 11, 2020, at 7:28 AM, Martin Jambor wrote:
>
> On Tue, Jun 09 2020, Mike Stump wrote:
>> I think I'd prefer the fix on the other side, if reasonable. I'd give
>> them some time to see about a fix there before selecting this patch.
>
> given Alexandre's email, are you OK with the patch?
Hi Mike,
On Tue, Jun 09 2020, Mike Stump wrote:
> I think I'd prefer the fix on the other side, if reasonable. I'd give
> them some time to see about a fix there before selecting this patch.
given Alexandre's email, are you OK with the patch? It essentially
manually keeps the input name "rootna
On Jun 9, 2020, Thomas Schwinge wrote:
> Are you able to easily create/suggest patches for these? (You're
> probably not set up for offloading compilation...)
I can try, but I can certainly use help, if not in coding, at least with
testing.
> Can you suggest
> how/where to adjust: producer-si
I think I'd prefer the fix on the other side, if reasonable. I'd give them
some time to see about a fix there before selecting this patch.
On Jun 9, 2020, at 5:42 AM, Martin Jambor wrote:
> On Tue, Jun 09 2020, Thomas Schwinge wrote:
>> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>>> T
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For libgomp offloading testing, I'm seeing a number of failures like:
UNSUPPORTED:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop
Hi,
On Tue, Jun 09 2020, Thomas Schwinge wrote:
> Hi!
>
> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>> Thanks, here's the combined patch I'm checking in.
>>
>> revamp dump and aux output names
>
> For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
>
> Running [...]/
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
Running [...]/source-gcc/gcc/testsuite/brig.dg/dg.exp ...
PASS: brig.dg/t
On Tue, 2 Jun 2020, Alexandre Oliva wrote:
> On May 27, 2020, Alexandre Oliva wrote:
>
> > - The prepending of -Wl, to file names in ldflags et al was done in a
> > way that introduced empty arguments when consecutive blanks appeared
> > in these board configuration knobs. Skip the empty string
On May 27, 2020, Alexandre Oliva wrote:
> - The prepending of -Wl, to file names in ldflags et al was done in a
> way that introduced empty arguments when consecutive blanks appeared
> in these board configuration knobs. Skip the empty strings between
> consecutive blanks to avoid this problem.
On Wed, 2020-05-27 at 19:05 -0300, Alexandre Oliva wrote:
> outputs.exp: no lto, linker default output, cdtor temps, empty args
>
> From: Alexandre Oliva
>
> This patch fixes various issues in the testsuite that came up after
> the dump/aux output revamp, namely:
>
> - many outputs.exp tests us
outputs.exp: no lto, linker default output, cdtor temps, empty args
From: Alexandre Oliva
This patch fixes various issues in the testsuite that came up after
the dump/aux output revamp, namely:
- many outputs.exp tests used -flto without checking that LTO was
supported, getting lots of failures
On Mai 27 2020, Alexandre Oliva wrote:
> On May 27, 2020, Andreas Schwab wrote:
>
>> Looks like tcl 8.5.5 has a bug:
>
> Ugh, how unfortunate.
In fact, that bug exists in all versions.
https://core.tcl-lang.org/tcl/tktview?name=5bbd044812
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
On May 27, 2020, Andreas Schwab wrote:
> Looks like tcl 8.5.5 has a bug:
Ugh, how unfortunate.
> % glob -nocomplain -path {} -- {a.{out,exe}}
> % glob -nocomplain -path {} -- {a.{out,exe}*}
> a.out
Thanks for tracking that down, I'll put in some work around for that.
--
Alexandre Oliva, fre
Looks like tcl 8.5.5 has a bug:
% glob -nocomplain -path {} -- {a.{out,exe}}
% glob -nocomplain -path {} -- {a.{out,exe}*}
a.out
Andreas.
--
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 diffe
FAIL: outputs exe default 1: a.{out,exe}
FAIL: outputs exe default 1: extra
a.out
FAIL: outputs exe default 2: a.{out,exe}
FAIL: outputs exe default 2: extra
a.out
FAIL: outputs exe savetmp unnamed1: a.{out,exe}
FAIL: outputs exe savetmp unnamed1: extra
a.out
FAIL: outputs exe savetmp unnamed2: a.{
> From: Alexandre Oliva
> Date: Tue, 26 May 2020 15:52:57 +0200
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
> Here's a proper patch submission.
And he
On Tue, 26 May 2020, Alexandre Oliva wrote:
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
>
> Here's a proper patch submission. I'm still throwing tests
On May 26, 2020, Richard Biener wrote:
> xgcc: error: unrecognized command-line option '-dumpbase'^M
> xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
Here's a proper patch submission. I'm still throwing tests at it, but
it's already proved (with a non-bootstrapped buil
On May 26, 2020, Richard Biener wrote:
> All visible by testing on x86_64-linux.
Interesting bug. You wouldn't have hit it if you enabled Ada. That's
because I'd missed the %< directives that validate_switches mishandled
in the Ada specs, so validate_switches handled the %{d*} and validated
-d
On May 26, 2020, Richard Biener wrote:
> I'm seeing a lot of issues.
:-(
> First any LTO invocations end up with
> xgcc: error: unrecognized command-line option '-dumpbase'^M
> lto-wrapper: fatal error: /home/rguenther/obj/gcc/xgcc returned 1 exit
> status^M
> compilation terminated.^M
> xg+
On 5/26/20 10:52 AM, Richard Biener wrote:
Did you maybe install a wrong patch or miss some changes?
No, I see the same failures.
Martin
On May 21, 2020, Alexandre Oliva wrote:
> On May 19, 2020, Richard Biener wrote:
>> Thanks again for doing this. May I also suggest to prepare a short
>> entry for gcc-11/changes.html with these things (like "Output of
>> auxiliary files changed. See https://gcc.gnu.org/ml/gcc-patches/...
>>
On Thu, 21 May 2020, Alexandre Oliva wrote:
> On May 19, 2020, Richard Biener wrote:
>
> > On Tue, 19 May 2020, Alexandre Oliva wrote:
> >> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
> >> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
> >> patches on
On May 19, 2020, Richard Biener wrote:
> On Tue, 19 May 2020, Alexandre Oliva wrote:
>> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
>> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
>> patches on top of it, that I hope to get approved for folding and j
On Tue, 19 May 2020, Alexandre Oliva wrote:
> On May 19, 2020, Alexandre Oliva wrote:
>
> > - fix spurious outputs.exp test failures on targets that do not support
> > -gsplit-dwarf
>
> cope with -gsplit-dwarf errors
>
> From: Alexandre Oliva
>
> On targets that did not support -gsplit-dwa
On Tue, 19 May 2020, Alexandre Oliva wrote:
> On May 19, 2020, Alexandre Oliva wrote:
>
> > - fix a build problem when targeting platforms with an executable suffix
>
> aux and dump revamp: fix target exec suffix handling
>
> HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
On Tue, 19 May 2020, Alexandre Oliva wrote:
> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
> patches on top of it, that I hope to get approved for folding and joint
> installation:
Thanks again for doing
On May 19, 2020, Alexandre Oliva wrote:
> - fix for outputs.exp for platforms with nonempty ldflags, libs,
> ldscripts, or output_format in the dejagnu board configuration, and
> for link tests with aux dumps in the testsuite when ldflags, libs or
> ldscripts in the board config name files
On May 19, 2020, Alexandre Oliva wrote:
> - fix a build problem when targeting platforms with an executable suffix
aux and dump revamp: fix target exec suffix handling
HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
that requires testing whether it's defined, rather than fo
On May 19, 2020, Alexandre Oliva wrote:
> - fix spurious outputs.exp test failures on targets that do not support
> -gsplit-dwarf
cope with -gsplit-dwarf errors
From: Alexandre Oliva
On targets that did not support -gsplit-dwarf, we'd get tons of
spurious failures. This patch tests for sup
I've refreshed the patch, approved back on Jan 22 for gcc-11, in
refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
patches on top of it, that I hope to get approved for folding and joint
installation:
- fix a build problem when targeting platforms with an executable suffix
-
On Jan 22, 2020, Richard Biener wrote:
> I think it's fine to make that change now.
FTR, the combined patch, to be installed in GCC 11, is commit
f798a915a2a00ff7921644d0e08cb88e7db581a2, in
refs/users/aoliva/heads/aux-dump-revamp
I'm not reposting the monster patch right now.
--
Alexandre Ol
On Jan 22, 2020, Richard Biener wrote:
>> I suppose I might go ahead and install the libiberty follow-up patch
>> approved by Joseph, and squash the lto-wrapper portion into the larger
>> patch. Please let me know in case you think the libiberty change to
>> preserve empty arguments should also
On Tue, 21 Jan 2020, Alexandre Oliva wrote:
> On Jan 20, 2020, Richard Biener wrote:
>
> > On Thu, 16 Jan 2020, Alexandre Oliva wrote:
>
> >> Here it is, at last, regstrapped on x86_64-linux-gnu. Ok to install?
>
> > I'm hesitant to approve it now since we're in stage4 and been too
> > permis
On Jan 20, 2020, Richard Biener wrote:
> On Thu, 16 Jan 2020, Alexandre Oliva wrote:
>> Here it is, at last, regstrapped on x86_64-linux-gnu. Ok to install?
> I'm hesitant to approve it now since we're in stage4 and been too
> permissive already. So ...
> OK for GCC 11.
Thanks, that sounds
On Thu, 16 Jan 2020, Alexandre Oliva wrote:
> And here's a followup that fixes a limitation (bug?) in libiberty that
> was hit when I attempted a last-minute simplification in lto-wrapper.
>
> Regstrapped separately on x86_64-linux-gnu. Ok to install?
>
>
> [libiberty] output empty args as a p
On Jan 16, 2020, Alexandre Oliva wrote:
> On Jan 9, 2020, Alexandre Oliva wrote:
>> On Jan 9, 2020, Richard Biener wrote:
>>> Did I miss the actual (non-documentation) patch?
>> No, I didn't post it. It's kind of big, and only yesterday did I get it
>> to work as expected and now extensivel
On Jan 9, 2020, Richard Biener wrote:
> Did I miss the actual (non-documentation) patch?
No, I didn't post it. It's kind of big, and only yesterday did I get it
to work as expected and now extensively documented, passing all of the
extensive testsuite I wrote for it.
Alas, some of the latest
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> On Dec 25, 2019, Alexandre Oliva wrote:
>
> > 3. do not take the executable name into account when it shares the
> > basename with an input file; combine executable basename with input name
> > otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf
68 matches
Mail list logo
