Re: Successful bootstrap and install of gcc (GCC) 6.3.0 on mips64el-unknown-linux-gnu

[Dennis Luehring]

are you only building gcc or also glibc/binutils? and building a kernel 
with minimal hello world init or something for testing?


what about a dec-alpha build test :)

Am 08.01.2017 um 21:27 schrieb Aaro Koskinen:

Hi,

Here's a report of a successful build and install of GCC:

$ gcc-6.3.0/config.guess
mips64el-unknown-linux-gnu

$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/mipsel-unknown-linux-gnu/6.3.0/lto-wrapper
Target: mipsel-unknown-linux-gnu
Configured with: ../gcc-6.3.0/configure --with-arch=loongson2f --with-abi=32 
--with-fp-32=xx --enable-targets=all --disable-nls 
--prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ 
--host=mipsel-unknown-linux-gnu --build=mipsel-unknown-linux-gnu 
--target=mipsel-unknown-linux-gnu --with-system-zlib --with-sysroot=/
Thread model: posix
gcc version 6.3.0 (GCC)

-- Build environment --

host: fuloong-minipc
distro:   los.git rootfs=ef31e1 native=ef31e1
kernel:   Linux 4.9.0-lemote-los_ef31e1
binutils: GNU binutils 2.27
make: GNU Make 4.2.1
libc: GNU C Library (GNU libc) stable release version 2.24
zlib: 1.2.8
mpfr: 3.1.3
gmp:  6

-- Time consumed --

configure:  real0m 23.73s
user0m 15.35s
sys 0m 6.22s

bootstrap:  real50h 9m 38s
user46h 31m 26s
sys 3h 16m 30s

install:real16m 28.01s
user6m 15.90s
sys 7m 51.50s

-- Hardware details ---

MemTotal: 494016 kB

system type : lemote-fuloong-2f-box
machine : Unknown
processor   : 0
cpu model   : ICT Loongson-2 V0.3  FPU V0.1
BogoMIPS: 264.19
wait instruction: yes
microsecond timers  : yes
tlb_entries : 64
extra interrupt vector  : no
hardware watchpoint : yes, count: 0, address/irw mask: []
isa : mips2 mips3
ASEs implemented:
shadow register sets: 1
kscratch registers  : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available

A.

Adoption of C subset standards

[Jim MacArthur]

Hi all, I've become involved in a group which seeks to refine previous 
efforts in both safety-critical and secure coding standards (for example 
MISRA and CERT-C). We note that in the past MISRA has been declined for 
explicit inclusion in GCC but that parts of it and CERT-C are tested by 
individual flags.


For either new standards or existing standards like TS 17961, would the 
GCC maintainers be opposed to forming a new option (possibly an option 
for --std=) to test for a particular standard, or whatever subset of it 
can currently be checked? I expect someone from the our group would 
provide patches for the tests.


One of the reasons for asking is that we'd like to remove any barriers 
to adoption of our new standard by GCC; in particular, trying to 
determine if the new standard not being LGPL or similar would be a problem.


Thanks for any advice you can offer.

Jim MacArthur

GCC 7.0.0 Status Report (2017-01-09), Stage 4 to start soon

[Jakub Jelinek]

The trunk is still in Stage 3 now, which means it is open for general
bugfixing, but will enter Stage 4 on Thursday, 19th, end of day (timezone
of your preference).  Once that happens, only wrong-code fixes, regression
bugfixes and documentation fixes will be allowed, as is normal for
our release branches too.

We are behind schedule in the amount of P1-P3 PRs compared e.g. to
GCC 5 or GCC 6, so any help with fixing regressions will be appreciated.


Quality Data


Priority  #   Change from last report
---   ---
P1   12+   8
P2  138+  24
P3   88-  89
P4  134+  25
P5   30+   1
---   ---
Total P1-P3 238-  57
Total   402-  31


Previous Report
===

https://gcc.gnu.org/ml/gcc/2016-11/msg00051.html

Question about inlining and strict_aliasing

[Martin Liška]

Hello.

I've been working on a patch that would cope with target and optimization (read 
PerFunction)
in a proper way. I came to following test-case (slightly modified 
./gcc/testsuite/gcc.c-torture/execute/alias-1.c):

int val;

int *ptr = &val;
float *ptr2 = &val;

static
__attribute__((always_inline, optimize ("-fno-strict-aliasing")))
typepun ()
{
  *ptr2=0;
}

main()
{
  *ptr=1;
  typepun ();
  if (*ptr)
__builtin_abort ();
}

$ gcc -O2 /tmp/always-inline.c -fdump-tree-all-details && ./a.out
Aborted (core dumped)

Problem is that einline does:

  Inlining typepun into main (always_inline).
   Estimating body: typepun/3
   Known to be false: not inlined
   size:2 time:2
Dropping flag_strict_aliasing on main:4 << here is strict_aliasing drop
Accounting size:2.00, time:2.00 on predicate:(true)

However fre1 does not still check for flag_strict_aliasing. Is it bug or not?
I did an experimental fix, but I guess there will me multiple places where the 
flag is checked.

