Re: Bisected failure

2022-02-20 Thread Søren Holm via Gcc 

Please ignore my previous email.

As usual after reaching out - a little light appears in the dark. My 
problem seems to be a kind of race initiated by some hardware state.


Sorry for the noise :)

Den 19.02.2022 kl. 18.11 skrev Søren Holm via Gcc:

Hi

My application running on a stm32f7 started to behave "random" when 
compiled with gcc 10.1 - Gcc 9.x works fine.


By random I mean this.

1. Flash the application onto the target.
2. reset - the application starts up fine
2. reset again - the application somehow goes haywire during startup 
effectively starting over with out a reset. That ends up leaving 
interrups and timers enabled fireing during BSS clear.

3. Reset again - now the application starts up fine again.
4. reset again - lockup again
5. reset again - lockup again
6 ...


I have bisected and verified that whatever makes my

commit 79f1d8521882de51480866fd7037199d670316bd (HEAD, refs/bisect/bad)
Author: Jan Hubicka 
Date:   Thu Nov 14 14:30:46 2019 +0100

     * params.opt (max-inline-insns-single-O2): Set to 70 (instead of 30).

     From-SVN: r278221


Do you have any ideas to how to hunt down this bug? Besides trying to 
isolate the place where things go wrong. I'm unsure if GCC does 
something that the hardware does not like or my application is buggy. In 
any case I'd like to figure out the root cause. I do not like to be 
stuck at gcc 9 because of these kinds of issues :)


I'd appreciate any input you might have.

/Søren

Re: GCC GSoC 2022: Call for project ideas and mentors

2022-02-20 Thread Thomas Schwinge 
Hi David!

On 2022-01-07T12:41:17-0500, David Malcolm via Fortran  
wrote:
> I'd like to (again) mentor a project relating to the GCC static
> analyzer:
>   https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
>
> I've updated the analyzer task ideas on:
>   https://gcc.gnu.org/wiki/SummerOfCode
> but the ideas there are suggestions

May I suggest -- and add to that page if you agree to co-mentor :-) --
another GCC static analyzer project?  Responding to your initial
"RFC: Add a static analysis framework to GCC", in

I had said:

On 2019-11-16T21:42:25+0100, I wrote:
> On 2019-11-15T20:22:47-0500, David Malcolm  wrote:
>> [...]
>> Specific state machines include:
>> - a checker for malloc/free, for detecting double-free, resource leaks,
>>   use-after-free, etc (sm-malloc.cc), and
>
> I can immediately see how this can be useful for a bunch of
> 'malloc'/'free'-like etc. OpenACC Runtime Library calls as well as source
> code directives.  ..., and this would've flagged existing code in the
> libgomp OpenACC tests, which recently has given me some grief. Short
> summary/examples:
>
> In addition to host-side 'malloc'/'free', there is device-side (separate
> memory space) 'acc_malloc'/'acc_free'.  Static checking example: don't
> mix up host-side and device-side pointers.  (Both are normal C/C++
> pointers.  Hmm, maybe such checking could easily be implemented even
> outside of your checker by annotating the respective function
> declarations with an attribute describing which in/out arguments are
> host-side vs. device-side pointers.)
>
> Then, there are functions to "map" host-side and device-side memory:
> 'acc_map_data'/'acc_unmap_data'.  Static checking example: you must not
> 'acc_free' memory spaces that are still mapped.
>
> Then, there are functions like 'acc_create' (or equivalent directives
> like '#pragma acc create') doing both 'acc_malloc', 'acc_map_data'
> (plus/depending on internal reference counting).  Static checking
> example: for a pointer returned by 'acc_create" etc., you must use
> 'acc_delete' etc. instead of 'acc_free', which first does
> 'acc_unmap_data' before interal 'acc_free' (..., and again all that
> depending on reference counting).  (Might be "interesting" to teach your
> checker about the reference counting -- if that is actually necessary;
> needs further thought.)

So, something like: "Extend the GCC static analyzer to understand OpenACC
host vs. device memory" (plus an example or two, similar to what I quoted
above).  The project can scale depending on what we/applicant intends to
do.  I'm happy to advise on the OpenACC bits, but will need you for the
general analyzer infrastructure.  Opinions?


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: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

