Re: Status of C++11 support

[Dennis Luehring]

Overview:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

Am 09.12.2019 um 04:17 schrieb Nicholas Krause:

Greetings,

I was wondering what the current status of being able to use C++11 is
without
the gcc project. Seems it will be much easier to implement  basic
spinlocks with
the  C++11 memory model than without.

Thanks,
Nick

Re: PPC64 libmvec implementation of sincos

[Richard Biener]

On Sun, Dec 8, 2019 at 10:40 PM GT  wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, December 6, 2019 12:43 PM, Richard Biener 
> richard.guent...@gmail.com wrote:
>
> ...
> ...
>
> > > Are we certain the change we want is to support _Complex double so that
> > > cexpi is auto-vectorized?
> > > Looking at the resulting executable of the code with sincos in the
> > > loop, the only function called
> > > is sincos. Not builtin_cexpi or any variant of cexpi. File
> > > gcc/builtins.c expands calls to builtin_cexpi
> > > to sincos! What is gained by the compiler going through the
> > > transformations sincos -> builtin_cexpi ->
> > > sincos?
> >
> > Yes, we want to support vectorizing cexpi because that is what the compiler 
> > will lower sincos to. The sincos API is painful to deal with due to the 
> > data dependences it introduces. Now, the vectorizer can of course emit 
> > calls to a vectorized sincos it just needs to be able to deal with cexpi 
> > input IL.
> >
> > Richard.
>
> I'm modifying the code trying to get complex double accepted as a valid type 
> by the vectorizer.
> This is the first time I'm dealing with GCC source so I ask for some patience.
>
> Function mode_for_vector in gcc/stor-layout.c requires a new else-if for 
> complex double. I cannot
> seem to find a header file where MIN_MODE_VECTOR_FLOAT and similar macros are 
> defined. I expect
> a new MIN_MODE_COMPLEX_VECTOR_FLOAT to be defined in the same file as the 
> existing similar macros.
> How do I go about making this change?

You don't want to do it this way but map _Complex double to a vector
of 2 * n doubles instead.
Look into get_related_vectype_for_scalar_type where it alreday has
code to "change" the
scalar type into something that fits what we allow for vectors.

Richard.

> Thanks.
> Bert.

Re: Possible Bugs in cgraphunit.c

[Martin Liška]

On 12/5/19 5:08 PM, Nicholas Krause wrote:



On 12/5/19 7:08 AM, Martin Liška wrote:

On 12/5/19 9:00 AM, Nicholas Krause wrote:

Greetings,
Seems that the extend_trucks return values are not returned when called in both,
cnode::assemble_thunks_and_aliases and cnode::create_wrapper. I'm not sure
if this is a set of edge case bugs or there was a reason for this. Seems not as 
its
checked in the third function caller in the file, cgraph_node::analyze.


Hello.

You are right that the return value of expand_thunk is not checked (except one 
place).
The code is quite old, so I guess it's not causing issues.

Martin


Indeed or the edge cases are almost never hit or not at all.


There is one usage of the return value.


So the question is should
we just change the function to return void as its always successful or fix up 
the callers?


I would leave it as is.
Martin



Nick


Not sure if my assumptions are correct so I'm asking if there isn't another 
reason
for this as the code seems to have at least directly no reason for it,

Nick

How to build gcc with address sanitizer?

[Qing Zhao]

Hello,

When using gcc8.2.1 to build one application, it’s out of memory during “cc1”, 
We suspect that there are some memory leak problem in “cc1”, therefore tried to 
build
Gcc with address sanitizer in order to detect the memory leak during 
compilation. 

However, it took me a lot of time in order to build the gcc (or just “cc1”) 
with address sanitizer. Still cannot do this successfully till now. 

Did anyone do this before? Any documentation on how to do this?

Thanks a lot for any help.

Qing

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 3:16 AM, Dennis Luehring wrote:

Overview:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not for other
projects using gcc.
Nick


Am 09.12.2019 um 04:17 schrieb Nicholas Krause:

Greetings,

I was wondering what the current status of being able to use C++11 is
without
the gcc project. Seems it will be much easier to implement basic
spinlocks with
the  C++11 memory model than without.

Thanks,
Nick

Re: PPC64 libmvec implementation of sincos

[GT]

‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener richard.guent...@gmail.com 
wrote:

