How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
Hi, I find it difficult to locate the information regarding the version of the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could anyone suggest me a location where I can find this information. My question is due to some of the run time flags defined in ASAN is not recognized in GCC based binary (i.e. GCC 4.9.3). e.g. ASAN_OPTIONS=help=1:halt_on_error=0 Also what is the GCC policy behind updating LLVM sanitizers to their latest version? Rgds, Gayan
Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
Hi. On 31/03/16 12:52, Gayan Pathirage wrote: Hi, I find it difficult to locate the information regarding the version of the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could anyone suggest me a location where I can find this information. This is indeed difficult. AFAIK, there isn't any mapping between LLVM and GCC ASan releases, we just merge sanitizer library from upstream to GCC source tree from time to time. GCC wiki doesn't have a dedicated page for AddressSanitizer, so I suppose that the most appropriate method for discovering such an information is just looking into ASan source code. My question is due to some of the run time flags defined in ASAN is not recognized in GCC based binary (i.e. GCC 4.9.3). e.g. ASAN_OPTIONS=help=1:halt_on_error=0 ASAN_OPTIONS=help=1 was introduced in GCC 5 and ASAN_OPTIONS=halt_on_error will be available in GCC 6. Also what is the GCC policy behind updating LLVM sanitizers to their latest version? As I mentioned above, we merge sanitizer library from upstream to GCC source tree from time to time during the active development stage (stage 1, see https://gcc.gnu.org/develop.html). -Maxim Rgds, Gayan
[ipa-comdat] put symbol in new comdat group if it's referenced from multiple comdat groups
Hi,
I was trying to address first TODO from ipa-comdats.c (attached patch)
TODO: When symbol is used only by comdat symbols, but from different groups,
it would make sense to produce a new comdat group for it with anonymous name.
The patch introduces new lattice value ANON "between" COMDAT and BOTTOM values.
The meet operation is rewritten in merge_comdat_group().
Does the approach look reasonable ?
For comdat-1.C (attached) q is referenced from both i1 and i2
and hence is put in it's own comdat-section.
I suppose that's the expected result ?
However it fails for comdat-2.C with the error below.
error: comdat-local function called by int i1() outside its comdat
However in case of comdat-1.C, i1() calls q() which is also placed
in another comdat group but doesn't give error for that case.
It also works if r() is referenced from another comdat group
and not just from q (comdat-3.C).
I am not able to understand why the error occurs for comdat-2.C.
Could someone please have a look at it ?
Thanks!
Assembling functions:
comdat-2.C: At global scope:
comdat-2.C:33:15: error: comdat-local function called by int i2()
outside its comdat
int (*f2)()=i2;
^
comdat-2.C:33:15: error: comdat-local function called by int i1()
outside its comdat
_ZL1qv/1 (int q()) @0x7fe19ccde170
Type: function definition analyzed
Visibility: prevailing_def_ironly comdat_group:q
Same comdat group as: _ZL1rv/0
References:
Referring:
Availability: local
First run: 0
Function flags: body local
Called by: _Z2i2v/3 (1.00 per call) (can throw external) _Z2i1v/2
(1.00 per call) (can throw external)
Calls: _ZL1rv/0 (1.00 per call) (can throw external) _Z6printfPKcz/6
(1.00 per call) (can throw external)
comdat-2.C:33:15: internal compiler error: verify_cgraph_node failed
0x936083 cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3233
0x92b6df symtab_node::verify()
../../gcc/gcc/symtab.c:1177
0x92b7cf symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1197
0x93e736 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:602
0x93e736 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2431
0x940a57 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2538
0x940a57 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2564
Thanks,
Prathamesh
diff --git a/gcc/ipa-comdats.c b/gcc/ipa-comdats.c
index 6e0f762..999bed2 100644
--- a/gcc/ipa-comdats.c
+++ b/gcc/ipa-comdats.c
@@ -56,6 +56,68 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h"
#include "cgraph.h"
+
+static void
+set_anon (tree& newgroup, symtab_node *symbol,
+ hash_set& anon_set,
+ hash_map& comdat_head_map)
+{
+ newgroup = DECL_NAME (symbol->decl);
+ anon_set.add (newgroup);
+ comdat_head_map.put (newgroup, symbol);
+ symbol->set_comdat_group (newgroup);
+ fprintf (stderr, "newgroup goes to anon: %s\n", IDENTIFIER_POINTER
(newgroup));
+}
+
+static void
+merge_comdat_group (tree& newgroup, tree *val2, symtab_node *symbol,
+ hash_set& anon_set,
+ hash_map& comdat_head_map)
+{
+ /* *val2 is TOP. */
+ if (val2 == NULL || *val2 == NULL)
+return;
+
+ /* *val2 is BOTTOM. */
+ if (*val2 == error_mark_node)
+{
+ newgroup = error_mark_node;
+ return;
+}
+
+ /* *val2 is ANON. */
+ else if (anon_set.contains (*val2))
+{
+ /* ANON meet TOP == ANON. */
+ if (newgroup == NULL)
+ newgroup = *val2;
+ /* ANON1 meet ANON2 == ANON2. */
+ else if (anon_set.contains (newgroup))
+ ;
+ /* ANON meet COMDAT == ANON2. */
+ else
+ set_anon (newgroup, symbol, anon_set, comdat_head_map);
+}
+
+ /* *val2 is COMDAT. */
+ else
+{
+ /* COMDAT meet TOP == COMDAT. */
+ if (newgroup == NULL)
+ {
+ newgroup = *val2;
+ return;
+ }
+ /* COMDAT1 meet COMDAT2 == ANON. */
+ else if (*val2 != newgroup)
+ set_anon (newgroup, symbol, anon_set, comdat_head_map);
+ /* ensure this case is COMDAT meet COMDAT. */
+ else
+ gcc_assert (*val2 == newgroup);
+}
+}
+
+
/* Main dataflow loop propagating comdat groups across
the symbol table. All references to SYMBOL are examined
and NEWGROUP is updated accordingly. MAP holds current lattice
@@ -63,7 +125,9 @@ along with GCC; see the file COPYING3. If not see
tree
propagate_comdat_group (struct symtab_node *symbol,
- tree newgroup, hash_map &map)
+ tree newgroup, hash_map &map,
+ hash_set& anon_set,
+ hash_map& comdat_head_map)
{
int i;
struct ipa_ref *ref;
@@ -78,7 +142,7 @@ propagate_comdat_group (struct symtab_node *symbol,
if (ref->use == IPA_REF_ALIAS)
{
- newgroup = propagate_comdat_group (symbol2, newgroup, map);
+ newgroup = propagate_comdat_group (symbol2, newgroup, map, anon_set,
comdat_head_map);
continue;
Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
Hi Maxim, Thanks a lot for the information. I find it very useful for my future tests. Also I found this page maintained by ASAN developers https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC which lists some of the differences. Finally any plans to integrate other sanitizer tools by LLVM in to GCC, like Memory Sanitizer, Data Flow Sanitizer ? Best Regards, Gayan On Thu, Mar 31, 2016 at 4:40 PM, Maxim Ostapenko wrote: > Hi. > > On 31/03/16 12:52, Gayan Pathirage wrote: >> >> Hi, >> >> I find it difficult to locate the information regarding the version of >> the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could >> anyone suggest me a location where I can find this information. > > > This is indeed difficult. AFAIK, there isn't any mapping between LLVM and > GCC ASan releases, we just merge sanitizer library from upstream to GCC > source tree from time to time. GCC wiki doesn't have a dedicated page for > AddressSanitizer, so I suppose that the most appropriate method for > discovering such an information is just looking into ASan source code. > >> >> My question is due to some of the run time flags defined in ASAN is >> not recognized in GCC based binary (i.e. GCC 4.9.3). e.g. >> ASAN_OPTIONS=help=1:halt_on_error=0 > > > ASAN_OPTIONS=help=1 was introduced in GCC 5 and ASAN_OPTIONS=halt_on_error > will be available in GCC 6. > >> >> Also what is the GCC policy behind updating LLVM sanitizers to their >> latest version? > > > As I mentioned above, we merge sanitizer library from upstream to GCC source > tree from time to time during the active development stage (stage 1, see > https://gcc.gnu.org/develop.html). > > -Maxim > >> >> Rgds, >> >> Gayan >> >> >
Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
On 31/03/16 18:20, Gayan Pathirage wrote: Hi Maxim, Thanks a lot for the information. I find it very useful for my future tests. Also I found this page maintained by ASAN developers https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC which lists some of the differences. Yes, but please note, that this page describes differences between two particular revisions. For current trunk (and release) GCC and LLVM versions the situation might be different. Finally any plans to integrate other sanitizer tools by LLVM in to GCC, like Memory Sanitizer, Data Flow Sanitizer ? AFAIK, there aren't any plans on porting MSan and DFSan to GCC (see https://gcc.gnu.org/ml/gcc/2014-10/msg0.html for MSan). TSan and UBSan are already present in GCC. -Maxim Best Regards, Gayan On Thu, Mar 31, 2016 at 4:40 PM, Maxim Ostapenko wrote: Hi. On 31/03/16 12:52, Gayan Pathirage wrote: Hi, I find it difficult to locate the information regarding the version of the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could anyone suggest me a location where I can find this information. This is indeed difficult. AFAIK, there isn't any mapping between LLVM and GCC ASan releases, we just merge sanitizer library from upstream to GCC source tree from time to time. GCC wiki doesn't have a dedicated page for AddressSanitizer, so I suppose that the most appropriate method for discovering such an information is just looking into ASan source code. My question is due to some of the run time flags defined in ASAN is not recognized in GCC based binary (i.e. GCC 4.9.3). e.g. ASAN_OPTIONS=help=1:halt_on_error=0 ASAN_OPTIONS=help=1 was introduced in GCC 5 and ASAN_OPTIONS=halt_on_error will be available in GCC 6. Also what is the GCC policy behind updating LLVM sanitizers to their latest version? As I mentioned above, we merge sanitizer library from upstream to GCC source tree from time to time during the active development stage (stage 1, see https://gcc.gnu.org/develop.html). -Maxim Rgds, Gayan
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: > On 03/28/2016 01:56 PM, Florian Weimer wrote: > >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though > >>he provides the "-Werror=return-type" option, the compiler doesn't > >>flag the warning/error about a control reaching the end of a non-void > >>function, due to the presence of the "-w" option. He points out that > >>clang++ wtill flags the promoted warning even though warnings are > >>inhibited. > > > >I think -w is ordered with respect to the other warning obtions, and > >-w inhibits previously requested warnings, and future -W flags may > >enable other warnings. With this in mind, I agree that the current > >GCC behavior is consistent and probably not a bug. > > The general rule of thumb documented in the manual is that more > specific options take precedence over more general ones, regardless > of where they appear on the command line: Currently, -w is a nice easy quick way of shutting up all warnings whenever they are getting in the way. Let's keep it that way. [ Most warnings are heuristic, so they misfire sometimes. ] Segher
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
* Segher Boessenkool: > On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: >> On 03/28/2016 01:56 PM, Florian Weimer wrote: >> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though >> >>he provides the "-Werror=return-type" option, the compiler doesn't >> >>flag the warning/error about a control reaching the end of a non-void >> >>function, due to the presence of the "-w" option. He points out that >> >>clang++ wtill flags the promoted warning even though warnings are >> >>inhibited. >> > >> >I think -w is ordered with respect to the other warning obtions, and >> >-w inhibits previously requested warnings, and future -W flags may >> >enable other warnings. With this in mind, I agree that the current >> >GCC behavior is consistent and probably not a bug. >> >> The general rule of thumb documented in the manual is that more >> specific options take precedence over more general ones, regardless >> of where they appear on the command line: > > Currently, -w is a nice easy quick way of shutting up all warnings > whenever they are getting in the way. Let's keep it that way. You mean, by putting -w towards the end of the command line?
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On Thu, Mar 31, 2016 at 06:34:12PM +0200, Florian Weimer wrote: > * Segher Boessenkool: > > > On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: > >> On 03/28/2016 01:56 PM, Florian Weimer wrote: > >> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though > >> >>he provides the "-Werror=return-type" option, the compiler doesn't > >> >>flag the warning/error about a control reaching the end of a non-void > >> >>function, due to the presence of the "-w" option. He points out that > >> >>clang++ wtill flags the promoted warning even though warnings are > >> >>inhibited. > >> > > >> >I think -w is ordered with respect to the other warning obtions, and > >> >-w inhibits previously requested warnings, and future -W flags may > >> >enable other warnings. With this in mind, I agree that the current > >> >GCC behavior is consistent and probably not a bug. > >> > >> The general rule of thumb documented in the manual is that more > >> specific options take precedence over more general ones, regardless > >> of where they appear on the command line: > > > > Currently, -w is a nice easy quick way of shutting up all warnings > > whenever they are getting in the way. Let's keep it that way. > > You mean, by putting -w towards the end of the command line? Either that or how it is now (always turn off everything, wherever -w is on the command line); but certainly not "more specific overrides less specific". -w turns off all warnings, it's a very useful feature. Segher
stray quotation marks warning enhancement or extension
Hi, many times we copy code snippets from sources that change the Unicode quotation marks ( “ ” ) rather than " ". For example const std::string a_string(“Hello”); That line looks innocent but causes gcc to say x.cpp:4:1: error: stray ‘\342’ in program const std::string a_string(“Hello”); ^ misleading the poor programmer with such error message and wrong column. A quick Google search says there are 171,000 matches for " error: stray ‘\342’ in program" which may show that this is a very common issue. I want to know if there is consensus to one of these solutions that I can implement: * improve the error message for the case of the Unicode quotes such as adding "(seems Unicode quotes where used)" * add a flag for a GNU extension so Unicode quotes are treated as regular quotes Feedback? I just don't want to waist time coding a solution that won't be accepted. Thanks, Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson
Re: stray quotation marks warning enhancement or extension
On 31 March 2016 at 21:10, Daniel Gutson wrote:
> Hi,
>
> many times we copy code snippets from sources that change the
> Unicode quotation marks ( “ ” ) rather than " ". For example
>
> const std::string a_string(“Hello”);
>
> That line looks innocent but causes gcc to say
>
> x.cpp:4:1: error: stray ‘\342’ in program
> const std::string a_string(“Hello”);
> ^
>
> misleading the poor programmer with such error message and wrong
> column. A quick Google search says there are 171,000 matches for "
> error: stray ‘\342’ in program" which may show that this is a very
> common issue.
I have hit that problem several times and would welcome a smarter diagnostic.
> I want to know if there is consensus to one of these solutions that I
> can implement:
>
>* improve the error message for the case of the Unicode quotes such
> as adding "(seems Unicode quotes where used)"
IMHO this would be better.
It doesn't actually help fix the code, it only helps identify the
problem, but this is usually only a problem for small pieces of code
copied from a webpage, so fixing it isn't a huge task.
>* add a flag for a GNU extension so Unicode quotes are treated as
> regular quotes
That could change the meaning of valid code unless it was careful to
ignore fancy quotes inside string literals, e.g. we wouldn't want to
change the meaning of:
const std::string a_string(" “Hello” ");
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On 03/31/2016 10:30 AM, Segher Boessenkool wrote: On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: On 03/28/2016 01:56 PM, Florian Weimer wrote: In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though he provides the "-Werror=return-type" option, the compiler doesn't flag the warning/error about a control reaching the end of a non-void function, due to the presence of the "-w" option. He points out that clang++ wtill flags the promoted warning even though warnings are inhibited. I think -w is ordered with respect to the other warning obtions, and -w inhibits previously requested warnings, and future -W flags may enable other warnings. With this in mind, I agree that the current GCC behavior is consistent and probably not a bug. The general rule of thumb documented in the manual is that more specific options take precedence over more general ones, regardless of where they appear on the command line: Currently, -w is a nice easy quick way of shutting up all warnings whenever they are getting in the way. Let's keep it that way. I agree that having a knob to suppress all warnings can be useful. At the same time, having the ability to do what PR 70275 asks for (i.e., suppress only warnings that have not be been explicitly enabled or elevated to errors) can be handy as well. If it's preferable to keep -w unchanged, providing a new option to do it might be worth considering. Martin
Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
Thanks a lot for the prompt feedback Maxim, All clear now! On Thu, Mar 31, 2016 at 9:18 PM, Maxim Ostapenko wrote: > On 31/03/16 18:20, Gayan Pathirage wrote: >> >> Hi Maxim, >> >> Thanks a lot for the information. I find it very useful for my future >> tests. >> >> Also I found this page maintained by ASAN developers >> https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC >> which lists some of the differences. > > > Yes, but please note, that this page describes differences between two > particular revisions. For current trunk (and release) GCC and LLVM versions > the situation might be different. > >> >> Finally any plans to integrate other sanitizer tools by LLVM in to >> GCC, like Memory Sanitizer, Data Flow Sanitizer ? > > > AFAIK, there aren't any plans on porting MSan and DFSan to GCC (see > https://gcc.gnu.org/ml/gcc/2014-10/msg0.html for MSan). TSan and UBSan > are already present in GCC. > > -Maxim > > >> >> Best Regards, >> >> Gayan >> >> On Thu, Mar 31, 2016 at 4:40 PM, Maxim Ostapenko >> wrote: >>> >>> Hi. >>> >>> On 31/03/16 12:52, Gayan Pathirage wrote: Hi, I find it difficult to locate the information regarding the version of the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could anyone suggest me a location where I can find this information. >>> >>> >>> This is indeed difficult. AFAIK, there isn't any mapping between LLVM and >>> GCC ASan releases, we just merge sanitizer library from upstream to GCC >>> source tree from time to time. GCC wiki doesn't have a dedicated page for >>> AddressSanitizer, so I suppose that the most appropriate method for >>> discovering such an information is just looking into ASan source code. >>> My question is due to some of the run time flags defined in ASAN is not recognized in GCC based binary (i.e. GCC 4.9.3). e.g. ASAN_OPTIONS=help=1:halt_on_error=0 >>> >>> >>> ASAN_OPTIONS=help=1 was introduced in GCC 5 and >>> ASAN_OPTIONS=halt_on_error >>> will be available in GCC 6. >>> Also what is the GCC policy behind updating LLVM sanitizers to their latest version? >>> >>> >>> As I mentioned above, we merge sanitizer library from upstream to GCC >>> source >>> tree from time to time during the active development stage (stage 1, see >>> https://gcc.gnu.org/develop.html). >>> >>> -Maxim >>> Rgds, Gayan >> >
