GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation

[Moritz Strübe]

Hi,

I have an issue with the optimization options. We are on an stm32 and it 
only has a prefetcher, but no cache. Thus it's nice to have linear 
default path. For example, we use  __builtin_expect in our asserts. Yet 
it seems that this does not work when using -Os. I confirmed that this 
is not an arm issue, but can also be seen on x86.
I have the following code:
--
#include 
#ifdef UN
#define UNLIKELY(x) __builtin_expect((x),0)
#else
#define UNLIKELY(x) (x)
#endif

float a = 66;

int test (float b, int test) {
     if(UNLIKELY(test)) {
     return b / a;
     } else {
     return b * a;
     }
}
--
"gcc -O2" reorders the code depending on a passed -DUN, while -Os always 
produces the same output (see https://godbolt.org/z/cL-Pbg)

I played around with different options running
gcc -O{s|2} -Q  --help=optimizers
, but didn't manage to get -Os to do that optimization.
Opposed to what the manual[1] says, this only differs in 
-finline-functions and -foptimize-strlen for 8.3
(OT: Especially the info about freorder-blocks-algorithm seems to be 
outdated for gcc 8.3 (my arm 7.3.1 produces smaller code using stc, too).)
Since adjusting all those options didn't help I tried
gcc -O{s|2} -Q  --help={param|common|target|c++}
but that didn't give me any new insight. (BTW: "-Q --help=param" should 
probably be documented in the --param-section)

Cheers
Moritz


[1] https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Optimize-Options.html

-- 
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

[PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[Nicholas Krause]

Not sure if this is a correct fix to this bug found here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
comments are welcome. If a backtrace is required please
let me know. I am just sending it to the development list
for review to make sure it's OK in terms of my understanding
the code.

Signed-off-by: Nicholas Krause 
---
 gcc/cp/constraint.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 9884eb0db50..a78d0a9a49b 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1882,7 +1882,7 @@ tsubst_requires_expr (tree t, tree args,
   tree parms = TREE_OPERAND (t, 0);
   if (parms)
 {
-  parms = tsubst_constraint_variables (parms, args, complain, in_decl);
+  parms = tsubst_constraint_variables (PARM_CONSTR_PARMS (parms), args, 
complain, in_decl);
   if (parms == error_mark_node)
 return error_mark_node;
 }
-- 
2.17.1

Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[Jonathan Wakely]

On Mon, 25 Mar 2019 at 12:39, Nicholas Krause  wrote:
>
> Not sure if this is a correct fix to this bug found here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
> comments are welcome. If a backtrace is required please
> let me know. I am just sending it to the development list
> for review to make sure it's OK in terms of my understanding
> the code.

That's what the gcc-patches list is for.

Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[nick]

On 2019-03-25 9:25 a.m., Jonathan Wakely wrote:
> On Mon, 25 Mar 2019 at 12:39, Nicholas Krause  wrote:
>>
>> Not sure if this is a correct fix to this bug found here:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
>> comments are welcome. If a backtrace is required please
>> let me know. I am just sending it to the development list
>> for review to make sure it's OK in terms of my understanding
>> the code.
> 
> That's what the gcc-patches list is for.
> 

Sorry it was sent there too. Didn't know which list was the correct one for
reviewing RFC patches.

Nick

Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[Jonathan Wakely]

On Mon, 25 Mar 2019 at 13:26, nick  wrote:
>
>
>
> On 2019-03-25 9:25 a.m., Jonathan Wakely wrote:
> > On Mon, 25 Mar 2019 at 12:39, Nicholas Krause  wrote:
> >>
> >> Not sure if this is a correct fix to this bug found here:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
> >> comments are welcome. If a backtrace is required please
> >> let me know. I am just sending it to the development list
> >> for review to make sure it's OK in terms of my understanding
> >> the code.
> >
> > That's what the gcc-patches list is for.
> >
>
> Sorry it was sent there too. Didn't know which list was the correct one for
> reviewing RFC patches.

https://gcc.gnu.org/lists.html
https://gcc.gnu.org/contribute.html#patches

Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[nick]

On 2019-03-25 9:29 a.m., Jonathan Wakely wrote:
> On Mon, 25 Mar 2019 at 13:26, nick  wrote:
>>
>>
>>
>> On 2019-03-25 9:25 a.m., Jonathan Wakely wrote:
>>> On Mon, 25 Mar 2019 at 12:39, Nicholas Krause  wrote:

 Not sure if this is a correct fix to this bug found here:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
 comments are welcome. If a backtrace is required please
 let me know. I am just sending it to the development list
 for review to make sure it's OK in terms of my understanding
 the code.
>>>
>>> That's what the gcc-patches list is for.
>>>
>>
>> Sorry it was sent there too. Didn't know which list was the correct one for
>> reviewing RFC patches.
> 
> https://gcc.gnu.org/lists.html
> https://gcc.gnu.org/contribute.html#patches
> 

Thanks Jonathan,

As for the patch documentation I will change the changelog after it's been 
reviewed. I'm 
newer to the code so would prefer it to be known correct and then I will just 
send a
a proper changelogged patch. Not that I normally wouldn't just would like to 
check
the code first before I sent a proper patch.

Nick

Regarding GSOC

[Aniket Agarwalla]

Hello Sir,

I am interested in working with you in your shortlisted projects on Gsoc
2019 namely
"Add new math.h and complex.h functions as built-ins".
I would like to add that I have a good mathematical background and have
been doing competitive programming for years now.So I think I can work hard
on this project and complete the project as per the organization
requirements. I also wanted to know what more I can do or submit a proposal
to get a chance to work with your organization.

Thanking you

Re: Gcov Internals

[Nathan Sidwell]

On 3/22/19 7:58 AM, Sebastian Roland wrote:

Hi,

I am currently trying to understand the internals of Gcov. Specifically 
I am wondering of the following:


1) Certain Basic Blocks are instrumented with counters that are 
incremented during execution. During compilation a destructor is 
registered that actually goes through a gcov_info struct and finds all 
counters in the appropriate gcov_fn_info struct(s). My question is how 
(and where in the source code) do the references to the various counters 
are linked to the gcov_info struct?


gcc/coverage.c generates the increments and the spanning tree used to 
determine where to place them.
2) What exactly is the purpose of the constructor (__gcov_init()) and 
where are the values of the passed gcov_info struct set (probably 
related to 1)?


