Andrew Pinski via Gcc schrieb:
On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc wrote:
Hi all,
I’ve added a named address space to our backend and I noticed that it is only
support in C.
Has anyone had experience porting this feature to C++? Is there any technical
reason why it’s not su
On Fri, Jun 26, 2020 at 9:12 AM Georg-Johann Lay wrote:
>
> Andrew Pinski via Gcc schrieb:
> > On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc
> > wrote:
> >> Hi all,
> >>
> >> I’ve added a named address space to our backend and I noticed that it is
> >> only support in C.
> >> Has anyone
* Nathan Sidwell:
> On 6/25/20 2:34 PM, Joel Sherrill wrote:
>> Hi
>>
>> RTEMS supports over 15 processor architectures and we would like to ensure
>> that TLS is supported on all rather than just a handful of popular ones
>> (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document (
Hi all,
I'm trying to implement DWARF output for the AMD GCN target, and I've
run into trouble; -O0 debug works pretty well, but there are some
problems accessing variables in registers.
Problem 1
The proposed DWARF specification for the target doesn't specify separate
DWARF registers
On Jun 22, 2020, at 3:51 PM, Eric Gallager wrote:
>
> Hi, at Apple's WWDC this year they have announced that they are doing
> yet another architecture transition, so I was wondering what exactly
> would be the best way to go about adding support for it?
I usually use emacs and git to add ports t
Sent from my iPhone
Snapshot gcc-9-20200626 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200626/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote:
> > On Jun 25, 2020, at 6:37 PM, Jeff Law wrote:
> >
> > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit
> > > data-path between registers and memory;
Any idea on that? I just cannot find a way of using GIMPLE to analyze
multiple .C files. All my analysis is still start from the following
function:
virtual unsigned int execute(function *fun) override
which has no idea about the .C file information. In LLVM all .C files are
roughly maintained in
Hello,
I am writing the following statement to make a GIMPLE call:
tree function_fn_type = build_function_type_list(void_type_node,
void_type_node, integer_type_node, NULL_TREE);
tree sancov_fndecl = build_fn_decl("my_instrumentation_function",
function_fn_type);
auto gcall = gi
10 matches
Mail list logo
