ideas on PR/109279

[Vineet Gupta]

Hi Jeff, Kito,

I need some ideas to proceed with PR/109279: pertaining to longer term 
direction and short term fix.


First the executive summary:

long long f(void)
{
  return 0x0101010101010101ull;
}

Up until gcc 12 this used to generate const pool type access.

    lui    a5,%hi(.LANCHOR0)
    ld    a0,%lo(.LANCHOR0)(a5)
    ret
.LC0:
    .dword    0x101010101010101

After commit 2e886eef7f2b ("RISC-V: Produce better code with complex 
constants [PR95632] [PR106602] ") it gets synthesized to following


li    a0,0x0101
    addi    a0,0x0101
    slli    a0,a0,16
    addi    a0,a0,0x0101
    slli    a0,a0,16
    addi    a0,a0,0x0101
    ret

Granted const pool could or not be preferred by  specific uarch, will 
the long term approach be to have a cost model for the const pool vs. 
synthesizing.


The second aspect is to improve the horror above. Per chat on IRC, 
pinskia suggested we relax the in_splitter constraint in 
riscv_move_integer, as the combine issue holding it back is now fixed - 
after commit 61bee6aed26eb30.


That beings it down to some what reasonable

    li    a5,0x0101
    addi   a5,a5,0x0101
    mv a0,a5
    slli  a5,a5,32
    add    a0,a5,a0
    ret

I can spin a minimal patch, will that be acceptable for gcc 13.1 if it 
is testsuite clean !


Thx,
-Vineet

Re: [GSOC] query about C++: Implement compiler built-in traits for the standard library traits

[Martin Jambor]

Hello,

my apologies for a very late reply, unfortunately we have had an
unpleasant hiccup in our internal miscommunication.

On Thu, Mar 23 2023, Anastasia3412 wrote:
> Thanks, Martin and Jonathan for your suggestion. I have already finished 
> building gcc from source. I was looking at other project ideas and found 
> "Enable incremental Link Time Optimization (LTO) linking" interesting. Can 
> anyone please explain how to proceed further with this? Currently, I am 
> watching videos posted in the getting started section.
>
> --- Original Message ---
> On Wednesday, March 22nd, 2023 at 5:04 AM, Jonathan Wakely 
>  wrote:
>
>
>> On Tue, 21 Mar 2023 at 21:16, Martin Jambor wrote:
>> 
>> > Hello Anastasia,
>> > 
>> > we are very happy that you are considering contributing to GCC.
>> > 
>> > On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
>> > 
>> > > Hello Everyone I'm Anastasia.
>> > > 
>> > > I am a prospective GSOC Student. I wish to know if the project C++:
>> > > Implement compiler built-in traits for the standard library traits is
>> > > still available. I have already build and got my hand dirty on
>> > > debugging GCC.
>> > 
>> > Various prospective contributors have shown interest in it but we have
>> > not "promised" it to anyone, I don't think we can, so it is "available."
>> > It has been discussed for example here:
>> > https://gcc.gnu.org/pipermail/gcc/2023-February/240816.html
>
>> We already have two candidates working on it, before their proposal
>> has even been accepted. As a result, I think you'd have to be a very
>> strong candidate to get accepted for that project, and it might be
>> better to pick another one.

after talking to Honza I unfortunately became aware that that project
also already has a student who has also advanced quite far.

At the moment I can only suggest to look at the project proposal to
"Bypass assembler when generating LTO object files," because even though
a few people were interested in it, nobody had applied for it yet and as
far as I know nobody has even really attempted a serious proposal.  The
task is discussed here:

https://gcc.gnu.org/pipermail/gcc/2023-March/240833.html

I know that our late reply made writing a proposal difficult.  But in
order to succeed, it should be enough to show that you have basic
understanding of what needs to be done at the technical level and have
basic understanding of the source code you would need to touch (lto
streaming code and simple-object.c in libiberty).  This project also
would require rather little understanding of compiler theory because it
is mostly about shoveling around data in more efficient form but it
requires some knowledge of the ELF format.

Apologies again for the delay, please feel free to ask any specific
question about the code here or on our IRC channel.

Martin

Re: GSoC Separate Host Process Offloading

[Prasad, Adi via Gcc]

Hi Thomas,

Thanks for the info - I’ve read through the page on “Offloading” and looked at 
some code and have successfully built and tested GCC from source. I’ll also 
watch the videos on LTO on the Getting Started page, as offloading seems to be 
quite intertwined with LTO.

Before I start writing the proposal, I came up with a rough list of TODOs that 
I wanted to run by you (not necessarily in this order; I will order things in a 
way that makes it easiest to test):

  1.  Add an —enable-offload-targets option for a separate host process
  2.  Rework lto-wrapper so that if the separate host process target is 
enabled, it finds and calls a mkoffload for the host architecture instead of 
looking for an offloading compiler’s mkoffload; then write a mkoffload tool for 
a separate host process.
  3.  Write a libgomp plugin for separate host processes
  4.  Document changes, certify Developer Certificate of Origin, produce a 
ChangeLog etc according to 
https://gcc.gnu.org/wiki/GettingStarted#Tutorials.2C_HOWTOs and 
https://gcc.gnu.org/contribute.html#patches
  5.  Submit to the mailing list and respond to any requests for changes
  6.  Commit! :)