It's a global constructor, libgcc/libgcov-$something

natha

--
Nathan Sidwell

Re: Warning in gcc/libiberty/dyn-string.c during build

[Martin Sebor]

On 3/23/19 9:49 PM, nick wrote:

Greetings all,
I just got this in my build output:
ar: `u' modifier ignored since `D' is the default (see `U')
configure: WARNING: cannot check for properly working vsnprintf when cross 
compiling, will assume it's ok
../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
  ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated 
before terminating nul copying as many bytes from a string as its length 
[-Wstringop-truncation]
  strncpy (dest->s + pos, src, length);
^~~~
  ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
272 |   int length = strlen (src);
|^~~~
  ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
\ ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated 
before terminating nul copying as many bytes from a string as its length 
[-Wstringop-truncation]
280 |   strncpy (dest->s + pos, src, length);
|   ^~~~
  ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
272 |   int length = strlen (src);
|^~~~

I've already looked through git blame and it seems this code was last touched 
in 2000. That warning seems
to be  new to gcc 8 after a little research so is this a rather old bug that 
was not found and very
subtle or is this a mislabel. Seems to be a mislabel to me but I'm new to the 
code base so just thought
I would ask.


The warning detects strncpy calls that create unterminated string
copies.  That can happen for example when the function is misused
by specifying a bound that's equal to the length of the source,
as in:

  void f (char *d, const char *s)
  {
int n = strlen (s);
strncpy (d, s, n);
  }

But the warning is far from perfect and it cannot distinguish
all the incorrect misuses from the benign ones.  For instance,
it triggers in the case below even though the copy is nul
terminated:

  void g (char *d, const char *s)
  {
int n = strlen (s);
d[n] = 0;
strncpy (d, s, n);
  }