Second question:
Current ipa-inline.c code contains question sophisticated 
check_{match,maybe_up,maybe_down} and
it's following by:

  /* When user added an attribute to the callee honor it.  */
  else if (lookup_attribute ("optimize", DECL_ATTRIBUTES (callee->decl))
   && opts_for_fn (caller->decl) != opts_for_fn (callee->decl))
{
  e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
  inlinable = false;
}

I think it's very strict, as when one uses __attribute__((optimize)) with a 
param that matches with
command line arguments, it will return false. What if we remove the hunk?

Thanks,
Martin
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 871fa121fd0..da38e4fab69 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -986,7 +986,7 @@ ncr_compar (const void *field1_, const void *field2_)
 static bool
 nonoverlapping_component_refs_p (const_tree x, const_tree y)
 {
-  if (!flag_strict_aliasing
+  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing
   || !x || !y
   || TREE_CODE (x) != COMPONENT_REF
   || TREE_CODE (y) != COMPONENT_REF)
@@ -1167,7 +1167,7 @@ indirect_ref_may_alias_decl_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
 return false;
 
   /* Disambiguations that rely on strict aliasing rules follow.  */
-  if (!flag_strict_aliasing || !tbaa_p)
+  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || !tbaa_p)
 return true;
 
   ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
@@ -1334,7 +1334,7 @@ indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
 return false;
 
   /* Disambiguations that rely on strict aliasing rules follow.  */
-  if (!flag_strict_aliasing || !tbaa_p)
+  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || !tbaa_p)
 return true;
 
   ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
@@ -1508,7 +1508,7 @@ refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool tbaa_p)
 
   /* First defer to TBAA if possible.  */
   if (tbaa_p
-  && flag_strict_aliasing
+  && opts_for_fn (current_function_decl)->x_flag_strict_aliasing
   && !alias_sets_conflict_p (ao_ref_alias_set (ref1),
  ao_ref_alias_set (ref2)))
 return false;

Re: Question about inlining and strict_aliasing

[Jan Hubicka]

> Hello.
> 
> I've been working on a patch that would cope with target and optimization 
> (read PerFunction)
> in a proper way. I came to following test-case (slightly modified 
> ./gcc/testsuite/gcc.c-torture/execute/alias-1.c):
> 
> int val;
> 
> int *ptr = &val;
> float *ptr2 = &val;
> 
> static
> __attribute__((always_inline, optimize ("-fno-strict-aliasing")))
> typepun ()
> {
>   *ptr2=0;
> }
> 
> main()
> {
>   *ptr=1;
>   typepun ();
>   if (*ptr)
> __builtin_abort ();
> }
> 
> $ gcc -O2 /tmp/always-inline.c -fdump-tree-all-details && ./a.out
> Aborted (core dumped)
> 
> Problem is that einline does:
> 
>   Inlining typepun into main (always_inline).
>Estimating body: typepun/3
>Known to be false: not inlined
>size:2 time:2
> Dropping flag_strict_aliasing on main:4 << here is strict_aliasing drop
>   Accounting size:2.00, time:2.00 on predicate:(true)
> 
> However fre1 does not still check for flag_strict_aliasing. Is it bug or not?
> I did an experimental fix, but I guess there will me multiple places where 
> the 
> flag is checked.

Aha, I think the problem is that once we modify strict aliasing of cfun, we need
to re-set the global optimization attributes, becuase those are still copies 
from
the original declaration.
> 
> Second question:
> Current ipa-inline.c code contains question sophisticated 
> check_{match,maybe_up,maybe_down} and
> it's following by:
> 
>   /* When user added an attribute to the callee honor it.  */
>   else if (lookup_attribute ("optimize", DECL_ATTRIBUTES (callee->decl))
>  && opts_for_fn (caller->decl) != opts_for_fn (callee->decl))
>   {
> e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> inlinable = false;
>   }
> 
> I think it's very strict, as when one uses __attribute__((optimize)) with a 
> param that matches with
> command line arguments, it will return false. What if we remove the hunk?

I am not quite sure.  If you have function A with optimization attribute and 
you inline it to function b
with same command line parameters, it may enable to inline it into function C 
where A would not be inlined
because of the explicit optimization attribute.
If we relax this check, we will need to copy the optimization attribute from A 
to B at the time
we inline into B.
> 
> Thanks,
> Martin

> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> index 871fa121fd0..da38e4fab69 100644
> --- a/gcc/tree-ssa-alias.c
> +++ b/gcc/tree-ssa-alias.c
> @@ -986,7 +986,7 @@ ncr_compar (const void *field1_, const void *field2_)
>  static bool
>  nonoverlapping_component_refs_p (const_tree x, const_tree y)
>  {
> -  if (!flag_strict_aliasing
> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing

This should not be necessary. Einline ought to update global opts.
I suppose when decl modified is cfun one needs to reset current_funcion_decl
to NULL and then set it again so the global flags changing machinery notices 
this
change.

Honza
t
>|| !x || !y
>|| TREE_CODE (x) != COMPONENT_REF
>|| TREE_CODE (y) != COMPONENT_REF)
> @@ -1167,7 +1167,7 @@ indirect_ref_may_alias_decl_p (tree ref1 
> ATTRIBUTE_UNUSED, tree base1,
>  return false;
>  
>/* Disambiguations that rely on strict aliasing rules follow.  */
> -  if (!flag_strict_aliasing || !tbaa_p)
> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || 
> !tbaa_p)
>  return true;
>  
>ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
> @@ -1334,7 +1334,7 @@ indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, 
> tree base1,
>  return false;
>  
>/* Disambiguations that rely on strict aliasing rules follow.  */
> -  if (!flag_strict_aliasing || !tbaa_p)
> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || 
> !tbaa_p)
>  return true;
>  
>ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
> @@ -1508,7 +1508,7 @@ refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool 
> tbaa_p)
>  
>/* First defer to TBAA if possible.  */
>if (tbaa_p
> -  && flag_strict_aliasing
> +  && opts_for_fn (current_function_decl)->x_flag_strict_aliasing
>&& !alias_sets_conflict_p (ao_ref_alias_set (ref1),
>ao_ref_alias_set (ref2)))
>  return false;

