https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #27 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 15 07:52:50 2019
New Revision: 268930
URL: https://gcc.gnu.org/viewcvs?rev=268930=gcc=rev
Log:
PR other/69006
PR testsuite/88920
* lib/gcc-dg.exp: If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #26 from Bill Schmidt ---
Yes, that indeed helps! With that we see it once per directory prior to
running the tests, like the other existing checks. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #25 from Jakub Jelinek ---
Created attachment 45679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45679=edit
gcc9-pr88920.patch
For that I agree it is annoying, does the following patch fix it?
There is another issue, once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #24 from Bill Schmidt ---
Why does this end up showing up after a test is run, rather than early like all
the other target-supports checks? It would be less surprising if it acted like
the others (and I would probably not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #23 from Andrew Stubbs ---
It's caused by the llvm_binutils check, which is used by pretty much every test
to determine whether to complain about blank lines in compile output, or not.
Right now the easiest way to determine if it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #22 from Bill Schmidt ---
It also seems odd to me that all the other checks happen when reading
powerpc.exp, prior to running my tests, but this one happens late:
Running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #21 from Bill Schmidt ---
Well, perhaps this is business as usual, but I'd still like to understand this
a little better.
What causes us to run the effective-target check for this thing in the first
place?
I've restricted my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #20 from Jakub Jelinek ---
Various effective targets are checked already in the initialization of various
*.exp, etc. E.g. struct-layout-1.exp checks
check_effective_target_short_enums, gomp.exp checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #19 from Bill Schmidt ---
Specifially, I asked to compile only srad-modulo.c, but I end up with a
compilation of offload_gcn7262.c in my log when I do not configure in any way
to test for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #18 from Bill Schmidt ---
(In reply to Jakub Jelinek from comment #16)
> I don't see why this should be reopened. Many of the effective target
> procedures leave some output in the log files, that is completely normal.
> Why should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #17 from Andrew Stubbs ---
If this is going to annoy a lot of people then I suppose I could add an
additional message stating that the error can safely be ignored?
Or, maybe there's a way to silence/hide the output from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #16 from Jakub Jelinek ---
I don't see why this should be reopened. Many of the effective target
procedures leave some output in the log files, that is completely normal. Why
should this one be an exception?
E.g.
spawn -ignore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Bill Schmidt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Andrew Stubbs changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Andrew Stubbs changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #12 from Andrew Stubbs ---
Author: ams
Date: Wed Jan 30 11:26:31 2019
New Revision: 268384
URL: https://gcc.gnu.org/viewcvs?rev=268384=gcc=rev
Log:
Cache effective-target llvm_binutils result.
2019-01-30 Andrew Stubbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #11 from Andrew Stubbs ---
Created attachment 45481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45481=edit
Cache test
This patch caches the result so that the (harmless) error message occurs only
once.
Is there a way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #9 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #8)
> First of all, I thought the current trunk amdgcn support is non-offloading
> only, so you could at least for now always return 0 from
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #10 from Jakub Jelinek ---
(In reply to Andrew Stubbs from comment #9)
> > Does the llvm as or ld emit blank lines even when not emitting any useful
> > diagnostics, or only if it emits some errors/warnings?
>
> Only when it emits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #8 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #6)
> Emit blanks where? On the stdout or stderr of the tool?
> If so, wouldn't it be better to fix it, wrap them with a wrapper that would
> remove that mess or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #7 from Andrew Stubbs ---
I'm not sure that an assembler or linker can be labelled "insane" for choosing
to include some blank lines amongst its diagnostics. :-)
In any case, there's no other tool available, and no time/money
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #6 from Jakub Jelinek ---
Emit blanks where? On the stdout or stderr of the tool?
If so, wouldn't it be better to fix it, wrap them with a wrapper that would
remove that mess or change to a saner assembler/linker?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Andrew Stubbs changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #5 from Andrew Stubbs ---
The llvm_binutils check is needed because those tools emit blank lines all over
the place, so we end up with hundreds of stupid failures.
I'll look into caching it though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Jakub Jelinek changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #2 from seurer at gcc dot gnu.org ---
The configure is pretty simple:
/home/seurer/gcc/gcc-test2/configure
--prefix=/home/seurer/gcc/install/gcc-test2 --enable-languages=c,fortran,c++
--with-cpu=power8 --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #1 from Jakub Jelinek ---
Have you configured gcc with --enable-offload-targets= that includes
amdgcn-unknown-amdhsa ?
29 matches
Mail list logo
