> I don't know the specifics of your example, but from how I understand
> it, I don't see a problem if the compiler can prove that the store will
> always happen.
>
> To be more specific, if the compiler can prove that the store will
> happen anyway, and the region of code can be assumed to always
Hi,
I'm trying to use the tests in "gcc/testsuite/gnat.dg" and I'm having trouble
understanding one particular test: "gnat.dg/div_no_warning.adb". If I
understand correctly, this test is expected to compile without any error or
warning. When I compile this test with a native compiler gnatmake,
Hi.
I would like to get started with how to improve code generation for a
backend. Any pointers, especially to good documentation is welcome.
For this example consider this C function for a reference counted type:
void TCRelease(TCTypeRef tc) {
if (--tc->retainCount == 0) {
if (tc->destroy)
On Tue, Feb 11, 2014 at 10:20 PM, Jan Hubicka wrote:
>> >> Since both toolchains do the magic, binutils has no incentive to
>> >> create any automatic detection of objects.
>>
>> It is mostly a historical decision. At the time the design was for the
>> plugin to be matched to the compiler, and so
On Wed, Feb 12, 2014 at 7:21 AM, Albert Cahalan wrote:
> I had a problem that got solved in an ugly way. I think gcc ought
> to provide a few ways to make a nicer solution.
>
> There was an array of structs roughly like so:
>
> struct{int w;float x;char y[4];short z[2];}foo[512][4];
>
> The types
> What about instead of our current odd way of identifying LTO objects
> simply add a special ELF note telling the linker the plugin to use?
>
> .note._linker_plugin '/./libltoplugin.so'
>
> that way the linker should try 1) loading that plugin, 2) register the
> specific object with that plugi
On 02/12/14 02:37, Fredrik Olsson wrote:
Hi.
I would like to get started with how to improve code generation for a
backend. Any pointers, especially to good documentation is welcome.
For this example consider this C function for a reference counted type:
void TCRelease(TCTypeRef tc) {
if (--
On Wed, 12 Feb 2014, Richard Biener wrote:
> What about instead of our current odd way of identifying LTO objects
> simply add a special ELF note telling the linker the plugin to use?
>
> .note._linker_plugin '/./libltoplugin.so'
>
> that way the linker should try 1) loading that plugin, 2)
> On Wed, 12 Feb 2014, Richard Biener wrote:
>
> > What about instead of our current odd way of identifying LTO objects
> > simply add a special ELF note telling the linker the plugin to use?
> >
> > .note._linker_plugin '/./libltoplugin.so'
> >
> > that way the linker should try 1) loading
On Tue, Feb 11, 2014 at 10:06:34PM -0800, Torvald Riegel wrote:
> On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote:
> > On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote:
> > > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> > > >
> > > > Intuitively, this is wrong be
On Wed, Feb 12, 2014 at 10:19:07AM +0100, Peter Zijlstra wrote:
> > I don't know the specifics of your example, but from how I understand
> > it, I don't see a problem if the compiler can prove that the store will
> > always happen.
> >
> > To be more specific, if the compiler can prove that the s
On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote:
> You need volatile semantics to force the compiler to ignore any proofs
> it might otherwise attempt to construct. Hence all the ACCESS_ONCE()
> calls in my email to Torvald. (Hopefully I translated your example
> reasonably.)
My
On Tue, Feb 11, 2014 at 09:39:24PM -0800, Torvald Riegel wrote:
> On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote:
> > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> > >
> > > Intuitively, this is wrong because this let's the program take a step
> > > the abstract machine wouldn't
On Tue, Feb 11, 2014 at 09:13:34PM -0800, Torvald Riegel wrote:
> On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote:
> > On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote:
> > > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote:
> > > > On Fri, Feb 07, 2014 at 12:44:48A
On Feb 11, 2014, at 10:59 AM, Renato Golin wrote:
> Hi Folks,
>
> First of all, I'd like to thank everyone for their great responses and
> heart warming encouragement for such an enterprise. This will be my
> last email about this subject on these lists, so I'd like to just let
> everyone know wh
On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney
wrote:
>
> Us Linux-kernel hackers will often need to use volatile semantics in
> combination with C11 atomics in most cases. The C11 atomics do cover
> some of the reasons we currently use ACCESS_ONCE(), but not all of them --
> in particular, i
On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney
> wrote:
> >
> > Us Linux-kernel hackers will often need to use volatile semantics in
> > combination with C11 atomics in most cases. The C11 atomics do cover
> > some of the reaso
Hi,
I have a question about the implementation of
aarch64_final_eh_return_addr
which is used to point out the return address of the frame
According the source code
If FP is not needed
return gen_frame_mem (DImode,
plus_constant (Pmode,
Let me ask a different question.
On GCC 3.2.3, does this sequence look correct:
./configure --target=i370-mvspdp --prefix=~/devel/mvscross --with-sysroot=~/devel/mvshead
--enable-languages=c
make
make install
./configure --build=x86_64-unknown-linux-gnu --host=i370-mvspdp --target=i370-mvspdp
Hi PPL i developed a plugin that produces the following gimple
test ()
{
int selected_fnc_var_.3;
int random_Var.2;
int D.2363;
int _1;
:
random_Var.2_2 = rand ();
selected_fnc_var_.3_3 = random_Var.2_2 %[fl] 5;
if (selected_fnc_var_.3_3 == 4) goto ;
if (selected_fnc_var_.3_3
20 matches
Mail list logo