In dyn_string_insert_cstr(), although the strnlen call itself
doesn't nul-terminate the copy (and so the warning isn't strictly
incorrect), the loop before the call does make sure the copy is
nul-terminated (similarly to function g above), and so the result
is a valid nul-terminated string.

I've been working on improving the warning to detect more instances
of nul-termination but I don't expect it to ever be smart enough
to figure out cases as complex as this one.  Using memcpy instead
of strncpy would avoid the warning.  (The loop above the strncpy
call could also be replaced by a call to memmove for efficiency.)

Martin

Gsoc

[FuN traveller]

Hello,
I am Darshan jadhao ,I am a computer engineering student at Lovely
Professional University, Jalandhar.
And I would like to work with GNU on the project  "c/c++
Not automatically promote memory".

Email:- darshan18jadha...@gmail.com

Re: Warning in gcc/libiberty/dyn-string.c during build

[Jeff Law]

On 3/25/19 10:39 AM, Martin Sebor wrote:
> On 3/23/19 9:49 PM, nick wrote:
>> Greetings all,
>> I just got this in my build output:
>> ar: `u' modifier ignored since `D' is the default (see `U')
>> configure: WARNING: cannot check for properly working vsnprintf when
>> cross compiling, will assume it's ok
>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>   ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>> truncated before terminating nul copying as many bytes from a string
>> as its length [-Wstringop-truncation]
>>   strncpy (dest->s + pos, src, length);
>> ^~~~
>>   ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>> 272 |   int length = strlen (src);
>> |    ^~~~
>>   ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>> \ ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>> truncated before terminating nul copying as many bytes from a string
>> as its length [-Wstringop-truncation]
>> 280 |   strncpy (dest->s + pos, src, length);
>> |   ^~~~
>>   ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>> 272 |   int length = strlen (src);
>> |    ^~~~
>>
>> I've already looked through git blame and it seems this code was last
>> touched in 2000. That warning seems
>> to be  new to gcc 8 after a little research so is this a rather old
>> bug that was not found and very
>> subtle or is this a mislabel. Seems to be a mislabel to me but I'm new
>> to the code base so just thought
>> I would ask.
> 
> The warning detects strncpy calls that create unterminated string
> copies.  That can happen for example when the function is misused
> by specifying a bound that's equal to the length of the source,
> as in:
> 
>   void f (char *d, const char *s)
>   {
>     int n = strlen (s);
>     strncpy (d, s, n);
>   }
> 
> But the warning is far from perfect and it cannot distinguish
> all the incorrect misuses from the benign ones.  For instance,
> it triggers in the case below even though the copy is nul
> terminated:
> 
>   void g (char *d, const char *s)
>   {
>     int n = strlen (s);
>     d[n] = 0;
>     strncpy (d, s, n);
>   }
The dynamic case is painful :-)






> In dyn_string_insert_cstr(), although the strnlen call itself
> doesn't nul-terminate the copy (and so the warning isn't strictly
> incorrect), the loop before the call does make sure the copy is
> nul-terminated (similarly to function g above), and so the result
> is a valid nul-terminated string.
This reminds me a bit of some of the failure to eliminate dead stores
problems that are in BZ as well as some of the uninit issues for memory
references that's been rattling around in my head.   It's also related
to SRA.  Richi has stated (and I tend to agree) there's a goodly amount
of common analysis that can probably be shared across these problems.

I don't know if there's a grand unifying analysis that will tackle all
of this, but it certainly feels like there's at least something worth
exploring in this space.

Jeff

Re: Warning in gcc/libiberty/dyn-string.c during build

[nick]