2022-02-20 Thread Shubham Narlawar via Gcc 
On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski  wrote:
>
> On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
>  wrote:
> >
> > Hello,
> >
> > I want to know whether it is correct to add left shift instruction to
> > a constant expression statement like "_3 + 4"?
> >
> > I am trying to add a left shift instruction in between below GIMPLE
> > instructions -
> >
> >:
> >   instrn_buffer.0_1 = instrn_buffer;
> >   _2 = tree.cnt;
> >   _3 = (int) _2;
> >   _4 = _3 + 4;
> >   _5 = (unsigned int) _4;// I want to add left shift here
> >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> > //this is "stmt"
> >
> > I am using this snippet in custom gcc plugin -
> >
> >   tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> > NULL, "slli");
>
> A couple of things.
> I Noticed you use integer_type_node here. Why not the type of what is
> being replaced?
> That is the main thing I see right now.

I want to apply left shift to a constant expression with 8 which is an
integer. Since I am not replacing a statement, I am creating new
GIMPLE statement -

tree shift_amt = build_int_cst (integer_type_node, 8);

Here, I am not replacing any GIMPLE statement. Is this the correct way
to do this?

My goal is to left shift constant expression and update its usage as below -

  _19 = (unsigned int) _18;
  D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19);

into

  _19 = (unsigned int) _18;
temp = _19 << 8
  D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp);

I am storing the left shift result to the new ssa variable name "temp"
and updating sfploadi parameters as expected.

On doing the above, dom_walker_eliminate is prohibiting me to do the
above gimple transformation. Is the above transformation complete and
correct?

>
> Also you shouldn't need to do:
> update_ssa (TODO_update_ssa);
>
> As make_temp_ssa_name is a new SSA name already and such.

Understood.

Thanks and Regards,
Shubham


>
> Thanks,
> Andrew Pinski
>
> >   gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, 
> > parm,
> >   build_int_cst
> > (integer_type_node, 8));
> >   gsi_insert_before(&gsi, lshift, GSI_NEW_STMT);
> >   //Update function call
> >   gimple_call_set_arg (stmt, idx, lshift_tmp);
> >   update_stmt (stmt);
> >   update_ssa (TODO_update_ssa);
> >
> > from which above GIMPLE IR is modified to -
> >
> >:
> >   instrn_buffer.0_1 = instrn_buffer;
> >   _2 = tree.cnt;
> >   _3 = (int) _2;
> >   _4 = _3 + 4;
> >   _5 = (unsigned int) _4;
> >   slli_24 = _5 << 8;
> >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24);
> >
> >
> > 1. When I run above code, either dominator tree validation or tree cfg
> > fixup is failing which suggests to me it is either incorrect to apply
> > such left shift or some more work is missing?
> >
> > 2. I followed how a left shift gimple assignment is generated but
> > still feels there is something wrong with the above generation. Can
> > someone please point me out?
> >
> > Thanks in advance! As always, the GCC community and its members are
> > very supportive, responsive and helpful!
> >
> > Regards,
> > Shubham

gcc-12-20220220 is now available

2022-02-20 Thread GCC Administrator via Gcc 
Snapshot gcc-12-20220220 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision e49508ac6b36adb8a2056c5a1fb6e0178de2439d

You'll find:

 gcc-12-20220220.tar.xz   Complete GCC

  SHA256=4355d5cc684ad282472ad2a24a333ac53f26dcdb0bda01887478a89c56012db4
  SHA1=db49cbc1081aecd98ad992c72f0ae0d8d5ec2b13

Diffs from 12-20220213 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