One thing I was wondering that I may be missing - the offloading docs state 
that the patch for adding the Intel MIC target have a “runtime offloading 
library” called Intel MIC. I haven’t been able to figure out the purpose of 
this (my best guess is it’s used to implement the libgomp plugin?), and whether 
it’s Intel-specific or needed for multiple targets.

Finally, I was wondering if, having built and tested GCC, there are now any 
patches, tests, or docs that I can work on?


Thanks so much for the help!

Adi


From: Thomas Schwinge 
Sent: Wednesday, March 29, 2023 9:39:02 PM
To: Prasad, Adi 
Cc: gcc@gcc.gnu.org ; Tobias Burnus 
Subject: Re: GSoC Separate Host Process Offloading


***
This email originates from outside Imperial. Do not click on links and 
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list 
https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for 
this address.
***
Hi Adi!

On 2023-03-28T20:39:04+, "Prasad, Adi via Gcc"  wrote:
> I’m Adi Prasad, a 2nd year Computing student at Imperial College London, 
> interested in doing the Separate Host Process Offloading GSoC project this 
> summer.

Greak, and welcome to GCC!  :-)

> First off, I’m aware I’m getting in touch very late; I have been busy up 
> until now with a university project deadline. I am however determined to work 
> as hard as I need to this week to catch up for my late start; I hope you are 
> still willing to consider me.

No worries, you're to too late; no decisions have been made, yet.

> I was wondering if the devs had any recommendations for starter issues to 
> work on (or simpler tasks like tests and documentation) that would help me 
> familiarise myself with the relevant code?

Building GCC and producing test results would be one obvious first task.
 and
 have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

Then, get familiar with the basic concepts of code offloading in GCC.
 is the best (only?) we have,
unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c' (The
'GOMP_OFFLOAD_[...]' functions implement the offloading plugin API), and
actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
the API you need to care about (for OpenACC; but OpenMP 'target' also
won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

> Thank you for reading this, and I will stay in touch as I develop my proposal!

Yes, please do.  In particular, think about a timeline for your proposal.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: GSoC Separate Host Process Offloading

[Tobias Burnus]

Hi Adi,

On 31.03.23 14:35, Prasad, Adi wrote:

Rework lto-wrapper so that if the separate host process target is
enabled, it finds and calls a mkoffload for the host architecture
instead of looking for an offloading compiler’s mkoffload; then write
a mkoffload tool for a separate host process.


Note that multiple offload targets are possible. For instance, on
Debian/Ubuntu, 'gcc -v' shows:
'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper then
cycles through those, finding the offloading compiler in
$PATH/accel//mkoffload

Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload

Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
some special handling in gcc.cc to avoid host-process offloading by
default and permit something like -foffload=host instead of having to
specify -foffload=x86_64-none-linux-gnu

(For those flags, see
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload )

(* it is automatically when adding it to --enable-offload-targets=...
when configuring the non-offloading compiler.)


3. Write a libgomp plugin for separate host processes
4. Document changes, certify Developer Certificate of Origin, produce
a ChangeLog etc according
tohttps://gcc.gnu.org/wiki/GettingStarted#Tutorials.2C_HOWTOsandhttps://gcc.gnu.org/contribute.html#patches

I think it would be useful to start posting patches early – such that
they can be reviewed and discussed. Thus, this is not really the 4th and
5th item.

5. Submit to the mailing list and respond to any requests for changes

* * *


One thing I was wondering that I may be missing - the offloading docs
state that the patch for adding the Intel MIC target have a “runtime
offloading library” called Intel MIC. I haven’t been able to figure
out the purpose of this (my best guess is it’s used to implement the
libgomp plugin?), and whether it’s Intel-specific or needed for
multiple targets.


There used to be Intel MIC support – which effectively only used a
simulator, similar to what this project is about, but this time it is
supposed to be generic and not as narrowly focused as the Intel MIC
stub/simulator/target support.

(Intel MIC support was removed.)


Finally, I was wondering if, having built and tested GCC, there are
now any patches, tests, or docs that I can work on?


For offloading tests, see libgomp/testsuite/ for OpenMP and OpenACC -
albeit for OpenMP, only those tests with 'omp target' actually use
offloading, which can be hostfall back.

They can be run as "make check-target-libgomp" (in the build dir) or by
"cd x86_64-none-linux-gnu/libgomp; make check" – and specific tests can
be run by setting, e.g., RUNTESTFLAGS="fortran.exp" or
RUNTESTFLAGS="c.exp=target-11.c" or ...

No quick idea for work items – maybe I get one – or Thomas does :-)

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: ideas on PR/109279

[Jeff Law via Gcc]

On 3/31/23 03:11, Vineet Gupta wrote:

Hi Jeff, Kito,

I need some ideas to proceed with PR/109279: pertaining to longer term 
direction and short term fix.


First the executive summary:

long long f(void)
{
   return 0x0101010101010101ull;
}

Up until gcc 12 this used to generate const pool type access.

     lui    a5,%hi(.LANCHOR0)
     ld    a0,%lo(.LANCHOR0)(a5)
     ret
.LC0:
     .dword    0x101010101010101