On 2019-03-25 3:45 p.m., Jeff Law wrote:
> On 3/25/19 10:39 AM, Martin Sebor wrote:
>> On 3/23/19 9:49 PM, nick wrote:
>>> Greetings all,
>>> I just got this in my build output:
>>> ar: `u' modifier ignored since `D' is the default (see `U')
>>> configure: WARNING: cannot check for properly working vsnprintf when
>>> cross compiling, will assume it's ok
>>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>>   ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>>> truncated before terminating nul copying as many bytes from a string
>>> as its length [-Wstringop-truncation]
>>>   strncpy (dest->s + pos, src, length);
>>> ^~~~
>>>   ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>>> 272 |   int length = strlen (src);
>>> |    ^~~~
>>>   ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>> \ ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>>> truncated before terminating nul copying as many bytes from a string
>>> as its length [-Wstringop-truncation]
>>> 280 |   strncpy (dest->s + pos, src, length);
>>> |   ^~~~
>>>   ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>>> 272 |   int length = strlen (src);
>>> |    ^~~~
>>>
>>> I've already looked through git blame and it seems this code was last
>>> touched in 2000. That warning seems
>>> to be  new to gcc 8 after a little research so is this a rather old
>>> bug that was not found and very
>>> subtle or is this a mislabel. Seems to be a mislabel to me but I'm new
>>> to the code base so just thought
>>> I would ask.
>>
>> The warning detects strncpy calls that create unterminated string
>> copies.  That can happen for example when the function is misused
>> by specifying a bound that's equal to the length of the source,
>> as in:
>>
>>   void f (char *d, const char *s)
>>   {
>>     int n = strlen (s);
>>     strncpy (d, s, n);
>>   }
>>
>> But the warning is far from perfect and it cannot distinguish
>> all the incorrect misuses from the benign ones.  For instance,
>> it triggers in the case below even though the copy is nul
>> terminated:
>>
>>   void g (char *d, const char *s)
>>   {
>>     int n = strlen (s);
>>     d[n] = 0;
>>     strncpy (d, s, n);
>>   }
> The dynamic case is painful :-)
> 
> 
> 
> 
> 
> 
>> In dyn_string_insert_cstr(), although the strnlen call itself
>> doesn't nul-terminate the copy (and so the warning isn't strictly
>> incorrect), the loop before the call does make sure the copy is
>> nul-terminated (similarly to function g above), and so the result
>> is a valid nul-terminated string.
> This reminds me a bit of some of the failure to eliminate dead stores
> problems that are in BZ as well as some of the uninit issues for memory
> references that's been rattling around in my head.   It's also related
> to SRA.  Richi has stated (and I tend to agree) there's a goodly amount
> of common analysis that can probably be shared across these problems.
> 
> I don't know if there's a grand unifying analysis that will tackle all
> of this, but it certainly feels like there's at least something worth
> exploring in this space.
> 
> Jeff
> 

The easiest way forward for me is should I just use W=1 or something or
even better is just ctags and parse the calls in the parts you mentioned.
It's worth looking into as there may be longs of small callers that
actually really add up.

As for Martin don't know if I would be much help but if you want help with
the work on -nul-terimated let me known.

Cheers,

Nick

Re: [GSoC 2019] No application template?

[Martin Jambor]

Hi,

On Sun, Mar 24 2019, 김규래 wrote:
> Hello,
> I was trying to write my application for GSoC 2019 but couldn't find an 
> application form for GCC.
> Some other organizations seem to have GSoC application forms/templates.
> The gcc GSoC wiki page doesn't mention any.
> Is the application format free? or did I miss it somewhere?

No, you did not miss anything, we do not have any specific application
format to follow.  In the OpenMP tread you sounded like you knew what
to do and why anyway.  But to at last give an example, last year this
was an application that would have been accepted if the applicant did
not retract it:
https://docs.google.com/document/d/1YkKYI3J-pKFfHLdxljWVoJ89l2oVGibxslIW3ikluz8/edit
(at least at the moment it i still available).

> If it is free, is there anything I should include else than what is mentioned 
> in [1, 2]
>  

Generally speaking, it is probably a good idea to accompany the proposed
project description with a brief motivation, an expected time-line (we
understand it is likely to change) and a brief introduction of your
technical background, skills and/or accomplishments.  The project
description is the most important part however (and each project is
perhaps best explained differently), we'll mostly judge your abilities
from your interactions with us, on mailing lists and IRC, rather than
from a CV.

If you share the proposal with us on this list some three or four work
days before submitting it, we are likely to have a look at it and
comment if we'd like something changed.