Re: Adoption of C subset standards

[David Brown]

On 09/01/17 12:34, Jim MacArthur wrote:
> Hi all, I've become involved in a group which seeks to refine previous
> efforts in both safety-critical and secure coding standards (for example
> MISRA and CERT-C). We note that in the past MISRA has been declined for
> explicit inclusion in GCC but that parts of it and CERT-C are tested by
> individual flags.
> 
> For either new standards or existing standards like TS 17961, would the
> GCC maintainers be opposed to forming a new option (possibly an option
> for --std=) to test for a particular standard, or whatever subset of it
> can currently be checked? I expect someone from the our group would
> provide patches for the tests.
> 
> One of the reasons for asking is that we'd like to remove any barriers
> to adoption of our new standard by GCC; in particular, trying to
> determine if the new standard not being LGPL or similar would be a problem.
> 
> Thanks for any advice you can offer.
> 
> Jim MacArthur
> 

Things like MISRA and CERT-C are not "standards" in the sense of
"language standards", and thus are not appropriate for "--std" options.
 They are coding standards, rather than language standards.  Normal
"MISRA" uses the ISO C90 language standard, MISRA C:2012 uses ISO C99 or
C90, and MISRA C++:2008 uses ISO C++2003.  So you would start with those
languages for the --std= option.

I don't know about CERT-C, but one of the challenges of implementing
MISRA coding standards checking in gcc is that the MISRA documents are
not free.  They are cheap (about $10, I think), but since they are not
free there are likely to be copyright complications.  I think it would
be difficult for gcc to have a warning that rejects non-zero octal
constants with the message "MISRA Rule 7.1: Octal constants shall not be
used", even though it should be fairly straightforward (and highly
desirable) for gcc to have a warning on the use of non-zero octal constants.

I would imagine that the best way to make a MISRA or CERT-C checked
would be as a plugin to gcc.  That would let you be a lot freer about
the development, as it can be done independently from the main gcc code,
and it frees you from the copyright restraints of mainline gcc (you
don't have to assign the copyright to gnu, which I think could be
problematic with wording taken from MISRA documents).  Two likely
starting points here would be the gcc Python plugin, and Melt (which
uses as sort of LISP language for plugins).

Much as I dislike MISRA (whose rules are, IMHO, 50% good, 50% obvious,
and 50% bad), for some uses it is an advantage to be able to check for
MISRA compliance and get the warnings.  So a project to make such
warnings in gcc would be a very nice idea.

mvh.,

David

Re: input address reload issue

[Aurelien Buhrig]

On 06/01/2017 17:06, Jeff Law wrote:
> On 01/06/2017 03:20 AM, Aurelien Buhrig wrote:
>>
 So the insn:
 (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1))

 is transformed into:
 (set (reg:SI 8 a0) (reg:SI 2 r2))
 (set (reg:SI 8 a0) (const_int 1))
 (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0)))
 (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0))

 This "basic" transformation requires two reload regs, but only one is
 given/used/possible from the rl structure (in emit_reload_insns).

 So where does the issue comes from? The need for 2 reload regs, the
 transformation which is too "basic" and could be optimized to use only
 one reload reg, or any wrong/missing reload target hook?
