Possible bug; code-block vanishes when adding one assembler-instruction.

[Jens Bauer]

I'm using a GCC toolchain similar to Yagarto for making code for the LPC1768 
microcontroller.

My gcc is version 4.7.2, my binutils is version 2.23.1

To make parts of my code run faster (a timer interrupt to be exact), I've used 
a modified linker script, so that I get a '.fastcode' section.
The linker script I copied can be found here:


My code is as follows:

.syntax unified
.section.fastcode
.global interrupt
.func   interrupt
.type   interrupt,%function
.thumb_func
interrupt:

;// str r1,[r0, #0]   /* offending line */
movwr0,#0x1234
movtr0,#0x5678
bx  lr

.pool
.endfunc
.size   interrupt, . - interrupt

.end


Now as it is there, everything's correct.

$ tail -n 6 Fastcode-test.hex
:10041C041C0420041847C04623
:10041000F8B5C046F8BC08BC9E4670475101C4
:10042000F8B5C046F8BC08BC9E4670472101E4
:0C04300041F23420C5F278607047F3   <-- This is my routine, which 
should be located in RAM
:040301D91F
:0001FF

Now, when I enable the line 'str r1,[r0, #0]', and I do a 'make clean; make', I 
get this:
$ tail -n 6 Fastcode-test.hex
:1003FDF8A642F9D170BC01BC00471C04F6
:10041C041C0420041847C04623
:10041000F8B5C046F8BC08BC9E4670475101C4
:10042000F8B5C046F8BC08BC9E4670472101E4
:040301D91F
:0001FF


This has been driving me crazy, and it took a few days to nail it down.

If I have the 'str r1,[r0, #0]' line disabled and replace the 'movw' / 'movt' 
instructions with this...
.rept 64
movtr0,#0x5678
.endr

...then I still get the code in the .hex file.

-But if I insert just one of the following lines, the function disappears from 
the .hex file:

ldr r0,=(LPC_GPIO2 + FIOPIN)
ldr r1,[r0]
str r1,[r0]

Now, one interesting thing is that the disassembly looks just fine to me, so 
does the linker map.

I'm using gcc -x assembler-with-cpp for assembling, and g++ for linking.

This could be a bug in my Makefile, my linker script, in my source file or in 
how I compiled gcc/binutils.
-But as there is a chance it could be in gcc or binutils, I'd like to ask here 
- does anyone have a clue of what's going on in this case ?

Please let me know if I need to provide more information.

(Note: This is my third time I'm trying to send this email; I had so much 
problems [on all GNU lists] with being blocked, because I had no reverse DNS.)


Love
Jens

Re: OpenACC support in 4.9

[Richard Biener]

On Mon, May 6, 2013 at 5:16 PM, Jeff Law  wrote:
> On 05/06/2013 07:41 AM, Tobias Burnus wrote:
>>
>> Evgeny Gavrin wrote:
>>>
>>> What do you think about support of OpenACC 1.0
>>> (http://www.openacc-standard.org/) in gcc?
>>
>>
>> I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
>> be the better choice as it looks a bit more flexible and better defined.
>> (Conceptually, they are very similar; I think the
>> middle-end/back-end/library part would even be the same.)
>
> We're certainly hoping that OpenACC & OpenMP 4 & Cilk+ can share certain
> parts of their implementations.  We're already seeing OpenMP 4 and Cilk
> starting to converge on some stuff.
>
> In a perfect world, there'd only be one standard for this stuff.  That's not
> likely, so I'd be happy with parsing/FE kinds of things being specific to
> each standard with everything from initial gimple generation through the
> optimizers being shared.  That may not ultimately be possible, but I think
> that's the right way to look at the work.

We're going to look at supporting HSA from GCC (which would make it
more or less trivial to also target openCL I think) and also hope to leverage
parts of the GOMP infrastructure for this (GOMP is currently the only
way to annotate parallel regions, apart from autodetecting them).  If Cilk+
and OpenACC provide additional ways of annotating parallel regions then
it would be nice to have the middle-end see only a single consistent way
of a parallel region.

Richard.

> Jeff