2022-02-20 Thread Andrew Pinski via Gcc 
On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar  wrote:
>
> On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski  wrote:
> >
> > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
> >  wrote:
> > >
> > > Hello,
> > >
> > > I want to know whether it is correct to add left shift instruction to
> > > a constant expression statement like "_3 + 4"?
> > >
> > > I am trying to add a left shift instruction in between below GIMPLE
> > > instructions -
> > >
> > >:
> > >   instrn_buffer.0_1 = instrn_buffer;
> > >   _2 = tree.cnt;
> > >   _3 = (int) _2;
> > >   _4 = _3 + 4;
> > >   _5 = (unsigned int) _4;// I want to add left shift here
> > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> > > //this is "stmt"
> > >
> > > I am using this snippet in custom gcc plugin -
> > >
> > >   tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> > > NULL, "slli");
> >
> > A couple of things.
> > I Noticed you use integer_type_node here. Why not the type of what is
> > being replaced?
> > That is the main thing I see right now.
>
> I want to apply left shift to a constant expression with 8 which is an
> integer. Since I am not replacing a statement, I am creating new
> GIMPLE statement -
>
> tree shift_amt = build_int_cst (integer_type_node, 8);
>
> Here, I am not replacing any GIMPLE statement. Is this the correct way
> to do this?
>
> My goal is to left shift constant expression and update its usage as below -
>
>   _19 = (unsigned int) _18;
>   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19);
>
> into
>
>   _19 = (unsigned int) _18;
> temp = _19 << 8
>   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp);
>
> I am storing the left shift result to the new ssa variable name "temp"
> and updating sfploadi parameters as expected.
>
> On doing the above, dom_walker_eliminate is prohibiting me to do the
> above gimple transformation. Is the above transformation complete and
> correct?

I think you misunderstood me. I was saying for a left shift gimple,
the result type and the first operand type must be compatible (signed
and unsigned types are not compatible). In the above case, you have:
integer_type_node = unsigned_int << integer_type_name .

Does that make sense now?

Thanks,
Andrew

>
> >
> > Also you shouldn't need to do:
> > update_ssa (TODO_update_ssa);
> >
> > As make_temp_ssa_name is a new SSA name already and such.
>
> Understood.
>
> Thanks and Regards,
> Shubham
>
>
> >
> > Thanks,
> > Andrew Pinski
> >
> > >   gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, 
> > > parm,
> > >   build_int_cst
> > > (integer_type_node, 8));
> > >   gsi_insert_before(&gsi, lshift, GSI_NEW_STMT);
> > >   //Update function call
> > >   gimple_call_set_arg (stmt, idx, lshift_tmp);
> > >   update_stmt (stmt);
> > >   update_ssa (TODO_update_ssa);
> > >
> > > from which above GIMPLE IR is modified to -
> > >
> > >:
> > >   instrn_buffer.0_1 = instrn_buffer;
> > >   _2 = tree.cnt;
> > >   _3 = (int) _2;
> > >   _4 = _3 + 4;
> > >   _5 = (unsigned int) _4;
> > >   slli_24 = _5 << 8;
> > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24);
> > >
> > >
> > > 1. When I run above code, either dominator tree validation or tree cfg
> > > fixup is failing which suggests to me it is either incorrect to apply
> > > such left shift or some more work is missing?
> > >
> > > 2. I followed how a left shift gimple assignment is generated but
> > > still feels there is something wrong with the above generation. Can
> > > someone please point me out?
> > >
> > > Thanks in advance! As always, the GCC community and its members are
> > > very supportive, responsive and helpful!
> > >
> > > Regards,
> > > Shubham

Re: Benchmark recommendations needed

2022-02-20 Thread Gary Oblock via Gcc 
Trying to use the dhrystone isn't going to be very useful. It has many 
downsides not the least is that gcc's optimizer can run rings about it.

Gary


From: Gcc  on behalf of 
gcc-requ...@gcc.gnu.org 
Sent: Tuesday, February 15, 2022 6:25 AM
To: gcc@gcc.gnu.org 
Subject: Re:

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Send Gcc mailing list submissions to
gcc@gcc.gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://gcc.gnu.org/mailman/listinfo/gcc
or, via email, send a message with subject or body 'help' to
gcc-requ...@gcc.gnu.org

You can reach the person managing the list at
gcc-ow...@gcc.gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gcc digest..."

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