>>> Sounds like you need secondary or intermediate reloads.
>> Do you suggest the secondary reload must implement a scratch reg & md
>> pattern to implement this reload?
> Perhaps.  I don't know enough about your architecture to be 100% sure
> about how all the pieces interact with each other -- reload, and
> secondary reloads in particular are a complex area.  I'm largely going
> on your comment that you need 2 reload registers.
>
> Presumably you don't have an instruction for
> (set (reg) (plus (reg) (const_int)))
>
> Thus you need two scratch reload regs IIUC.  One to hold r2 another to
> hold (const_int 1).  So you'd want to generate
>
> (set (areg1) (reg r2))
> (set (areg2) (const_int 1))
> (set (areg1) (plus (areg1) (areg2)
> (set (r0) (mem (areg1))
>
> Or something along those lines.  If you're going to stick with reload,
> you'll likely want to dig into find_reloads_address and its children
> to see what reloads it generates and why (debug_reload can be helpful
> here). 

Thank you very much Jeff for your help. The best mapping for my target
would be:
(set areg1 r2) (set r0 (mem:QI (areg1 + 1)), and only 1 scratch would be
needed.

In secondary_reload, I can see the pattern (mem:QI (reg+1)) during IRA
pass with reg being a pseudo (ira_cost), but I cannot tranform it since
I do not know in which class the address reg would be reloaded into (or
maybe I can, but I don't know how since reg_renumber is -1 for this pseudo).
And the reload pass does not call my secondary reload with this pattern
mapped onto hw regs, so I cannot transform it.

So I try to add LEGITIMIZE_RELOAD_ADDRESS. I can see the (mem:QI (r2+1))
with hwreg, and so try to push_reload r2 with the "BASE_REG_CLASS".
But it has no effect. Indeed, in push_secondary_reload, the
secondary_reload is called and if NO_REG and CODE_FOR_nothing is
returned, "no reload reg is needed" ... But r2 is a hwreg which does not
belong to BASE_REG_CLASS, can be directly copied to BASE_REG_CLASS and
it does need a reload reg.
So should not push_secondary_reload check for class intersection ? Or
how to perform a reload from a hwreg to a class it does not belong to?

Thanks,
Aurélien

Re: Adoption of C subset standards

[Nathan Sidwell]

On 01/09/2017 08:58 AM, David Brown wrote:


I don't know about CERT-C, but one of the challenges of implementing
MISRA coding standards checking in gcc is that the MISRA documents are
not free.  They are cheap (about $10, I think), but since they are not
free there are likely to be copyright complications.  I think it would
be difficult for gcc to have a warning that rejects non-zero octal
constants with the message "MISRA Rule 7.1: Octal constants shall not be
used", even though it should be fairly straightforward (and highly
desirable) for gcc to have a warning on the use of non-zero octal constants.


Well, there are the effective-c++ warnings that come from Scott Meyers' 
(non-zero-cost) books.  so it must be possible to do something:


@item -Weffc++ @r{(C++ and Objective-C++ only)}
@opindex Weffc++
@opindex Wno-effc++
Warn about violations of the following style guidelines from Scott Meyers'
@cite{Effective C++} series of books:

nathan

--
Nathan Sidwell

Re: Question about inlining and strict_aliasing

[Martin Liška]

On 01/09/2017 02:34 PM, Jan Hubicka wrote:
>> Hello.
>>
>> I've been working on a patch that would cope with target and optimization 
>> (read PerFunction)
>> in a proper way. I came to following test-case (slightly modified 
>> ./gcc/testsuite/gcc.c-torture/execute/alias-1.c):
>>
>> int val;
>>
>> int *ptr = &val;
>> float *ptr2 = &val;
>>
>> static
>> __attribute__((always_inline, optimize ("-fno-strict-aliasing")))
>> typepun ()
>> {
>>   *ptr2=0;
>> }
>>
>> main()
>> {
>>   *ptr=1;
>>   typepun ();
>>   if (*ptr)
>> __builtin_abort ();
>> }
>>
>> $ gcc -O2 /tmp/always-inline.c -fdump-tree-all-details && ./a.out
>> Aborted (core dumped)
>>
>> Problem is that einline does:
>>
>>   Inlining typepun into main (always_inline).
>>Estimating body: typepun/3
>>Known to be false: not inlined
>>size:2 time:2
>> Dropping flag_strict_aliasing on main:4 << here is strict_aliasing drop
>>  Accounting size:2.00, time:2.00 on predicate:(true)
>>
>> However fre1 does not still check for flag_strict_aliasing. Is it bug or not?
>> I did an experimental fix, but I guess there will me multiple places where 
>> the 
>> flag is checked.
> 
> Aha, I think the problem is that once we modify strict aliasing of cfun, we 
> need
> to re-set the global optimization attributes, becuase those are still copies 
> from
> the original declaration.

Good, I prepared patch that does that and works for me. Is it stage3 material? 
I hope it is
as it fixes a miscompilation. Should I create PR for that?

>>
>> Second question:
>> Current ipa-inline.c code contains question sophisticated 
>> check_{match,maybe_up,maybe_down} and
>> it's following by:
>>
>>   /* When user added an attribute to the callee honor it.  */
>>   else if (lookup_attribute ("optimize", DECL_ATTRIBUTES (callee->decl))
>> && opts_for_fn (caller->decl) != opts_for_fn (callee->decl))
>>  {
>>e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
>>inlinable = false;
>>  }
>>
>> I think it's very strict, as when one uses __attribute__((optimize)) with a 
>> param that matches with
>> command line arguments, it will return false. What if we remove the hunk?
> 
> I am not quite sure.  If you have function A with optimization attribute and 
> you inline it to function b
> with same command line parameters, it may enable to inline it into function C 
> where A would not be inlined
> because of the explicit optimization attribute.
> If we relax this check, we will need to copy the optimization attribute from 
> A to B at the time
> we inline into B.

Can you please provide an example for that? As I've been thinking about it, 
both IPA inline and IPA ICF should
handle optimization flags/attributes in very similar manner as it can 
potentially make a divergence for -fcompare-debug

>>
>> Thanks,
>> Martin
> 
>> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
>> index 871fa121fd0..da38e4fab69 100644
>> --- a/gcc/tree-ssa-alias.c
>> +++ b/gcc/tree-ssa-alias.c
>> @@ -986,7 +986,7 @@ ncr_compar (const void *field1_, const void *field2_)
>>  static bool
>>  nonoverlapping_component_refs_p (const_tree x, const_tree y)
>>  {
>> -  if (!flag_strict_aliasing
>> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing
> 
> This should not be necessary. Einline ought to update global opts.
> I suppose when decl modified is cfun one needs to reset current_funcion_decl
> to NULL and then set it again so the global flags changing machinery notices 
> this
> change.

Yep, fixed in the patch
Martin

> 
> Honza
> t
>>|| !x || !y
>>|| TREE_CODE (x) != COMPONENT_REF
>>|| TREE_CODE (y) != COMPONENT_REF)
>> @@ -1167,7 +1167,7 @@ indirect_ref_may_alias_decl_p (tree ref1 
>> ATTRIBUTE_UNUSED, tree base1,
>>  return false;
>>  
>>/* Disambiguations that rely on strict aliasing rules follow.  */
>> -  if (!flag_strict_aliasing || !tbaa_p)
>> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || 
>> !tbaa_p)
>>  return true;
>>  
>>ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
>> @@ -1334,7 +1334,7 @@ indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, 
>> tree base1,
>>  return false;
>>  
>>/* Disambiguations that rely on strict aliasing rules follow.  */
>> -  if (!flag_strict_aliasing || !tbaa_p)
>> +  if (!opts_for_fn (current_function_decl)->x_flag_strict_aliasing || 
>> !tbaa_p)
>>  return true;
>>  
>>ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1));
>> @@ -1508,7 +1508,7 @@ refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool 
>> tbaa_p)
>>  
>>/* First defer to TBAA if possible.  */
>>if (tbaa_p
>> -  && flag_strict_aliasing
>> +  && opts_for_fn (current_function_decl)->x_flag_strict_aliasing
>>&& !alias_sets_conflict_p (ao_ref_alias_set (ref1),
>>   ao_ref_alias_set (ref2)))
>>  return false;
> 

diff --git a/gcc/function.c b/gcc/function.c
index 7fde96adbe3..f625489205b 100644
-

Re: Adoption of C subset standards

[Jonathan Wakely]

On 9 January 2017 at 14:22, Jonathan Wakely wrote:
> On 9 January 2017 at 14:15, Nathan Sidwell wrote:
>> On 01/09/2017 08:58 AM, David Brown wrote:
>>
>>> I don't know about CERT-C, but one of the challenges of implementing
>>> MISRA coding standards checking in gcc is that the MISRA documents are
>>> not free.  They are cheap (about $10, I think), but since they are not
>>> free there are likely to be copyright complications.  I think it would
>>> be difficult for gcc to have a warning that rejects non-zero octal
>>> constants with the message "MISRA Rule 7.1: Octal constants shall not be
>>> used", even though it should be fairly straightforward (and highly
>>> desirable) for gcc to have a warning on the use of non-zero octal
>>> constants.
>>
>>
>> Well, there are the effective-c++ warnings that come from Scott Meyers'
>> (non-zero-cost) books.  so it must be possible to do something:
>>
>> @item -Weffc++ @r{(C++ and Objective-C++ only)}
>> @opindex Weffc++
>> @opindex Wno-effc++
>> Warn about violations of the following style guidelines from Scott Meyers'
>> @cite{Effective C++} series of books:
>
> That warning needs a lot of improvement, or should be deprecated. It
> only warns about the guidelines in the first edition, many of which
> were improved or replaced entirely in later books. Some are completely
> inappropriate for C++11 and later.

Although that's beside the point. I agree that simply referring to
MISRA rules (without quoting chunks of text verbatim) is probably OK.

Re: Adoption of C subset standards

[Jonathan Wakely]

On 9 January 2017 at 14:15, Nathan Sidwell wrote:
> On 01/09/2017 08:58 AM, David Brown wrote:
>
>> I don't know about CERT-C, but one of the challenges of implementing
>> MISRA coding standards checking in gcc is that the MISRA documents are
>> not free.  They are cheap (about $10, I think), but since they are not
>> free there are likely to be copyright complications.  I think it would
>> be difficult for gcc to have a warning that rejects non-zero octal
>> constants with the message "MISRA Rule 7.1: Octal constants shall not be
>> used", even though it should be fairly straightforward (and highly
>> desirable) for gcc to have a warning on the use of non-zero octal
>> constants.
>
>
> Well, there are the effective-c++ warnings that come from Scott Meyers'
> (non-zero-cost) books.  so it must be possible to do something:
>
> @item -Weffc++ @r{(C++ and Objective-C++ only)}
> @opindex Weffc++
> @opindex Wno-effc++
> Warn about violations of the following style guidelines from Scott Meyers'
> @cite{Effective C++} series of books:

That warning needs a lot of improvement, or should be deprecated. It
only warns about the guidelines in the first edition, many of which
were improved or replaced entirely in later books. Some are completely
inappropriate for C++11 and later.

Re: Adoption of C subset standards

[David Brown]

On 09/01/17 15:15, Nathan Sidwell wrote:
> On 01/09/2017 08:58 AM, David Brown wrote:
> 
>> I don't know about CERT-C, but one of the challenges of implementing
>> MISRA coding standards checking in gcc is that the MISRA documents are
>> not free.  They are cheap (about $10, I think), but since they are not
>> free there are likely to be copyright complications.  I think it would
>> be difficult for gcc to have a warning that rejects non-zero octal
>> constants with the message "MISRA Rule 7.1: Octal constants shall not be
>> used", even though it should be fairly straightforward (and highly
>> desirable) for gcc to have a warning on the use of non-zero octal
>> constants.
> 
> Well, there are the effective-c++ warnings that come from Scott Meyers'
> (non-zero-cost) books.  so it must be possible to do something:
> 
> @item -Weffc++ @r{(C++ and Objective-C++ only)}
> @opindex Weffc++
> @opindex Wno-effc++
> Warn about violations of the following style guidelines from Scott Meyers'
> @cite{Effective C++} series of books:
> 
> nathan
> 