Re: Possible bug; code-block vanishes when adding one assembler-instruction.

[Andrew Haley]

On 05/07/2013 08:18 AM, Jens Bauer wrote:
> Please let me know if I need to provide more information.

I'm afraid you have sent this to the wrong place.  The assembler doesn't
use gcc, and this is the gcc list.  Please send it to the binutils list.

Andrew.

Re: OpenACC support in 4.9

[Evgeny Gavrin]

Hi, all!

> Which accelerators do you intent to handle? "Accelerator" is a rather
> broad term, covering DSPs, GPUs, Intel's MIC, ...
The idea is to emit OpenCL from high-GIMPLE, for know. So, any device 
that has OpenCL support can be utilized by ACC.
Maybe, we'll be able to reuse some parts from graphite/opengpu projects, 
but this is not clear for now.


> Is there a specific reason for targeting 1.0 instead of 2.0 (besides 2.0
> still being declared as a draft)?
You've named the main reason why we're targeting OpenACC1 - it's stable 
and it's a good starting point for the initial implementation. BTW, 
OpenACC2 differs not much from the previous version. Major improvements 
covers only runtime library.


> - but I don't think anyone will work on OpenMP 4.0's 'target' feature
> soon as the enough work on the non-'target' features remains.
OpenMP's 'target' is definitely inspired by OpenACC. So, I think it'll 
be possible to reuse/share most of BE part from OpenACC implementation, 
once it's finished.


> I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
> be the better choice as it looks a bit more flexible and better defined.
> (Conceptually, they are very similar; I think the
> middle-end/back-end/library part would even be the same.)
OpenMP 4.0 is still in draft. Meanwhile, OpenACC is supported by several 
commercial compilers and our implementation can be compared for achieved 
performance. In addition, there are some side projects using OpenACC and 
it'll help to test implementation on real code.


Thanks,
Evgeny.

On 05/06/2013 05:41 PM, Tobias Burnus wrote:

Evgeny Gavrin wrote:

What do you think about support of OpenACC 1.0
(http://www.openacc-standard.org/) in gcc?


I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
be the better choice as it looks a bit more flexible and better defined.
(Conceptually, they are very similar; I think the
middle-end/back-end/library part would even be the same.)

Which accelerators do you intent to handle? "Accelerator" is a rather
broad term, covering DSPs, GPUs, Intel's MIC, ...

Tobias

* http://openmp.org/wp/2013/03/openmp-40-rc2/  (GCC supports OpenMP 3.1.
Support for OpenMP 4.0 is currently implemented in GCC's gomp-4_0-branch
- but I don't think anyone will work on OpenMP 4.0's 'target' feature
soon as the enough work on the non-'target' features remains.)

PS: A nonexclusive copyright assignment to the Free Software Foundation
is required for any any nontrivial code contribution. See
http://gcc.gnu.org/contribute.html#legal  - After the copyright issues
are sorted out, you can apply for commit rights (write after approval
status), which are sufficient to create a development branch.

Re: OpenACC support in 4.9

[Tobias Burnus]

Richard Biener wrote:
We're going to look at supporting HSA from GCC (which would make it 
more or less trivial to also target openCL I think)


For the friends of link-time optimization (LTO):

Unless I missed some fine point in OpenACC and OpenMP's target, they 
only work with directives which are locally visible. Thus, if one does a 
function call in the device/target section, it can only be placed on the 
accelerator if the function can be inlined.


Thus, it would be useful, if LTO could be used to inline such function 
into device code. I know one OpenACC code which calls functions in 
different translation units (TU) - and the Cray compiler handles this 
via LTO. Thus, it would be great if the HSA/OpenMP target/OpenACC 
middle-end infrastructure could do likewise, which also means deferring 
the error that an external function cannot be used to the middle-end/LTO 
FE and not placing it into the FE. - In the mentioned code, the called 
function does not have any OpenACC annotation but only consists of 
constructs which are permitted by the accelerator - thus, no automatic 
code gen of accelerator code happens for that. TU.