> > I'm modifying the code trying to get complex double accepted as a valid 
> > type by the vectorizer.
> > This is the first time I'm dealing with GCC source so I ask for some 
> > patience.
> > Function mode_for_vector in gcc/stor-layout.c requires a new else-if for 
> > complex double. I cannot
> > seem to find a header file where MIN_MODE_VECTOR_FLOAT and similar macros 
> > are defined. I expect
> > a new MIN_MODE_COMPLEX_VECTOR_FLOAT to be defined in the same file as the 
> > existing similar macros.
> > How do I go about making this change?
>
> You don't want to do it this way but map _Complex double to a vector
> of 2 * n doubles instead.
> Look into get_related_vectype_for_scalar_type where it alreday has
> code to "change" the
> scalar type into something that fits what we allow for vectors.
>

Function get_related_vectype_for_scalar_type doesn't exist. There is one named
get_vectype_for_scalar_type, which in turn calls 
get_vectype_for_scalar_type_and_size. In that
last function I already have 2 changes to prevent NULL_TREE being returned for 
_Complex double.

1.  In the first if statement of the function, added new condition 
!is_complex_float_mode (...),
with arguments identical to those of the existing !is_int_mode and 
!is_float_mode conditions.

2.  In the 2nd if statement, the else-if has a new condition 
!COMPLEX_FLOAT_TYPE_P (scalar_type)

After those changes, NULL_TREE is returned by a clause of the if statement 
whose first condition
is if (known_eq (size, 0U)). The 2nd part of the else-if returns true for 
!mode_for_vector (...).

Unless the correct path should involve a call similar to 
build_nonstandard_integer_type in the
2nd if statement, I still end up requiring the change to mode_for_vector as 
in my last post.

Bert.

Re: Status of C++11 support

[Andrew Haley]

On 12/9/19 5:03 PM, Nicholas Krause wrote:
>> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> I'm asking of what support exists in the gcc codebase itself not for other
> projects using gcc.

That is what you got.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Fri, 6 Dec 2019, Eric S. Raymond wrote:

> Reposurgeon has been used for several major conversions, including groff 
> and Emacs.  I don't mean to be nasty to Maxim, but I have not yet seen 
> *anybody* who thought they could get the job done with ad-hoc scripts 
> turn out to be correct.  Unfortunately, the costs of failure are often 
> well-hidden problems in the converted history that people trip over 
> months and years later.

I think the ad hoc script is the risk factor here as much as the fact that 
the ad hoc script makes limited use of git-svn.

For any conversion we're clearly going to need to run various validation 
(comparing properties of the converted repository, such as contents at 
branch tips, with expected values of those properties based on the SVN 
repository) and fix issues shown up by that validation.  reposurgeon has 
its own tools for such validation; I also intend to write some validation 
scripts myself.  And clearly we need to fix issues shown up by such 
validation - that's what various recent reposurgeon issues Richard and I 
have reported are about, fixing the most obvious issues that show up, 
which in turn will enable running more detailed validation.

The main risks are about issues that are less obvious in validation and so 
don't get fixed in that process.  There, if you're using an ad hoc script, 
the risks are essentially unknown.  But using a known conversion tool with 
an extensive testsuite, such as reposurgeon, gives confidence based on 
reposurgeon passing its own testsuite (once the SVN dump reader rewrite 
does so) that a wide range of potential conversion bugs, that might appear 
without showing up in the kinds of validation people try, are less likely 
because of all the regression tests for conversion issues seen in past 
conversions.  When using an ad hoc script specific to one conversion you 
lose that confidence that comes from a conversion tool having been used in 
previous conversions and having tests to ensure bugs found in those 
conversions don't come back.

I think we should fix whatever the remaining relevant bugs are in 
reposurgeon and do the conversion with reposurgeon being used to read and 
convert the SVN history and do any desired surgical operations on it.

Ad hoc scripts identifying specific proposed local changes to the 
repository content, such as the proposed commit message improvements from 
Richard or my branch parent fixes, to be performed with reposurgeon, seem 
a lot safer than ad hoc code doing the conversion itself.  And for 
validation, the more validation scripts people come up with the better.  
If anyone has or wishes to write custom scripts to analyze the SVN 
repository branch structure and turn that into verifiable assertions about 
what a git conversion should look like, rather than into directly 
generating a git repository or doing surgery on history, that helps us 
check a reposurgeon-converted repository in areas that might be 
problematic - and in that case it's OK for the custom script to have 
unknown bugs because issues it shows up are just pointing out places where 
the converted repository needs checking more carefully to decide whether 
there is a conversion bug or not.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Status of C++11 support