I am not an expert in these matters (there are plenty of folks at gnu
who could give much better advice).  But I think there is a difference
between explicitly using some 50+ rule numbers and titles from a
document (and that is what you want with MISRA compliance checking), and
checking for a few general good practice recommendations for C++ that
are discussed in a book.

Regardless of that sort of issue, I think on previous occasions when the
topic of MISRA (or other coding standard) checking came up, there has
been a general opinion from the gcc developers that the compiler itself
is not the best place for this sort of checking - they recommend an
external tool, and don't want the main code base cluttered with such
specific warnings for the dozens of coding standards in common use.

On the other hand, I think it makes sense to use the compiler's parsing
and analysis passes - and for the end user, integrating MISRA checking
with compilation would be very convenient.  I think a plugin is the
"happy medium" here.  gcc developers and users who have no interest in
MISRA will not be bothered by it, while those embedded developers who
/do/ need it would be able to use it as though it were built in to the
compiler.  And I suspect that it would be easier for someone to write a
MISRA checker as a plugin than as an addition to the compiler.  (I have
no experience with either plugin development or gcc development - merely
a small knowledge from what I have read.)

Re: Adoption of C subset standards

[Richard Kenner]

> Regardless of that sort of issue, I think on previous occasions when the
> topic of MISRA (or other coding standard) checking came up, there has
> been a general opinion from the gcc developers that the compiler itself
> is not the best place for this sort of checking - they recommend an
> external tool, and don't want the main code base cluttered with such
> specific warnings for the dozens of coding standards in common use.

Note that there's also a legal issue here: when one has to obtain a
license from MISRA.

Re: input address reload issue

[Jeff Law]

On 01/09/2017 07:02 AM, Aurelien Buhrig wrote:

On 06/01/2017 17:06, Jeff Law wrote:

On 01/06/2017 03:20 AM, Aurelien Buhrig wrote:



So the insn:
(set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1))

is transformed into:
(set (reg:SI 8 a0) (reg:SI 2 r2))
(set (reg:SI 8 a0) (const_int 1))
(set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0)))
(set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0))

This "basic" transformation requires two reload regs, but only one is
given/used/possible from the rl structure (in emit_reload_insns).

So where does the issue comes from? The need for 2 reload regs, the
transformation which is too "basic" and could be optimized to use only
one reload reg, or any wrong/missing reload target hook?

Sounds like you need secondary or intermediate reloads.

Do you suggest the secondary reload must implement a scratch reg & md
pattern to implement this reload?

Perhaps.  I don't know enough about your architecture to be 100% sure
about how all the pieces interact with each other -- reload, and
secondary reloads in particular are a complex area.  I'm largely going
on your comment that you need 2 reload registers.

Presumably you don't have an instruction for
(set (reg) (plus (reg) (const_int)))

Thus you need two scratch reload regs IIUC.  One to hold r2 another to
hold (const_int 1).  So you'd want to generate