After commit 2e886eef7f2b ("RISC-V: Produce better code with complex 
constants [PR95632] [PR106602] ") it gets synthesized to following


li    a0,0x0101
     addi    a0,0x0101
     slli    a0,a0,16
     addi    a0,a0,0x0101
     slli    a0,a0,16
     addi    a0,a0,0x0101
     ret

Granted const pool could or not be preferred by  specific uarch, will 
the long term approach be to have a cost model for the const pool vs. 
synthesizing.


The second aspect is to improve the horror above. Per chat on IRC, 
pinskia suggested we relax the in_splitter constraint in 
riscv_move_integer, as the combine issue holding it back is now fixed - 
after commit 61bee6aed26eb30.


That beings it down to some what reasonable

     li    a5,0x0101
     addi   a5,a5,0x0101
     mv a0,a5
     slli  a5,a5,32
     add    a0,a5,a0
     ret

I can spin a minimal patch, will that be acceptable for gcc 13.1 if it 
is testsuite clean 

It would seem to be a gcc-14 thing to me.

It seems like we probably should adjust the basic constant synthesis 
code to handle this class of cases so that the initial RTL is good 
rather than waiting on combine to fix it up.  It looks like we need the 
destination register as well as a temporary and a 5 instruction sequence.


I'm aware of uarch plans that would handle this kind of sequence 
entirely in the front-end and pass off a single uop to the execution 
units.  We'd planned to dig into constant synthesis in support of that 
effort.  So I'm happy to help shepherd this improvement once gcc-14 
development opens.


jeff

Re: ideas on PR/109279

[Kito Cheng via Gcc]

I would prefer defer to GCC 14 too

Jeff Law 於 2023年3月31日 週五，21:34寫道：

>
>
> On 3/31/23 03:11, Vineet Gupta wrote:
> > Hi Jeff, Kito,
> >
> > I need some ideas to proceed with PR/109279: pertaining to longer term
> > direction and short term fix.
> >
> > First the executive summary:
> >
> > long long f(void)
> > {
> >return 0x0101010101010101ull;
> > }
> >
> > Up until gcc 12 this used to generate const pool type access.
> >
> >  luia5,%hi(.LANCHOR0)
> >  lda0,%lo(.LANCHOR0)(a5)
> >  ret
> > .LC0:
> >  .dword0x101010101010101
> >
> > After commit 2e886eef7f2b ("RISC-V: Produce better code with complex
> > constants [PR95632] [PR106602] ") it gets synthesized to following
> >
> > lia0,0x0101
> >  addia0,0x0101
> >  sllia0,a0,16
> >  addia0,a0,0x0101
> >  sllia0,a0,16
> >  addia0,a0,0x0101
> >  ret
> >
> > Granted const pool could or not be preferred by  specific uarch, will
> > the long term approach be to have a cost model for the const pool vs.
> > synthesizing.
> >
> > The second aspect is to improve the horror above. Per chat on IRC,
> > pinskia suggested we relax the in_splitter constraint in
> > riscv_move_integer, as the combine issue holding it back is now fixed -
> > after commit 61bee6aed26eb30.
> >
> > That beings it down to some what reasonable
> >
> >  lia5,0x0101
> >  addi   a5,a5,0x0101
> >  mv a0,a5
> >  slli  a5,a5,32
> >  adda0,a5,a0
> >  ret
> >
> > I can spin a minimal patch, will that be acceptable for gcc 13.1 if it
> > is testsuite clean
> It would seem to be a gcc-14 thing to me.
>
> It seems like we probably should adjust the basic constant synthesis
> code to handle this class of cases so that the initial RTL is good
> rather than waiting on combine to fix it up.  It looks like we need the
> destination register as well as a temporary and a 5 instruction sequence.
>
> I'm aware of uarch plans that would handle this kind of sequence
> entirely in the front-end and pass off a single uop to the execution
> units.  We'd planned to dig into constant synthesis in support of that
> effort.  So I'm happy to help shepherd this improvement once gcc-14
> development opens.
>
> jeff
>

gcc-11-20230331 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230331 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230331/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision da73bd8fa056eb8ad34d302eebbb86c3a3f0556a

You'll find:

 gcc-11-20230331.tar.xz   Complete GCC

  SHA256=4099cc729d7a9a849cc40d72c60426a4c946fb918c8dbd07b6e37a77ccb893f5
  SHA1=91931debb7b6fae05090a936ec6860fa50e53619

Diffs from 11-20230324 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[GSoC][analyzer-c++] Enable enough C++ support for self-analysis

[Benjamin Priour via Gcc]

Hi David,


On Thu, Mar 30, 2023 at 2:04 AM David Malcolm  wrote:

> Note that the analyzer doesn't properly work yet on C++; see:
>   https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110
> I'm hoping to address much of this in GCC 14.
>
> Other notes inline below...
>
> I'm guessing that the CFG and thus the supergraph contains edges for
> handling exceptions, and the analyzer currently doesn't know anything
> about these, and mishandled them:
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111
>
> You might want to have a look at the supergraph (via -fdump-analyzer-
> supergraph); I recently added more debugging notes here:
>  https://gcc.gnu.org/onlinedocs/gccint/Debugging-the-Analyzer.html
>
> If that's the case, then -fno-exceptions might affect the behavior.
>
> Thanks for the additional debugging tips!

> >
> >
> > Another observation was in the distinction between delete and free in
> > the
> > case of mixing them.
> > With 'a' being allocated with malloc:
> > > A* a = (A*) malloc(sizeof(A));
> > > free(a);
> > > delete a; // -Wanalyzer-use-after-free, OK, might expect warning
> > > for
> > double free though ?
> >
> > but with allocation through new and inversion of free/delete
> > > A* a = new A();
> > > delete a;
> > > free(a); // No diagnostics at all from the analyzer, got
> > -Wmismatched-new-delete from the front-end though.
> >
> > I believe this might come from a similar issue as above, but I still
> > have
> > to investigate on that front.
> >
> > I just noticed another unexpected behavior. Let's consider
> > > struct A {int x; int y;};
> > > void* foo() { A* a = (A*) __builtin_malloc(sizeof(A)); return a; }
> > > int main() {
> > > A* a2 = (A*) __builtin_malloc(sizeof(A));
> > > foo();
> > > return 0;
> > > }
> >
> > Then a -Wanalyzer-malloc-leak is correctly ensued for allocation in
> > foo(),
> > but none is emitted for the leak in main(), although I checked the
> > exploded
> > graph it is correctly marked as unchecked(free).
> >
> > Should I file those on bugzilla ?
>
>


> We already know that "C++ doesn't work yet".  Minimal examples of
> problems with C++ support might be worth filing, to isolate specific
> issues.  If you do, please add them to the tracker bug (by adding
> "analyzer-c++" to the "Blocks" field of the new bug(s))
>
> Sure will be doing that.


> >
> >
> > Also I have taken interest in PR106388 - Support for use-after-move
> > in
> > -fanalyzer -.
> > The prerequisite PR106386 - Reuse libstdc++ assertions - would also
> > be of
> > great help in extending the support of -Wanalyzer-out-of-bounds,
> > as we could detect out-of-bounds on vectors through
> > __glibcxx_requires_subscript used in the definition of operator[].
>
> There's a bunch of other C++-enablement work (as per the tracker bug
> above) that I think would need fixing before PR106388 is reasonable to
> tackle.
>

Indeed a bunch of them, the ramification of solving that PR got me too
excited.


> >
> > I already thought about a few ideas to implement that, but I'll
> > develop
> > them more and try to come up with some proof of concept before
> > sending them
> > to you.
> > Hopefully by tomorrow I'll update on this, I'll preferably hop to bed
> > now
> > haha.
> > Do you think this could make a suitable GSoC subject ?
>
> I think working on the C++ enablement prerequisites in the analyzer
> would make more sense.  I'd planned to do this myself for GCC 14, but
> there are plenty of other tasks I could work on if you want to tackle
> C++ support as a GSoC project for GCC 14.
>

Yes, I gladly would.


> A good C++ project might be: enable enough C++ support in the analyzer
> for it to be able to analyze itself.  This could be quite a large,
> difficult project, though it sidesteps having to support exception-
> handling, since we build ourselves with exception-handling disabled.
>
> Hope this is helpful
> Dave
>
>
To that purpose,  the following order of resolutions would make sense into
achieving that:
0. An emphasis on reducing the amount of exploded nodes will have to be put
from the beginning. All of my C++ samples produce graphs quite dense.
1. First thing first, extending the current C tests to cover C++ PR96395

(1.bis )
2. I would then go with supporting the options relative to sm-malloc:
  - -Wanalyser-double-free should behave properly (cf the fresh PR109365
 )
  - Add proper support of the non-throwing new operators. At the moment,
any new operators are supposed non-throwing (on_allocator_call, param
returns_nonnull is implicitly set to false). Actually handling this would
result in less false positive of -Wanalyzer-possible-null-dereference I
observed by tweaking it to true. Indeed currently every throwing new
operators get this warning. This would fit the bill of PR94355
 and maybe the new
placement sizes could be ha

RE: GSoC Separate Host Process Offloading

[Prasad, Adi via Gcc]

Hi Tobias,
Thanks for the reply!

> 
> Note that multiple offload targets are possible. For instance, on
> Debian/Ubuntu, 'gcc -v' shows:
> 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper then
> cycles through those, finding the offloading compiler in
> $PATH/accel//mkoffload
> 
> Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
> 
> Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
> OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
> some special handling in gcc.cc to avoid host-process offloading by
> default and permit something like -foffload=host instead of having to
> specify -foffload=x86_64-none-linux-gnu
> 
Understood. Forgive me if I'm misunderstanding this, but I wonder if it might 
be better to put the new mkoffload in an "accel/host" directory, and add "host" 
to OFFLOAD_TARGET_NAMES rather than have the specific host e.g. 
"x86_64-none-linux-gnu"? This would 1) enable the use of "-foffload=host" 
automatically and 2) distinguish between compiling for the same device on a 
separate process versus compiling to a separate device with the same 
architecture and kernel as the host. I can imagine this clash wouldn’t happen 
in practice, since compiling for a separate host process would target CPUs 
while compiling for a separate device would target GPUs, but it might be nicer 
to keep them conceptually separate all the same.