(I just want to mention this to ensure that this kind of LTO/accelerator 
inlining is kept in mind when implementing the infrastructure for 
HSA/OpenACC/OpenMP target/OpenCL - even if cross-TU inlining is not 
supported initially.)


Tobias

Re: Possible bug; code-block vanishes when adding one assembler-instruction.

[Jens Bauer]

Hi Andrew.

Thank you, I will. Of course; I'm just a bit absent at the moment. ;)
In fact, I'm sure this must be a linker problem.


Love
Jens

On Tue, 07 May 2013 09:47:34 +0100, Andrew Haley wrote:
> On 05/07/2013 08:18 AM, Jens Bauer wrote:
>> Please let me know if I need to provide more information.
> 
> I'm afraid you have sent this to the wrong place.  The assembler doesn't
> use gcc, and this is the gcc list.  Please send it to the binutils list.
> 
> Andrew.
> 

Re: OpenACC support in 4.9

[Richard Biener]

On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus  wrote:
> Richard Biener wrote:
>>
>> We're going to look at supporting HSA from GCC (which would make it more
>> or less trivial to also target openCL I think)
>
>
> For the friends of link-time optimization (LTO):
>
> Unless I missed some fine point in OpenACC and OpenMP's target, they only
> work with directives which are locally visible. Thus, if one does a function
> call in the device/target section, it can only be placed on the accelerator
> if the function can be inlined.
>
> Thus, it would be useful, if LTO could be used to inline such function into
> device code. I know one OpenACC code which calls functions in different
> translation units (TU) - and the Cray compiler handles this via LTO. Thus,
> it would be great if the HSA/OpenMP target/OpenACC middle-end infrastructure
> could do likewise, which also means deferring the error that an external
> function cannot be used to the middle-end/LTO FE and not placing it into the
> FE. - In the mentioned code, the called function does not have any OpenACC
> annotation but only consists of constructs which are permitted by the
> accelerator - thus, no automatic code gen of accelerator code happens for
> that. TU.
>
> (I just want to mention this to ensure that this kind of LTO/accelerator
> inlining is kept in mind when implementing the infrastructure for
> HSA/OpenACC/OpenMP target/OpenCL - even if cross-TU inlining is not
> supported initially.)

In my view we'd get the "regular" OpenMP processing done during omp
lowering/expansion (which happens before LTO) which should mark the
generated worker functions apropriately.  Emitting accelerator code should
then happen at LTRANS time, thus after all IPA inlining took place.  The
interesting bits we can borrow from OMP is basically marking of functions
that are a) interesting, b) possible to transform.  Unmarked functions / loops
will have to go the autopar way, thus we have to prove via dependence analysis
that executing iterations in parallel is possible.

Richard.

> Tobias

Re: OpenACC support in 4.9

[Richard Biener]

On Tue, May 7, 2013 at 12:42 PM, Richard Biener
 wrote:
> On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus  wrote:
>> Richard Biener wrote:
>>>
>>> We're going to look at supporting HSA from GCC (which would make it more
>>> or less trivial to also target openCL I think)
>>
>>
>> For the friends of link-time optimization (LTO):
>>
>> Unless I missed some fine point in OpenACC and OpenMP's target, they only
>> work with directives which are locally visible. Thus, if one does a function
>> call in the device/target section, it can only be placed on the accelerator
>> if the function can be inlined.
>>
>> Thus, it would be useful, if LTO could be used to inline such function into
>> device code. I know one OpenACC code which calls functions in different
>> translation units (TU) - and the Cray compiler handles this via LTO. Thus,
>> it would be great if the HSA/OpenMP target/OpenACC middle-end infrastructure
>> could do likewise, which also means deferring the error that an external
>> function cannot be used to the middle-end/LTO FE and not placing it into the
>> FE. - In the mentioned code, the called function does not have any OpenACC
>> annotation but only consists of constructs which are permitted by the
>> accelerator - thus, no automatic code gen of accelerator code happens for
>> that. TU.
>>
>> (I just want to mention this to ensure that this kind of LTO/accelerator
>> inlining is kept in mind when implementing the infrastructure for
>> HSA/OpenACC/OpenMP target/OpenCL - even if cross-TU inlining is not
>> supported initially.)
>
> In my view we'd get the "regular" OpenMP processing done during omp
> lowering/expansion (which happens before LTO) which should mark the
> generated worker functions apropriately.  Emitting accelerator code should
> then happen at LTRANS time, thus after all IPA inlining took place.  The
> interesting bits we can borrow from OMP is basically marking of functions
> that are a) interesting, b) possible to transform.  Unmarked functions / loops
> will have to go the autopar way, thus we have to prove via dependence analysis
> that executing iterations in parallel is possible.