(set (areg1) (reg r2))
(set (areg2) (const_int 1))
(set (areg1) (plus (areg1) (areg2)
(set (r0) (mem (areg1))

Or something along those lines.  If you're going to stick with reload,
you'll likely want to dig into find_reloads_address and its children
to see what reloads it generates and why (debug_reload can be helpful
here).


Thank you very much Jeff for your help. The best mapping for my target
would be:
(set areg1 r2) (set r0 (mem:QI (areg1 + 1)), and only 1 scratch would be
needed.
So if you've got reg+d addressing modes, then I'd start by looking at 
your GO_IF_LEGITIMATE_ADDRESS, REG_OK_FOR_*_P, etc.  Reload ought to be 
able to reload r2 into an address register without defining secondary 
reloads.  From what you've described, it's comparable to any target that 
has split address/data registers.


So I try to add LEGITIMIZE_RELOAD_ADDRESS. I can see the (mem:QI (r2+1))
with hwreg, and so try to push_reload r2 with the "BASE_REG_CLASS".
But it has no effect. Indeed, in push_secondary_reload, the
secondary_reload is called and if NO_REG and CODE_FOR_nothing is
returned, "no reload reg is needed" ... But r2 is a hwreg which does not
belong to BASE_REG_CLASS, can be directly copied to BASE_REG_CLASS and
it does need a reload reg.
Never use LEGITIMIZE_RELOAD_ADDRESS to fix a correctness issue.  It is 
strictly a way to improve the generated code.  It's primary purpose is 
to allow improvement of reg+d addresses when the displacement is out of 
range.


Jeff

Re: Adoption of C subset standards

[Paul.Koning]

> On Jan 9, 2017, at 1:28 PM, Richard Kenner  wrote:
> 
>> Regardless of that sort of issue, I think on previous occasions when the
>> topic of MISRA (or other coding standard) checking came up, there has
>> been a general opinion from the gcc developers that the compiler itself
>> is not the best place for this sort of checking - they recommend an
>> external tool, and don't want the main code base cluttered with such
>> specific warnings for the dozens of coding standards in common use.
> 
> Note that there's also a legal issue here: when one has to obtain a
> license from MISRA.

I suspect there are vast quantities of coding guidelines out there, some of 
which may make some sense while others may not.  I don't see a good reason why 
one particular club should have its suggestions embodied in GCC code.

But as for a license, it's hard to see why that might be.  You can't copyright 
rules (only a particular expression of same, and only to the extend that the 
"sweat of the brow" rule doesn't apply).  And it doesn't sound like patentable 
matter either.  That said, if some outfit thinks it can ask for licensing on 
matter of this kind, that in itself is in my mind sufficient to exclude them 
from any consideration.

paul

Re: Adoption of C subset standards

[Richard Kenner]

> But as for a license, it's hard to see why that might be.  You can't
> copyright rules (only a particular expression of same, and only to
> the extend that the "sweat of the brow" rule doesn't apply).  And it
> doesn't sound like patentable matter either.  That said, if some
> outfit thinks it can ask for licensing on matter of this kind, that
> in itself is in my mind sufficient to exclude them from any
> consideration.

The issue is trademark.  When you can use the term "MISRA" to describe
something.  It's my understanding that you can't use the term to
describe something that checks rules without paying the license fee
for the trademark, but this is a complex issue and needs to be 
doublechecked.

Re: LTO remapping/deduction of machine modes of types/decls

[Alexander Monakov]

On Wed, 4 Jan 2017, Richard Biener wrote:
> My suggestion at that time isn't likely working in practice due to the
> limitations Jakub outlines below.  The situation is a bit unfortunate
> but expect to run into more host(!) dependences in the LTO bytecode.
> Yes, while it would be nice to LTO x86_64->arm and ppc64le->arm
> LTO bytecode it very likely isn't going to work.

Yes, I think it's not really practical to seek wide portability of LTO bytecode.
After all, platform specifics get into constant expressions (e.g. 'int p =
sizeof (void *);') and are also observable on the preprocessor level (e.g. via
'#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__').

However the accelerator platform must be compatible with the host platform in
almost all ABI (storage layout?) features such as type sizes and alignments,
endianness, default signedness of char, bitfield layout, and possibly others
(but yet in the other subthread I was arguing that compromising and making
'long double' only partially compatible makes sense).  Thus, portability issue
is much smaller in scope here.

I think it's a bit unfortunate that the discussion really focused on the trouble
with floating-point types.  I'd really appreciate any insight on the other
questions that were raised, such as whether the decl mode should match that
decl's type mode.

For floating types, I believe in the long run it should be possible to tag tree
type nodes with the floating-point type 'kind' such as IEEE binary, IEEE
decimal, accum/fract/sat, or IBM double-double.

For our original goal, I think we'll switch to the other solution I've outlined
in the opening mail, i.e. propagating mode tables at WPA stage and keeping
enough information to know if the section comes from the host or native
compiler.

Thanks.
Alexander

Re: Adoption of C subset standards

[Paul.Koning]

> On Jan 9, 2017, at 1:55 PM, Richard Kenner  wrote:
> 
>> But as for a license, it's hard to see why that might be.  You can't
>> copyright rules (only a particular expression of same, and only to
>> the extend that the "sweat of the brow" rule doesn't apply).  And it
>> doesn't sound like patentable matter either.  That said, if some
>> outfit thinks it can ask for licensing on matter of this kind, that
>> in itself is in my mind sufficient to exclude them from any
>> consideration.
> 
> The issue is trademark.  When you can use the term "MISRA" to describe
> something.  It's my understanding that you can't use the term to
> describe something that checks rules without paying the license fee
> for the trademark, but this is a complex issue and needs to be 
> doublechecked.

I suppose that would be true if you refer to MISRA in the messages.  If you 
don't then you're not using the trademark.

But still, I'm back to my previous comment.  People who try to extract license 
fees for stuff like this should just be rejected.  It's bad enough we have ISO 
doing this; we should not put up with random others trying to do the same.

paul

Re: Adoption of C subset standards

[Richard Kenner]

> I suppose that would be true if you refer to MISRA in the messages.
> If you don't then you're not using the trademark.

The issue isn't the messages. but how you describe what you've done
in, say, documentation or ChangeLog entries.  If you claim, in any
way, that you're checking for "MISRA compatibility", you violate the
trademark.

> But still, I'm back to my previous comment.  People who try to
> extract license fees for stuff like this should just be rejected.
> It's bad enough we have ISO doing this; we should not put up with
> random others trying to do the same.

The politics of IP are off-topic here, but I believe that it's not just a
license fee, but that there's also some (mild, but nonzero) verification
that you are actually doing checking against those rules.

Re: Adoption of C subset standards

[David Brown]

On 09/01/17 19:43, paul.kon...@dell.com wrote:



On Jan 9, 2017, at 1:28 PM, Richard Kenner
 wrote:


Regardless of that sort of issue, I think on previous occasions
when the topic of MISRA (or other coding standard) checking came
up, there has been a general opinion from the gcc developers that
the compiler itself is not the best place for this sort of
checking - they recommend an external tool, and don't want the
main code base cluttered with such specific warnings for the
dozens of coding standards in common use.


Note that there's also a legal issue here: when one has to obtain
a license from MISRA.


I found a reference to this in MISRA's forums:



The post and reply are from 4 years ago, but I expect the situation is 
the same now as then.  Basically, MISRA are quite happy for any tools to 
support checking of the rules, no matter what the license of the tools, 
and there is no certification or checking for conformance.  However, if 
you are going to include the rule texts, you need that part of the 
checker to be under a "commercial license agreement that contain[s] the 
expected restrictions on reverse engineering or extracting of 
information from the software".  The say it's fine for a pure open 
source checker to refer to the checks by MISRA rule number, but not by 
rule text.  It looks like no license is needed from MISRA to do this. 
(Obviously the people writing the checker will need a copy of the MISRA 
standards themselves, but at £10 it is not a deal breaker.)




I suspect there are vast quantities of coding guidelines out there,
some of which may make some sense while others may not.  I don't see
a good reason why one particular club should have its suggestions
embodied in GCC code.


I don't want to sound rude, but it would seem you are not aware of the 
special position MISRA holds.  In safety critical embedded development, 
especially in Europe, following MISRA standards can easy be a 
non-negotiable requirement for development.  And because gcc does not 
support checking, and any third-party checking tool costs at least as 
much as a compiler /with/ checking (such as Keil, IAR, GHS), this 
basically rules out gcc as an option for this sort of development.  For 
those in these industries, it is a real shame - not because gcc is cheap 
or free while IAR and GHS cost an arm and a leg, but because gcc is a 
much better compiler.


No other coding standard or guidelines has the same position as MISRA - 
it is /not/ like using Google Coding Standards or the JSF standards. 
(Another difference is that those are better standards - MISRA has a 
number of points that are /very/ questionable.)


However, for most gcc users, MISRA checking is useless or worse than 
useless (because it encourages a number of bad coding practices), which 
is why it makes sense for a checker to be a plugin and not an integral 
part of gcc.




But as for a license, it's hard to see why that might be.  You can't
copyright rules (only a particular expression of same, and only to
the extend that the "sweat of the brow" rule doesn't apply).


You can copyright the text of the rules, and trademark the name MISRA.


 And it
doesn't sound like patentable matter either.  That said, if some
outfit thinks it can ask for licensing on matter of this kind, that
in itself is in my mind sufficient to exclude them from any
consideration.

paul

Re: Adoption of C subset standards

[David Brown]

On 09/01/17 20:11, Richard Kenner wrote:

I suppose that would be true if you refer to MISRA in the messages.
If you don't then you're not using the trademark.


The issue isn't the messages. but how you describe what you've done
in, say, documentation or ChangeLog entries.  If you claim, in any
way, that you're checking for "MISRA compatibility", you violate the
trademark.


It does not look like that is a problem for MISRA, from what I saw on 
their forum.  But it would make sense to check on the MISRA forums 
before making a checker.





But still, I'm back to my previous comment.  People who try to
extract license fees for stuff like this should just be rejected.
It's bad enough we have ISO doing this; we should not put up with
random others trying to do the same.


The politics of IP are off-topic here, but I believe that it's not just a
license fee, but that there's also some (mild, but nonzero) verification
that you are actually doing checking against those rules.



That also does not appear to be a problem - MISRA does not endorse or 
recommend any particular tools, and say it is up to the user to check 
that they are appropriate for the job.  But again, it would make sense 
to check.

Re: Adoption of C subset standards

[Paul.Koning]

> On Jan 9, 2017, at 4:08 PM, David Brown  wrote:
> ...
> I found a reference to this in MISRA's forums:
> 
> 
> 
> The post and reply are from 4 years ago, but I expect the situation is the 
> same now as then.  Basically, MISRA are quite happy for any tools to support 
> checking of the rules, no matter what the license of the tools, and there is 
> no certification or checking for conformance.  However, if you are going to 
> include the rule texts, you need that part of the checker to be under a 
> "commercial license agreement that contain[s] the expected restrictions on 
> reverse engineering or extracting of information from the software".  The say 
> it's fine for a pure open source checker to refer to the checks by MISRA rule 
> number, but not by rule text.  It looks like no license is needed from MISRA 
> to do this. 

I'd say that messages of the form "you violated rule number 42" are 
unacceptable, since they have no intellegible meaning.  And the MISRA reply you 
pointed to says specifically that GCC couldn't get a license to use the 
messages because it's under GPL.  (The "additional module" exception mentioned 
afterwards seems to be based on a misunderstanding of the GPL "derived work" 
machinery.)

It looks like MISRA should adjust its rules if it wants to support open source.

paul

Re: Adoption of C subset standards

[Richard Kenner]

> It looks like MISRA should adjust its rules if it wants to support
> open source.

I can think of no reason why MISRA would want to do that given their
goals.  Can you?