[Paul Smith]

On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote:
> On 12/9/19 5:03 PM, Nicholas Krause wrote:
> > > https://gcc.gnu.org/projects/cxx-status.html#cxx11
> > 
> > I'm asking of what support exists in the gcc codebase itself not
> > for other projects using gcc.
> 
> That is what you got.

IIUC Nicholas is not asking what language features GCC _can compile_. 
He's asking which language version the compiler itself is _written in_.

If he were to write a new GCC feature, can he write it in C++11?

I'm pretty sure the link above shows the former, not the latter. 
Unless you're trying to imply, indirectly, that this is the language
GCC is written in as well as what it can compile.

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 1:09 PM, Andrew Haley wrote:

On 12/9/19 5:03 PM, Nicholas Krause wrote:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not for other
projects using gcc.

That is what you got.



No its not  as its just talking about support for other projects using 
gcc. I'm asking

about the internal codebase itself which was written using C++03. That's my
point not support for other things using it but internal to gcc source 
code itself

which was in the works a few weeks ago.

Nick

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 1:31 PM, Paul Smith wrote:

On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote:

On 12/9/19 5:03 PM, Nicholas Krause wrote:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not
for other projects using gcc.

That is what you got.

IIUC Nicholas is not asking what language features GCC _can compile_.
He's asking which language version the compiler itself is _written in_.

If he were to write a new GCC feature, can he write it in C++11?

I'm pretty sure the link above shows the former, not the latter.
Unless you're trying to imply, indirectly, that this is the language
GCC is written in as well as what it can compile.

Exactly as C++11 has a memory model which is useful for multi-threading
gcc alongside other things.

Sorry for the confusion,
Nick

Re: Proposal for the transition timetable for the move to GIT

[Bernd Schmidt]

On 12/9/19 7:19 PM, Joseph Myers wrote:


For any conversion we're clearly going to need to run various validation
(comparing properties of the converted repository, such as contents at
branch tips, with expected values of those properties based on the SVN
repository) and fix issues shown up by that validation.  reposurgeon has
its own tools for such validation; I also intend to write some validation
scripts myself.


Would it be feasible to require that both conversions produce the same 
output repository to some degree? Can we just look at release tags and 
require that they have the same hash in both conversions, or are there 
good reasons why the two would produce different outputs?




Bernd

Re: Status of C++11 support

[Jason Merrill]

>From the earlier email thread, I think the plan is to switch to C++11 for
GCC 11.

Jason


On Mon, Dec 9, 2019 at 1:43 PM Nicholas Krause  wrote:

>
>
> On 12/9/19 1:31 PM, Paul Smith wrote:
> > On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote:
> >> On 12/9/19 5:03 PM, Nicholas Krause wrote:
>  https://gcc.gnu.org/projects/cxx-status.html#cxx11
> >>> I'm asking of what support exists in the gcc codebase itself not
> >>> for other projects using gcc.
> >> That is what you got.
> > IIUC Nicholas is not asking what language features GCC _can compile_.
> > He's asking which language version the compiler itself is _written in_.
> >
> > If he were to write a new GCC feature, can he write it in C++11?
> >
> > I'm pretty sure the link above shows the former, not the latter.
> > Unless you're trying to imply, indirectly, that this is the language
> > GCC is written in as well as what it can compile.
> Exactly as C++11 has a memory model which is useful for multi-threading
> gcc alongside other things.
>
> Sorry for the confusion,
> Nick
>
>

Re: Proposal for the transition timetable for the move to GIT

[Eric S. Raymond]

Joseph Myers :
> I think we should fix whatever the remaining relevant bugs are in 
> reposurgeon and do the conversion with reposurgeon being used to read and 
> convert the SVN history and do any desired surgical operations on it.

On behalf of the reposurgeon crew - Julien Rivaud, Daniel Brooks, and myself -
we thank you for that expression of confidence.

We'll do our damnedest to deliver rapidly.  We welcome oversight and
discussion at #reposurgeon on freenode, because we're just the mechanics.
You guys have to make the policy decisions.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Mon, 9 Dec 2019, Bernd Schmidt wrote:

> On 12/9/19 7:19 PM, Joseph Myers wrote:
> > 
> > For any conversion we're clearly going to need to run various validation
> > (comparing properties of the converted repository, such as contents at
> > branch tips, with expected values of those properties based on the SVN
> > repository) and fix issues shown up by that validation.  reposurgeon has
> > its own tools for such validation; I also intend to write some validation
> > scripts myself.
> 
> Would it be feasible to require that both conversions produce the same output
> repository to some degree? Can we just look at release tags and require that
> they have the same hash in both conversions, or are there good reasons why the
> two would produce different outputs?

The same hashes are not practical.  There are several areas where two 
perfectly correct conversions are still expected to have different 
contents because of subjective decisions and heuristics involved in the 
conversion.

If some alternative heuristic is found to be clearly better than an 
existing one in reposurgeon, so that it would be better for any project 
converting with reposurgeon, or if some preference in the GCC case can 
readily be represented as a configuration option to choose between 
different approaches, it makes sense to implement the improvements in 
reposurgeon so that any project with similar issues can benefit.  For 
example, see Richard's suggestions in reposurgeon issue 174 of two 
possible improvements to ChangeLog handling: disregarding ChangeLog data 
if a commit adds multiple ChangeLog entries by different authors, and 
specifing a wildcard to allow ChangeLog processing on ChangeLog* files to 
cover ChangeLog..  GCC is hardly the last project converting from 
SVN to git, so we can benefit from the experiences of past conversions, 
and help contribute to having useful features available for future 
conversions.

Here are some cases for differences between two correct conversions:

* Tree contents should mostly be identical at any given commit, but 
reposurgeon deliberately produces a .gitignore with contents based on 
svn:ignore if the SVN tree contents don't have a .gitignore (we use 
--user-ignores to prefer the .gitignore file in SVN if it exists), and 
removes any .cvsignore file.

* The first parent of a commit should typically be the same between 
conversions, but (a) might be corrected in some way for cvs2svn issues, 
(b) might skip SVN commits that would translate into empty git commits, 
depending on the choices made for handling of such commits.