Btw, we plan to re-use the GOMP runtime as otherwise any synchronisation
between accelerator code and regular thread code is impossible.  Which
means changing the GOMP runtime in a way to be able to pass a descriptor
which eventually has accelerator code (and a fallback regular function so
you can disable accelerator usage at runtime).

Richard.

> Richard.
>
>> Tobias

GCC 4.8.1 Status Report (2013-05-07)

[Jakub Jelinek]

Status
==

GCC 4.8.0 has been released more than one and half months ago, and the
number of bugfixes on the branch is growing (70 fixed bugs with 4.8.1
milestone so far, including 5 P1s), and additionally the C++ frontend
reached C++11 feature completion milestone, so it is almost time to
release the GCC 4.8.1.  I'd like to release it if all goes well in
about two weeks from now, with a release candidate mid next week.
There is one P1 bug currently open (--disable-nls bootstrap issue
on MinGW, Diego, can you please look at it?) and several regressions from
4.7.x, so please try to help with bugfixing to make GCC 4.8.1 a good and
stable release.

Quality Data


Priority  #   Change from Last Report
---   ---
P11   +  1
P2   66   +  1
P3   25   + 16
---   ---
Total92   + 18


Previous Report
===

http://gcc.gnu.org/ml/gcc/2013-03/msg00179.html

The next report will be sent by me again, when announcing release
candidate.

RE: BImode and STORE_VALUE_FLAG

[Paulo Matos]

> -Original Message-
> From: Mikael Pettersson [mailto:mi...@it.uu.se]
> Sent: 04 May 2013 11:51
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: BImode and STORE_VALUE_FLAG
> 
> 
> I can't comment on the code in question, but the backend for m68k may be
> affected
> since it defines STORE_FLAG_VALUE as -1.  Do you have a testcase that would
> cause
> wrong code, or a patch to cure the issue?  I'd be happy to do some testing on
> m68k-linux.
> 
> /Mikael

Mikael,

I have looked at m68k code and it seems that the predicate (cc reg) is FPmode.
I can't see a definition of FPmode anywhere (where is it?) but I assume it's 
not a
defined as a single bit. I think we are making the mistake of using BImode for 
this 
and therefore STORE_FLAG_VALUE of -1 is invalid (or unsupported because it's 
meaningless).

So I guess the problem (which might not be a problem after all can't be 
reproduced in m68k and
it's fine. I will keep researching this issue and will get back to you if I 
find 
anything interesting. In the meantime, where is FPmode defined in m68k?

Paulo Matos

RE: BImode and STORE_VALUE_FLAG

[Paulo Matos]

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 07 May 2013 14:19
> To: Mikael Pettersson
> Cc: gcc@gcc.gnu.org
> Subject: RE: BImode and STORE_VALUE_FLAG
>
> In the meantime, where is FPmode defined in m68k?
> 
>

Got it, FP is a mode iterator defined in m68k.md. :)

Colombo & Pricelist

[Vivian Jiang]

Dear Sales, 
 
I'm interested in your products. Pls provide your best offer for the following: 
 
(1) CIF Colombo 
(2) Terms of payment (Irrevocable LC preferable) 
 
We require 3 samples. Please quote us best possible Ex-Colombo, Bangladash 
price. 
 
Thanks. 
  
Regards,
Vivian Jiang.
PRIME Shanghai
Add: Rm 15A, Liangfeng Tower, No. 8, Dongfang rd, Shanghai, China
Tel: +86-21-61226550,ext.8006
Fax:+86-21-61226552
M: +86-13661687657
E-mail: supportdept...@126.com
www.primeshanghai.com