Good luck,

Martin


> Ray Kim
>  
> [1] https://www.drupal.org/node/59037
> [2] http://of-code.blogspot.com/2007/08/soc-experience-introduction.html

GSOC

[nick]

Greetings All,

I would like to take up parallelize compilation using threads or make c++/c 
memory issues not automatically promote. I did ask about this before but
not get a reply. When someone replies I'm just a little concerned as 
my writing for proposals has never been great so if someone just reviews
and doubt checks that's fine.

As for the other things building gcc and running the testsuite is fine. Plus
I already working on gcc so I've pretty aware of most things and this would
be a great steeping stone into more serious gcc development work.

If sample code is required that's in mainline gcc I sent out a trial patch
for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395

Cheers,

Nick

Re: GSoC

[Martin Jambor]

Hello Martin,

On Sun, Mar 10 2019, Martin Emil wrote:
> Hello ,
> I am Martin Emil last year computer engineering student from Egypt .
> I came through your project in GSoC  and i am very interested about it and
> want to work on it.
> I have strong knowledge in C,C++,Java and python programming
> languages.

Given the project you are interested in, do you have background in
parallel programming?  OpenMP in particular?  I am also worried that you
need at least some rudimentary theoretical background in the area of
compilers in order to apply too.

> I am interested in *Implementation of OMPD
> 
> in  GCC idea  , and i want to know more about it .*

We are happy to answer any specific question but this one is quite a bit
too broad.  Apart from what is covered by the spec you have linked, what
would you like to know?

Thanks,

Martin

Re: GSoC

[Jakub Jelinek]

On Tue, Mar 26, 2019 at 01:05:37AM +0100, Martin Jambor wrote:
> On Sun, Mar 10 2019, Martin Emil wrote:
> > Hello ,
> > I am Martin Emil last year computer engineering student from Egypt .
> > I came through your project in GSoC  and i am very interested about it and
> > want to work on it.
> > I have strong knowledge in C,C++,Java and python programming
> > languages.
> 
> Given the project you are interested in, do you have background in
> parallel programming?  OpenMP in particular?  I am also worried that you
> need at least some rudimentary theoretical background in the area of
> compilers in order to apply too.
> 
> > I am interested in *Implementation of OMPD
> > 
> > in  GCC idea  , and i want to know more about it .*

Note, the current OMPD spec is in
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf

Jakub

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Andi Kleen]

sameeran joshi  writes:

> On 3/24/19, Andi Kleen  wrote:
>> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>>> 1) check_structured_block_conditions()
>>> checks for the conditions related to a structured block
>>> 1.no returns in block
>>
>> returns should be allowed inside statement expressions.
> If I am correct, we would create a new branch  "COMPsmith"(C OpenMP
> smith)(name will this work?)  from the master of Csmith and work on
> it, statement expression are in the "gcc c extensions" branch I guess
> which would be a separate branch.
>
> So it shouldn't allow return as well, right?

Yes
>> Yes check for continue too.
> referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
> continue can be used but with some restriction as:
>
> "innermost associated loop may be curtailed by a continue statement "

Ah you're right. Better don't do continue then.

>> If yes that would seem like a gcc bug. I would file in bugzilla with a
>> simple test case.
>>
> Did you file it? can you please send me the bug id?

I didn't. Can you show some simple example that errors first?

Perhaps Jakub or some other OpenMP expert can also chime in.

>>
>>>
>>>
>>> 1.Can I use a struct field variable for initialization?:
>>>
>>> Whereas the 5.0 specification states:
>>> var operator lb
>>> var := variable of signed or unsigned type | variable of pointer type
>>> which obeys the specification rules.
>>>
>>> error:expected iteration declaration/initialization before 'g_371'
>>
>> Ok I guess it's not supported, so you can't.
> Any specific reason for not supporting struct variables as
> initialization, as the spec. doesn't impose any restriction

Yes it seems like a gcc restriction. I would file a bug (feature
request) that one. It's good, these are the kind of things
the OpenMP fuzzing project should be finding.


-Andi