Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
On Fri, Apr 1, 2016 at 1:14 PM, Martin Liška wrote: > On 03/31/2016 05:48 PM, Maxim Ostapenko wrote: >> >> 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 > > Hi. > > I was thinking about integration of MSAN to GCC (as I was hunting for an > issue in Firefox), > but as the sanitizer really needs to have instrumented all shared libraries > that a program > uses, I gave up. After a brief discussion with Jakub, he had the same opinion. FYI in our experience instrumenting a complete distribution is relatively easy (albeit boring). It took us ~2-3 months to get fully AddressSanitized Tizen last year (http://injoit.org/index.php/j1/article/viewFile/231/184) and Hanno Boeck did the same to Gentoo few months ago (https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html). So if you have a working implementation for MSan, why not throw it out so that other people could play with it? I guess it's a big and non-trivial piece of code. > However, I've been working on use-after-scope sanitizer ([1]), which would > hopefully > land in GCC 7, where I hope we can get even better results as the GCC has good > scope information of local variables. That's a cool feature indeed (something that never worked in Clang btw). > Martin > > [1] https://github.com/marxin/gcc/tree/asan-use-after-scope-2 >
Vector registers on MIPS arch
Hello there!
I'm trying to add some vector registers to a MIPS arch (32 bit). This
arch has 32 x 128 bit registers that can essentially be seen as V4SF.
So far I'm using this test:
volatile float foo __attribute__ ((vector_size (16)));
volatile float bar __attribute__ ((vector_size (16)));
int main() {
foo = foo + bar;
}
Which produces the right SSE/AVX instructions for x86 but fails on my
mips cross compiler with my modifications.
The modifications I did so far are:
- Add 32 new regsiters, adding a register class, updating/adding bit
fields, updating also other macros that deal with reg allocation (like
caller saved and stuff). Also incremented the first pseudo reg value.
- Add 3 define_insn that load, store and add vectors.
- Tweak some things here and there to let the compiler know about the
V4SF type being available.
So far the compiler goes back to scalar code, not working properly at
the veclower pass. My test.c.123t.veclower21 looks like:
:
foo.0_2 ={v} foo;
bar.1_3 ={v} bar;
_6 = BIT_FIELD_REF ;
_7 = BIT_FIELD_REF ;
_8 = _6 + _7;
_9 = BIT_FIELD_REF ;
_10 = BIT_FIELD_REF ;
_11 = _9 + _10;
_12 = BIT_FIELD_REF ;
_13 = BIT_FIELD_REF ;
_14 = _12 + _13;
_15 = BIT_FIELD_REF ;
_16 = BIT_FIELD_REF ;
_17 = _15 + _16;
foo.2_4 = {_8, _11, _14, _17};
foo ={v} foo.2_4;
return 0;
Any ideas on what I'm missing and/or how to further debug this? I don't
really want autovectorization, just to be able to use vec registers
"manually".
Thanks!
David
Re: Run one gcc test case multiple times with different option sets
On Fri, Apr 1, 2016 at 9:00 AM, Bill Seurer wrote: > On 04/01/16 10:48, Andrew Pinski wrote: >> >> On Fri, Apr 1, 2016 at 8:42 AM, Bill Seurer >> wrote: >>> >>> Is there some way using deja-gnu to have a single test case run multiple >>> times using different sets of compiler options? I didn't see anything in >>> the documentation and didn't see any examples when I searched the >>> existing >>> test cases (though of course I wasn't exactly sure what to look for). >> >> >> What most folks do is have two .c files; one that includes the other. > > > So something like... > > #define foo > #include "real-test-case.c" > > #undef foo > #define bar > #include "real-test-case.c" Well more like: New-testcase.c: #define foo #include "real-test-case.c" real-testcase-case.c #ifndef foo #define bar #endif REAL TESTCASE GOES here Thanks, Andrew > -- > > -Bill Seurer >
Re: Run one gcc test case multiple times with different option sets
On 04/01/16 10:48, Andrew Pinski wrote: On Fri, Apr 1, 2016 at 8:42 AM, Bill Seurer wrote: Is there some way using deja-gnu to have a single test case run multiple times using different sets of compiler options? I didn't see anything in the documentation and didn't see any examples when I searched the existing test cases (though of course I wasn't exactly sure what to look for). What most folks do is have two .c files; one that includes the other. So something like... #define foo #include "real-test-case.c" #undef foo #define bar #include "real-test-case.c" -- -Bill Seurer
Re: Run one gcc test case multiple times with different option sets
On Fri, Apr 1, 2016 at 8:42 AM, Bill Seurer wrote:
> Is there some way using deja-gnu to have a single test case run multiple
> times using different sets of compiler options? I didn't see anything in
> the documentation and didn't see any examples when I searched the existing
> test cases (though of course I wasn't exactly sure what to look for).
What most folks do is have two .c files; one that includes the other.
Thanks,
Andrew
>
> For example, something like this if I wanted to compile the test case once
> with -Dfoo and once with -Dbar.
>
> /* { dg-options "-Dfoo" } */
> /* { dg-options "-Dbar" } */
>
> That actually just uses the second set of options as-is.
>
> Thanks!
> --
>
> -Bill Seurer
>
Run one gcc test case multiple times with different option sets
Is there some way using deja-gnu to have a single test case run multiple
times using different sets of compiler options? I didn't see anything
in the documentation and didn't see any examples when I searched the
existing test cases (though of course I wasn't exactly sure what to look
for).
For example, something like this if I wanted to compile the test case
once with -Dfoo and once with -Dbar.
/* { dg-options "-Dfoo" } */
/* { dg-options "-Dbar" } */
That actually just uses the second set of options as-is.
Thanks!
--
-Bill Seurer
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On 03/31/2016 09:39 PM, Martin Sebor wrote: 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. Given the long standing behavior of -w, I think it should remain unchanged. jeff
Re: Re: stray quotation marks warning enhancement or extension
On 31/03/16 23:23, Jonathan Wakely wrote: On 31 March 2016@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. [...] * improve the error message for the case of the Unicode quotes such as adding "(seems Unicode quotes where used)" IMHO this would be better. Note that GCC 6.0 has the capability of issuing something like: x.cpp:4:28: error: Unicode quotation marks ‘\342’ are not valid const std::string a_string(“Hello”); ^ " or even: x.cpp:4:28: error: Unicode quotation marks ‘\342’ are not valid const std::string a_string(“Hello”); ^~~ "Hello" Smart editors might be able to apply the fix automatically given the above. Cheers, Manuel.
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On 01/04/16 04:39, Martin Sebor wrote: 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. Some users have asked for -Weverything in the past (to turn on all possible warnings unless a more specific -Wno- option is provided). Perhaps -Wno-everything should do the opposite: turn off all warnings unless a more specific -Wfoo option is provided. I'm still not sure what would be the expected behavior in the presence of #pragmas. Nonetheless, one still would need to fix the bug I mentioned in my previous email so that -Werror=foo is the same as -Wfoo -Werror=foo. As Joseph mentioned, somebody has to come up with a set of consistent rules and then see how much of the rules GCC satisfies and whether it is worth it to break backwards compatibility or to modify the rules. One would need to inspect the code, since some options are set outside the code generated by the .awk scripts, and thus not follow the same rules (or extend the awk scripts to support those options). Cheers, Manuel.
Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after
On 03/31/2016 05:48 PM, Maxim Ostapenko wrote: > > 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 Hi. I was thinking about integration of MSAN to GCC (as I was hunting for an issue in Firefox), but as the sanitizer really needs to have instrumented all shared libraries that a program uses, I gave up. After a brief discussion with Jakub, he had the same opinion. However, I've been working on use-after-scope sanitizer ([1]), which would hopefully land in GCC 7, where I hope we can get even better results as the GCC has good scope information of local variables. Martin [1] https://github.com/marxin/gcc/tree/asan-use-after-scope-2