> I think it would be useful to start posting patches early – such that
> they can be reviewed and discussed. Thus, this is not really the 4th and
> 5th item.
>
I can post patches every week instead since my proposal will set a milestone 
target for each week.
Additionally, what do you think about me doing some other small tasks besides 
the proposed scope? What I was thinking about specifically was that it might be 
helpful to get the offloading documentation page up to date and add info on 
OpenACC.

> No quick idea for work items – maybe I get one – or Thomas does :-)
> 
> Tobias
> 
Thank you so much for all the info, and do let me know if any small tasks come 
up!
Adi

RE: GSoC Separate Host Process Offloading

[Prasad, Adi via Gcc]

Hi Tobias and Thomas,
My apologies for the double email; I have an unrelated administrative ask. 
Would it be possible to provide any past successful GSoC proposals? I'm 
interested in any thnigs GCC specifically is looking for in proposals (I've 
seen quite a few generic guides on the web but none specific to GCC).

Thanks,
Adi

> -Original Message-
> From: Prasad, Adi
> Sent: Saturday, April 1, 2023 4:16 AM
> To: 'Tobias Burnus' ; Thomas Schwinge
> 
> Cc: gcc@gcc.gnu.org
> Subject: RE: GSoC Separate Host Process Offloading
> 
> Hi Tobias,
> Thanks for the reply!
> 
> >
> > Note that multiple offload targets are possible. For instance, on
> > Debian/Ubuntu, 'gcc -v' shows:
> > 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper
> then
> > cycles through those, finding the offloading compiler in
> > $PATH/accel//mkoffload
> >
> > Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
> >
> > Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
> > OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
> > some special handling in gcc.cc to avoid host-process offloading by
> > default and permit something like -foffload=host instead of having to
> > specify -foffload=x86_64-none-linux-gnu
> >
> Understood. Forgive me if I'm misunderstanding this, but I wonder if it might 
> be
> better to put the new mkoffload in an "accel/host" directory, and add "host" 
> to
> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none-
> linux-gnu"? This would 1) enable the use of "-foffload=host" automatically 
> and 2)
> distinguish between compiling for the same device on a separate process versus
> compiling to a separate device with the same architecture and kernel as the 
> host.
> I can imagine this clash wouldn’t happen in practice, since compiling for a
> separate host process would target CPUs while compiling for a separate device
> would target GPUs, but it might be nicer to keep them conceptually separate 
> all
> the same.
> 
> > I think it would be useful to start posting patches early – such that
> > they can be reviewed and discussed. Thus, this is not really the 4th
> > and 5th item.
> >
> I can post patches every week instead since my proposal will set a milestone
> target for each week.
> Additionally, what do you think about me doing some other small tasks besides
> the proposed scope? What I was thinking about specifically was that it might 
> be
> helpful to get the offloading documentation page up to date and add info on
> OpenACC.
> 
> > No quick idea for work items – maybe I get one – or Thomas does :-)
> >
> > Tobias
> >
> Thank you so much for all the info, and do let me know if any small tasks come
> up!
> Adi