2022-02-20 Thread Richard Biener via Gcc 
On Sun, Feb 20, 2022 at 11:44 PM Andrew Pinski via Gcc  wrote:
>
> On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar  
> wrote:
> >
> > On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski  wrote:
> > >
> > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > > I want to know whether it is correct to add left shift instruction to
> > > > a constant expression statement like "_3 + 4"?
> > > >
> > > > I am trying to add a left shift instruction in between below GIMPLE
> > > > instructions -
> > > >
> > > >:
> > > >   instrn_buffer.0_1 = instrn_buffer;
> > > >   _2 = tree.cnt;
> > > >   _3 = (int) _2;
> > > >   _4 = _3 + 4;
> > > >   _5 = (unsigned int) _4;// I want to add left shift here
> > > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> > > > //this is "stmt"
> > > >
> > > > I am using this snippet in custom gcc plugin -
> > > >
> > > >   tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> > > > NULL, "slli");
> > >
> > > A couple of things.
> > > I Noticed you use integer_type_node here. Why not the type of what is
> > > being replaced?
> > > That is the main thing I see right now.
> >
> > I want to apply left shift to a constant expression with 8 which is an
> > integer. Since I am not replacing a statement, I am creating new
> > GIMPLE statement -
> >
> > tree shift_amt = build_int_cst (integer_type_node, 8);
> >
> > Here, I am not replacing any GIMPLE statement. Is this the correct way
> > to do this?
> >
> > My goal is to left shift constant expression and update its usage as below -
> >
> >   _19 = (unsigned int) _18;
> >   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19);
> >
> > into
> >
> >   _19 = (unsigned int) _18;
> > temp = _19 << 8
> >   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp);
> >
> > I am storing the left shift result to the new ssa variable name "temp"
> > and updating sfploadi parameters as expected.
> >
> > On doing the above, dom_walker_eliminate is prohibiting me to do the
> > above gimple transformation. Is the above transformation complete and
> > correct?
>
> I think you misunderstood me. I was saying for a left shift gimple,
> the result type and the first operand type must be compatible (signed
> and unsigned types are not compatible). In the above case, you have:
> integer_type_node = unsigned_int << integer_type_name .
>
> Does that make sense now?

Btw, the error you see is still odd - please make sure to build GCC with
checking enabled or run your tests with -fchecking.  For further help
it might be useful to post the patch you are testing to show where exactly
you are hooking into to add this statement.

Richard.

> Thanks,
> Andrew
>
> >
> > >
> > > Also you shouldn't need to do:
> > > update_ssa (TODO_update_ssa);
> > >
> > > As make_temp_ssa_name is a new SSA name already and such.
> >
> > Understood.
> >
> > Thanks and Regards,
> > Shubham
> >
> >
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > > >   gimple *lshift = gimple_build_assign (lshift_tmp, 
> > > > LSHIFT_EXPR, parm,
> > > >   build_int_cst
> > > > (integer_type_node, 8));
> > > >   gsi_insert_before(&gsi, lshift, GSI_NEW_STMT);
> > > >   //Update function call
> > > >   gimple_call_set_arg (stmt, idx, lshift_tmp);
> > > >   update_stmt (stmt);
> > > >   update_ssa (TODO_update_ssa);
> > > >
> > > > from which above GIMPLE IR is modified to -
> > > >
> > > >:
> > > >   instrn_buffer.0_1 = instrn_buffer;
> > > >   _2 = tree.cnt;
> > > >   _3 = (int) _2;
> > > >   _4 = _3 + 4;
> > > >   _5 = (unsigned int) _4;
> > > >   slli_24 = _5 << 8;
> > > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24);
> > > >
> > > >
> > > > 1. When I run above code, either dominator tree validation or tree cfg
> > > > fixup is failing which suggests to me it is either incorrect to apply
> > > > such left shift or some more work is missing?
> > > >
> > > > 2. I followed how a left shift gimple assignment is generated but
> > > > still feels there is something wrong with the above generation. Can
> > > > someone please point me out?
> > > >
> > > > Thanks in advance! As always, the GCC community and its members are
> > > > very supportive, responsive and helpful!
> > > >
> > > > Regards,
> > > > Shubham