* Cases that give rise to no tree changes in a commit (which thus might 
not become a git commit at all depending on the choices made and whether 
they also don't change any merge information properties) include (a) 
branch or tag creation as an exact copy of some revision of some branch, 
(b) branch recreation as a copy, e.g. when trunk was deleted accidentally, 
(c) commits that in SVN only add or remove empty directories, as git does 
not store empty directories, (d) commits that in SVN just remove some file 
or directory and replace it with a copy from some revision of some branch 
that happens to have identical contents to the file or directory removed 
(yes, we do have commits like that in GCC SVN).

* Subsequent parents of a commit based on merge info handling may well 
have subjective differences between correct conversions.

* Commit messages might differ, both because of heuristics to improve 
them, like Richard's work on that, and because of different choices for 
how to represent the SVN revision number information in commit messages.

* Author and committer identifications, and commit timestamps (especially 
timezones, something git has, SVN doesn't and reposurgeon has a per-author 
map for) may vary because of different heuristics or author maps used, 
especially when there is no ChangeLog entry for a commit or the ChangeLog 
entry is in some way malformed or the commit adds ChangeLog entries for 
multiple changes with different authors.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Proposal for the transition timetable for the move to GIT

[Eric S. Raymond]

Bernd Schmidt :
> On 12/9/19 7:19 PM, Joseph Myers wrote:
> > 
> > For any conversion we're clearly going to need to run various validation
> > (comparing properties of the converted repository, such as contents at
> > branch tips, with expected values of those properties based on the SVN
> > repository) and fix issues shown up by that validation.  reposurgeon has
> > its own tools for such validation; I also intend to write some validation
> > scripts myself.
> 
> Would it be feasible to require that both conversions produce the same
> output repository to some degree? Can we just look at release tags and
> require that they have the same hash in both conversions, or are there good
> reasons why the two would produce different outputs?

There are a couple of areas that could produce divergences.

One is the part of the history before SVN was adopted. There's a lot of 
weird junk back there, artifacts from the cvs2svn conversion, that can produce
issues like fundamntal uncertainty about where a child branch should actually be
rooted on its parent.  Reposurgeon makes choices that are a-priori reasonable
in cases of doubt, but there are edge cases where a different conversion 
pipeline
could make different ones.

Another is how to translate tags. I don't know what Maxim's scripts do, but 
under reposurgeon a copy commit can have one of two dispositions:

(1) Become a lightweight tag (git reference) if the tag comment looks like 
it was autogenerated and carries no real information.

(2) Become a git annotated tag if we want to preserve the tag metadata (comment,
date stamp)

There's room for a certain amount of artistic license here.

Most conversions have few enough disputable cases that the differences between
renderings can be reviewed by eyeball. I'm not going to bet that will be true
of this one.  At the scale of this conversion, any form of comparative auditing
is pretty hopeless.  You get your assurance, if you get it, from believing
the correctness of the conversion tool.

Which is a major reason that reposurgeon has a *large* test suite. 98
general operations tests, 55 Subversion test dumps including a rogue's
gallery of metadata perversions gathered from pervious conversions,
and a cloud of surrounding auxiliary checks.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Questions about IPA/clones and new LTO pass

[Erick Ochoa]

Hello,

this is an update on the LTO pass we've been working on. The optimization is
called ipa-initcall-cp because it propagates constant values written to
variables with static lifetimes (such as ones initialized in initialization
functions).

This patch can be applied to:
commit 3cce71b23f6ed221b4335b600e718d79903cc83d
Date:   Wed Dec 4 20:04:10 2019 +
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278975
138bc75d-0d04-0410-961f-82ee72b054a4

This patch can now successfully compile all benchmarks on the SPEC CPU2017
benchmarking suite. ~12 of the benchmarks have variables that can be
eliminated with this transformation. I am pasting the patch at the
bottom of the e-mail. I'll be working on adding some of the test cases onto
gcc's testing suite.

In my previous e-mail I asked some questions. Some of them still remain,
others I have answered:

> Question #1: Can someone please tell me what would be the best kind of clones
> to use in this use case?

I think that the only API which makes sense here is
create_version_clone_with_body because we want to modify the body of the
clones.

> Question #2: I found out that clones produced with
> create_clone_version_with_body are not themselves versionable. What is the
> reason behind this?

Still not sure why this is the case.

> Question #3: I have added a flag to cgraph_nodes to skip ipa-cp. This flag is
> true for the original functions which have been removed from the call graph.
> If this flag is removed, then cgraph_nodes removed from the call graph will
> trigger an assertion in ipa-cp (ipa-cp.c:1195). I would like to not have to
> add this flag to cgraph_node but I am not sure what to do.

Still not sure how to remove this graph. Ideally, ipa-cp would not
trigger that assertion because it shouldn't try to propagate constants
on cgraph_nodes that are not connected to the graph any more.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6b857bd..fb4ba09 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1370,6 +1370,7 @@ OBJS = \
internal-fn.o \
ipa-cp.o \
ipa-sra.o \
+   ipa-initcall-cp.o \
ipa-devirt.o \
ipa-fnsummary.o \
ipa-polymorphic-call.o \
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 7288440..0d56149 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -288,6 +288,7 @@ symbol_table::create_empty (void)
   node->type = SYMTAB_FUNCTION;
   node->frequency = NODE_FREQUENCY_NORMAL;
   node->count_materialization_scale = REG_BR_PROB_BASE;
+  node->skip_ipa_cp = false;
   cgraph_count++;
 
   return node;
@@ -3548,6 +3549,7 @@ cgraph_node::get_untransformed_body (void)
   name = lto_get_decl_name_mapping (file_data, name);
   struct lto_in_decl_state *decl_state
 = lto_get_function_in_decl_state (file_data, decl);
+  gcc_assert (decl_state != NULL);
 
   cgraph_node *origin = this;
   while (origin->clone_of)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 9c086fe..806ed56 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -901,6 +901,8 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public 
symtab_node
 {
   friend class symbol_table;
 
+  bool skip_ipa_cp;
+
   /* Remove the node from cgraph and all inline clones inlined into it.
  Skip however removal of FORBIDDEN_NODE and return true if it needs to be
  removed.  This allows to call the function from outer loop walking clone
diff --git a/gcc/common.opt b/gcc/common.opt
index 404b6aa..00c86dc 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3344,4 +3344,10 @@ fipa-ra
 Common Report Var(flag_ipa_ra) Optimization
 Use caller save register across calls if possible.
 
+finitcall-cp
+Common Report Var(flag_initcall_cp) TBD.
+
+finitcall-cp-dryrun
+Common Report Var(flag_initcall_cp_dryrun) TBD.
+
 ; This comment is to ensure we retain the blank line above.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 693c7a2..4169dfb 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1187,7 +1187,7 @@ initialize_node_lattices (struct cgraph_node *node)
 
   gcc_checking_assert (node->has_gimple_body_p ());
 
-  if (!ipa_get_param_count (info))
+  if (!ipa_get_param_count (info) || node->skip_ipa_cp)
 disable = true;
   else if (node->local)
 {
diff --git a/gcc/ipa-initcall-cp.c b/gcc/ipa-initcall-cp.c
new file mode 100644
index 000..264bf38
--- /dev/null
+++ b/gcc/ipa-initcall-cp.c
@@ -0,0 +1,1467 @@
+/* Initcall constant propagation pass.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "tree-eh.h"
+#include "gimple.h"
+#include "gimple-expr.h"
+#include "gimple-iterator.h"
+#include "predict.h"
+#include "alloc-pool.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "diagnostic.h"
+#include "fold-const.h"
+#include "gimple-fold.h"
+#include "symbol-summary.h"
+#include "tree-vrp.h"
+#include "ipa-prop.h"
+#include "tree-pretty-print.h"
+#include "tree-inline.h"
+#include "ipa-fnsummary.h"
+#include "ipa-utils.h"
+#include "tree-ssa-ccp.h"
+#include

Usage of C11 Annex K Bounds-checking interfaces on GCC

[li zi]

Hi All,
We are using gcc in our projects and we found some of the C standard functions 
(like memcpy, strcpy) used in gcc may induce security vulnerablities like 
buffer overflow. Currently we have not found any instances which causes such 
issues.
But we feel better to change these calls to Cll Annex K Bounds-checking 
interfaces like memcpy_s, strcpy_s etc. By defining a secure calls method (list 
of func pointers) and allowing application to register the method. I understand 
that this affects performance because of return value check added for _s 
calls, but this will relieve overflow kind of issues from code. And also 
currently using bounds-checking interfaces is a general industry practice.
Please share your opinion on it, and if any discussion happened in community to 
do some changes in future.

Thanks.

获取 Outlook for Android

Usage of C11 Annex K Bounds-checking interfaces on GCC

[li zi]

Hi All,
We are using gcc in our projects and we found some of the C standard functions 
(like memcpy, strcpy) used in gcc may induce security vulnerablities like 
buffer overflow. Currently we have not found any instances which causes such 
issues.
But we feel better to change these calls to Cll Annex K Bounds-checking 
interfaces like memcpy_s, strcpy_s etc. By defining a secure calls method (list 
of func pointers) and allowing application to register the method. I understand 
that this affects performance because of return value check added for _s 
calls, but this will relieve overflow kind of issues from code. And also 
currently using bounds-checking interfaces is a general industry practice.
Please share your opinion on it, and if any discussion happened in community to 
do some changes in future.

Thanks.
li

Re: Usage of C11 Annex K Bounds-checking interfaces on GCC

[Andrew Pinski]

On Mon, Dec 9, 2019 at 10:14 PM li zi  wrote:
>
> Hi All,
> We are using gcc in our projects and we found some of the C standard 
> functions (like memcpy, strcpy) used in gcc may induce security 
> vulnerablities like buffer overflow. Currently we have not found any 
> instances which causes such issues.

Are you using GCC as a compiler or the sources of GCC to do something
else?  If you are using it as a compiler, GCC does NOT provide the
libc functions, another project (e.g. glibc) provides those.

> But we feel better to change these calls to Cll Annex K Bounds-checking 
> interfaces like memcpy_s, strcpy_s etc. By defining a secure calls method 
> (list of func pointers) and allowing application to register the method. I 
> understand that this affects performance because of return value check added 
> for _s calls, but this will relieve overflow kind of issues from code. 
> And also currently using bounds-checking interfaces is a general industry 
> practice.
> Please share your opinion on it, and if any discussion happened in community 
> to do some changes in future.

Really the _s functions are not so good and right now are optional
part of the C standard and not even implemented by glibc.  Plus they
not so useful and there are other methods of producing similar code
without them.

Thanks,
Andrew

>
> Thanks.
> li
>
>