Re: BImode and STORE_VALUE_FLAG

[Andreas Schwab]

"Paulo Matos"  writes:

> So I guess the problem (which might not be a problem after all can't be 
> reproduced in m68k and
> it's fine.

I don't think m68k is using BImode anywhere.

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 different."

Re: GCC 4.8.1 Status Report (2013-05-07)

[Diego Novillo]

On 2013-05-07 07:29 , Jakub Jelinek wrote:

There is one P1 bug currently open (--disable-nls bootstrap issue
on MinGW, Diego, can you please look at it?)


Sure.  I'm (finally) on it.


Diego.

ToT Build failure (internal compiler error: in phi_nodes_ptr)

[Steve Ellcey]

Is anyone else seeing this build failure with ToT GCC?  I am
building the mips-mti-linux-gnu target on an x86 linux box and
the libgcc build fails because the newly built GCC is dying.

Before I try to figure out which patch broke this I wanted to see
if anyone already knows about it.

Steve Ellcey
sell...@imgtec.com


configure:3589: 
/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/xgcc 
-B/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/ 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/bin/
 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/lib/
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/include
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/sys-include
-c -g -O2 -minterlink-mips16  conftest.c >&5
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: in phi_nodes_ptr, at 
tree-flow-inline.h:458
 }
 ^
0x73e403 phi_nodes_ptr
/local/home/sellcey/nightly2/src/gcc/gcc/tree-flow-inline.h:458
0x73e403 gsi_start_phis(basic_block_def*)
/local/home/sellcey/nightly2/src/gcc/gcc/gimple-iterator.c:867
0x8436b4 execute_function_todo
/local/home/sellcey/nightly2/src/gcc/gcc/passes.c:1947
0x8457ed execute_todo
/local/home/sellcey/nightly2/src/gcc/gcc/passes.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Re: OpenACC support in 4.9

[Jakub Jelinek]

On Tue, May 07, 2013 at 11:02:08AM +0200, Tobias Burnus wrote:
> Richard Biener wrote:
> >We're going to look at supporting HSA from GCC (which would make
> >it more or less trivial to also target openCL I think)
> 
> For the friends of link-time optimization (LTO):
> 
> Unless I missed some fine point in OpenACC and OpenMP's target, they
> only work with directives which are locally visible. Thus, if one
> does a function call in the device/target section, it can only be
> placed on the accelerator if the function can be inlined.

No, OpenMP 4.0 has
#pragma omp declare target
...
#pragma omp end declare target
where you can define/declare functions and variables in that ... and those
are all marked for cloning for the target device (guess parsing of
the above construct is going to just add "omp declare target" attribute
to all those variables/functions and we'd then just clone the functions
and map the variables into the target code).

The target code can perhaps be done by streaming LTO IL for the target
device into special sections during normal compilation and a linker plugin
invoked for -fopenmp could then collect those if any, compile the code
with a different backend and link both the host program and whatever
is needed for the target device.

Jakub

Re: GCC 4.8.1 Status Report (2013-05-07)

[Ryan Hill]

On Tue, 7 May 2013 13:29:30 +0200
Jakub Jelinek  wrote:

> Status
> ==
> 
> GCC 4.8.0 has been released more than one and half months ago, and the
> number of bugfixes on the branch is growing (70 fixed bugs with 4.8.1
> milestone so far, including 5 P1s), and additionally the C++ frontend
> reached C++11 feature completion milestone, so it is almost time to
> release the GCC 4.8.1.  I'd like to release it if all goes well in
> about two weeks from now, with a release candidate mid next week.
> There is one P1 bug currently open (--disable-nls bootstrap issue
> on MinGW, Diego, can you please look at it?) and several regressions from
> 4.7.x, so please try to help with bugfixing to make GCC 4.8.1 a good and
> stable release.

We really need TARGET_H added back to PLUGIN_HEADERS for grsecurity and
dragonegg.  The PR is 56754 and a patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01369.html

Bootstrap is also broken with --disable-dependency-tracking.  This is PR 55930.
As far as I can tell no one has looked at it yet.


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature