Re: Compiler warnings while compiling gcc with clang
On 5 May 2015 at 05:58, Andrew Pinski wrote: > These two are bogus and really clang in GCC's mind. The main reason > is the standard says struct and class are the same thing. Apart from the fact that classes are private by default and structs are not. They may be similar for layout purposes, and it may be ok to interchange them on local re-declarations when the compiler doesn't need the type completely defined, but they're not the same thing. The compiler might be smart and use the protection model that the original declaration used (private/public), but what that warning is saying is that you have refactored your code to include classes and forgot to update all uses, which is a very valid warning. I can't see why one would *want* to keep the "struct" keyword. If you're already compiling in C++ mode, removing it from variable/argument declarations should be valid, and re-declaring incomplete types should be made as class. cheers, --renato
Re: Compiler warnings while compiling gcc with clang
> On May 5, 2015, at 1:00 AM, Renato Golin wrote: > >> On 5 May 2015 at 05:58, Andrew Pinski wrote: >> These two are bogus and really clang in GCC's mind. The main reason >> is the standard says struct and class are the same thing. > > Apart from the fact that classes are private by default and structs > are not. They may be similar for layout purposes, and it may be ok to > interchange them on local re-declarations when the compiler doesn't > need the type completely defined, but they're not the same thing. Read the standard again. They are the same. The standard is very clear they are the same. > > The compiler might be smart and use the protection model that the > original declaration used (private/public), but what that warning is > saying is that you have refactored your code to include classes and > forgot to update all uses, which is a very valid warning. I can't see > why one would *want* to keep the "struct" keyword. If you're already > compiling in C++ mode, removing it from variable/argument declarations > should be valid, and re-declaring incomplete types should be made as > class. No the warning is there to try to warn people about microsoft's c++ and nothing else. Thanks, Andrew > > cheers, > --renato
Re: [RFC] Design for flag bit outputs from asms
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
[snipped]
> (3) Note that ppc is both easier and more complicated.
>
> There we have 8 4-bit registers, although most of the integer
> non-comparisons only write to CR0. And the vector non-comparisons
> only write to CR1, though of course that's of less interest in the
> context of kernel code.
Actually vector (Altivec) write to CR6. Standard FPU optionally write to
CR1, but the written value does not exactly depend on the result of the last
instruction; it is an instead an accrued exception status.
>
> For the purposes of cr0, the same scheme could certainly work, although
> the hook would not insert a hard register use, but rather a pseudo to
> be allocated to cr0 (constaint "x").
Yes, but we might also want to leave the choice of a cr register to the
compiler.
>
> That said, it's my understanding that "dot insns", setting cr0 are
> expensive in current processor generations.
Not that much if I understand properly power7.md and power8.md:
no (P7) or one (P8) additional clock for common instructions
(add/sub and logical), but nothing else, so they are likely a win.
Shift/rotate/sign extensions seem to have more decoding restrictions:
the recording ("dot") forms are "cracked" and use 2 integer units.
> There's also a lot less
> of the x86-style "operate and set a flag based on something useful".
>
But there is at least an important one, which I occasionally wished I had:
the conditional stores.
The overflow bit might also be useful, not really
for the kernel, but for applications (and mfxer is slow).
Regards,
Gabriel
Re: Compiler warnings while compiling gcc with clang
On Tue, May 05, 2015 at 04:42:02AM +, Aditya K wrote: > I was able to successfully bootstrap gcc by using clang as the stage 1 > compiler. I configured gcc using the following arguments. > > ../configure --disable-multilib --enable-bootstrap --enable-languages=c,c++ > CC=/work/llvm/install-release/bin/clang > CXX=/work/llvm/install-release/bin/clang++ > > And the bootstrap was successful. One useful thing I got to see was clang > warnings. Clang produced several warnings (> 1000 unique ones). I have > attached two files with this email. > 1. sorted list of warnings (summary only) > 2. complete build log. > > I want to know that is there any interest in resolving these warnings? I went > through the list a little bit and some warnings > appear to be quite useful. e.g. > > 1. warning: struct 'varpool_node' was previously declared as a class > [-Wmismatched-tags] > > 2. ../../gcc/cgraph.h../../gcc/wide-int.h::18881125::101:: warningwarning: : > class 'cgraph_node' was previously declared as a struct [-Wmismatch > ed-tags]'fixed_wide_int_storage' defined as a class template here but > previously declared as a struct template [-Wmismatched-tags] as discussed those particular warnings are pretty useless. However some of the other warnings such as the NULL to bool conversion and unused function ones seem like they might be worth looking into. If you determin warnings make sense to fix it'd be nice to change gcc to warn too. I'm not sure why, but the list of warnings is really garbled which makes it hard to read. Trev > > Thanks, > -Aditya
Re: Compiler warnings while compiling gcc with clang
On Tue, May 05, 2015 at 09:00:59AM +0100, Renato Golin wrote: > On 5 May 2015 at 05:58, Andrew Pinski wrote: > > These two are bogus and really clang in GCC's mind. The main reason > > is the standard says struct and class are the same thing. > > Apart from the fact that classes are private by default and structs > are not. They may be similar for layout purposes, and it may be ok to > interchange them on local re-declarations when the compiler doesn't > need the type completely defined, but they're not the same thing. > > The compiler might be smart and use the protection model that the > original declaration used (private/public), but what that warning is > saying is that you have refactored your code to include classes and > forgot to update all uses, which is a very valid warning. I can't see > why one would *want* to keep the "struct" keyword. If you're already > compiling in C++ mode, removing it from variable/argument declarations > should be valid, and re-declaring incomplete types should be made as > class. Saying forward declaration should be done with class is a value choice you've made. Given forward declarations with struct and class are interchangable it seems like a perfectly valid choice to me to decide you don't care to bother fix up all the forward declaration when you change from class to struct. The warning is useful for people who care about MSVC compat, or really care about consistancy I guess, but it seems to me since the code it warns about isn't "wrong" in any real way the warning doesn't deserve to be in -Wall or really even in -Wextra. Trev > > cheers, > --renato
Re: Compiler warnings while compiling gcc with clang
On 5 May 2015 at 11:23, Trevor Saunders wrote: > Saying forward declaration should be done with class is a value choice > you've made. Yes. > Given forward declarations with struct and class are > interchangable it seems like a perfectly valid choice to me to decide > you don't care to bother fix up all the forward declaration when you > change from class to struct. Indeed. > or really care about consistancy I guess, That's my view. And I understand it might not be a common one. > but it > seems to me since the code it warns about isn't "wrong" in any real way > the warning doesn't deserve to be in -Wall or really even in -Wextra. Absolutely agreed. However, warnings are not just for errors or even potential errors, they're to help you write better code, whether you consider "better" just correct, or easy to read, is open to interpretation. My view is that being easy to read and consistent goes a long way towards maintenance and avoiding future errors. I know a lot of excellent programmers that disagree with me, that's a matter of opinion. Having said that, we seems to agree that -Wall is *only* about potential errors, not clarity. Maybe -pedantic would be a better place for this warning. cheers, --renato
RE: Compiler warnings while compiling gcc with clang
> CC: hiradi...@msn.com; gcc@gcc.gnu.org > From: pins...@gmail.com > Subject: Re: Compiler warnings while compiling gcc with clang > Date: Tue, 5 May 2015 01:11:38 -0700 > To: renato.go...@linaro.org > > > > > >> On May 5, 2015, at 1:00 AM, Renato Golin wrote: >> >>> On 5 May 2015 at 05:58, Andrew Pinski wrote: >>> These two are bogus and really clang in GCC's mind. The main reason >>> is the standard says struct and class are the same thing. >> >> Apart from the fact that classes are private by default and structs >> are not. They may be similar for layout purposes, and it may be ok to >> interchange them on local re-declarations when the compiler doesn't >> need the type completely defined, but they're not the same thing. > > Read the standard again. They are the same. The standard is very clear they > are the same. > >> >> The compiler might be smart and use the protection model that the >> original declaration used (private/public), but what that warning is >> saying is that you have refactored your code to include classes and >> forgot to update all uses, which is a very valid warning. I can't see >> why one would *want* to keep the "struct" keyword. If you're already >> compiling in C++ mode, removing it from variable/argument declarations >> should be valid, and re-declaring incomplete types should be made as >> class. > > > No the warning is there to try to warn people about microsoft's c++ and > nothing else. At least for consistency/maintainability purposes it would be very useful to have either all structs or all classes. There are however, other differences between class and struct (http://stackoverflow.com/a/999810/811335) i.e., 1. In absence of an access-specifier for a base class, public is assumed when the derived class is declared struct and private is assumed when the class is declared class. 2. class can be used in place of a typename to declare a template parameter, while the struct cannot. -Aditya > > Thanks, > Andrew > >> >> cheers, >> --renato
Is it Okay for GCC to do the following simplifications with "-ffast-math" flag
Hi all,
For the following illustrative code,
double f1(int x) { return (double)(float)x; } --> return (double)x;
int f2(double x) { return (int)(float)x; } --> return (int)x;
Is it Okay for the compiler to do the simplifications shown above with
fast-match enabled?
Regards,
Renlin Li
Target attribute hooks questions
Hi all,
I'm looking at implementing target attributes for aarch64 and I have some
questions about the hooks involved.
I haven't looked at this part of the compiler before, so forgive me if some of
them seem obvious. I couldn't
figure it out from the documentation
(https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes)
* Seems to me that TARGET_OPTION_VALID_ATTRIBUTE_P is the most important one
that parses
the string inside the __attribute__ ((target ("..."))) and sets the
target-specific
flags appropriately. Is that correct?
* What is TARGET_ATTRIBUTE_TABLE used for? It's supposed to map attributes to
handlers?
Isn't that what TARGET_OPTION_VALID_ATTRIBUTE_P is for?
* What is the use of TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE? Is that used
during
something like LTO when different object files and functions are compiled with
different
flags? Are these functions just supposed to 'backup' various tuning and ISA
decisions?
* Is TARGET_COMP_TYPE_ATTRIBUTES the one that's supposed to handle incompatible
attributes
being specified? (for example incompatible endianness or architecture levels)?
Thanks for any insight,
Kyrill
Re: [RFC] Design for flag bit outputs from asms
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote: > (1) Each target defines a set of constraint strings, > (2) A new target hook post-processes the asm_insn, looking for the > new constraint strings. The hook expands the condition prescribed > by the string, adjusting the asm_insn as required. Since it is pre-processed, there is no real reason to overlap this with the constraints namespace; we could have e.g. "=@[xy]" (and "@[xy]" for inputs) mean the target needs to do some "xy" transform here. > Note that the output constraints are adjusted to a single internal "=j_" > which would match the flags register in any mode. We can collapse > several output flags to a single set of the flags hard register. Many targets would use an already existing contraint that describes the flags. Targets that need a fixed register could just insert the hard register here as far as I see? (I'm assuming this happens at expand time). > (3) Note that ppc is both easier and more complicated. > > There we have 8 4-bit registers, although most of the integer > non-comparisons only write to CR0. And the vector non-comparisons > only write to CR1, though of course that's of less interest in the > context of kernel code. > > For the purposes of cr0, the same scheme could certainly work, although > the hook would not insert a hard register use, but rather a pseudo to > be allocated to cr0 (constaint "x"). And "y" for "any CR field". > That said, it's my understanding that "dot insns", setting cr0 are > expensive in current processor generations. They are not. (Cell BE is not "current" :-) ) PowerPC also has some other bits (the carry bit for example, CA) that could be usefully exposed via this mechanism. > Can anyone think of any drawbacks, pitfalls, or portability issues to less > popular targets that I havn't considered? I don't like co-opting the constraint names for this; other than that, it looks quite good :-) Segher
Re: Target attribute hooks questions
Hi Kyrill,
you are right it's not easy to get its way among all those macros, my
main source of inspiration for ARM was the x86 implementation.
You can have a look at the ARM implementation to start with (on
gcc-patches, under review). That would be best not to diverge too much
aarch64 might have a few code to share with the arm be. FYI I'm planning
to add the fpu/neon attribute extensions
A few quick answer bellow, ask if you need more.
Cheers
Christian
On 05/05/2015 03:38 PM, Kyrill Tkachov wrote:
> Hi all,
>
> I'm looking at implementing target attributes for aarch64 and I have some
> questions about the hooks involved.
> I haven't looked at this part of the compiler before, so forgive me if some
> of them seem obvious. I couldn't
> figure it out from the documentation
> (https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes)
>
> * Seems to me that TARGET_OPTION_VALID_ATTRIBUTE_P is the most important one
> that parses
> the string inside the __attribute__ ((target ("..."))) and sets the
> target-specific
> flags appropriately. Is that correct?
Yes, it parses the string that goes into DECL_FUNCTION_SPECIFIC_TARGET
(fndecl) and then builds the struct gcc_options that will be switched
between functions. Note that this gone must go again to the
option_override machinery since global options can be affected by the
target options.
>
> * What is TARGET_ATTRIBUTE_TABLE used for? It's supposed to map attributes to
> handlers?
> Isn't that what TARGET_OPTION_VALID_ATTRIBUTE_P is for?
I think it's different. the TARGET_ATTRIBUTE_TABLE specifies specific
attributes (e.g naked, interrupt, ...) while the target attribute allows
to pass target flags (e.g: -marm, -mfpu=neon, ...)
>
> * What is the use of TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE? Is that
> used during
> something like LTO when different object files and functions are compiled
> with different
> flags? Are these functions just supposed to 'backup' various tuning and ISA
> decisions?
>
This is to save custom function information that are not restored by
TARGET_SET_CURRENT_FUNCTION. I didn't need it for arm/thumb.
> * Is TARGET_COMP_TYPE_ATTRIBUTES the one that's supposed to handle
> incompatible attributes
> being specified? (for example incompatible endianness or architecture levels)?
like TARGET_ATTRIBUTE_TABLE, it's different and doesn't pertain to
attribute target
Cheers
Christian
>
> Thanks for any insight,
> Kyrill
>
Re: Compiler warnings while compiling gcc with clang -- clang compilation speed on building GCC
On 05/05/2015 12:42 AM, Aditya K wrote: I was able to successfully bootstrap gcc by using clang as the stage 1 compiler. I configured gcc using the following arguments. ../configure --disable-multilib --enable-bootstrap --enable-languages=c,c++ CC=/work/llvm/install-release/bin/clang CXX=/work/llvm/install-release/bin/clang++ And the bootstrap was successful. One useful thing I got to see was clang warnings. Clang produced several warnings (> 1000 unique ones). I have attached two files with this email. I also recently interested in building GCC by LLVM. Although I was interesting in compilation speed of LLVM. So I built GCC-5 sources with LLVM-3.6 and GCC-5 using --disable-bootstrap --enable-languages=c to minimize time spent by built GCC to compile libraries (or GCC-5 sources again for bootstrap). Here are the results of make -j1 on E5-2997v3 (default -O2 was used by the both compilers): GCC-5 LLVM-3.6 real 20m44s 20m31s user 15m35s 15m56s Another interesting thing I found on SPEC2006 (only C/C++ benchmarks were used for FP) for -O1 (the machine is 4.2Ghz i7-4790K). x86-64 SPEC rates (more is better): INT: LLVMGCC -O1: 34.9 39.8 14% FP: LLVMGCC -O1: 35.7 48.5 36% x86-64 Compilation time in seconds (cpu time): INT:LLVM GCC -O1: 196.46 153.66 -22% FP: LLVM GCC -O1: 110.22 86.83 -21% So GCC-5 in -O1 mode generates 20% better code and spent 15-30% less time on compilation than LLVM-3.6. LLVM is popular for JITing but I believe GCC has much bigger potential for this and recommend JIT developers to try it. I think it helps to see alternative point of view on LLVM as "a faster compiler than GCC".
Re: Target attribute hooks questions
Hi Christian,
On 05/05/15 15:25, Christian Bruel wrote:
Hi Kyrill,
you are right it's not easy to get its way among all those macros, my
main source of inspiration for ARM was the x86 implementation.
Yeah, I've been looking at that and rs6000 for some perspective.
You can have a look at the ARM implementation to start with (on
gcc-patches, under review). That would be best not to diverge too much
aarch64 might have a few code to share with the arm be. FYI I'm planning
to add the fpu/neon attribute extensions
A few quick answer bellow, ask if you need more.
Cheers
Christian
On 05/05/2015 03:38 PM, Kyrill Tkachov wrote:
Hi all,
I'm looking at implementing target attributes for aarch64 and I have some
questions about the hooks involved.
I haven't looked at this part of the compiler before, so forgive me if some of
them seem obvious. I couldn't
figure it out from the documentation
(https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes)
* Seems to me that TARGET_OPTION_VALID_ATTRIBUTE_P is the most important one
that parses
the string inside the __attribute__ ((target ("..."))) and sets the
target-specific
flags appropriately. Is that correct?
Yes, it parses the string that goes into DECL_FUNCTION_SPECIFIC_TARGET
(fndecl) and then builds the struct gcc_options that will be switched
between functions. Note that this gone must go again to the
option_override machinery since global options can be affected by the
target options.
Right, so I'll need to call the option_override hook manually...
* What is TARGET_ATTRIBUTE_TABLE used for? It's supposed to map attributes to
handlers?
Isn't that what TARGET_OPTION_VALID_ATTRIBUTE_P is for?
I think it's different. the TARGET_ATTRIBUTE_TABLE specifies specific
attributes (e.g naked, interrupt, ...) while the target attribute allows
to pass target flags (e.g: -marm, -mfpu=neon, ...)
Ok, I see from the rs6000 backend that it's something different, I'll leave it
alone for now.
* What is the use of TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE? Is that used
during
something like LTO when different object files and functions are compiled
with different
flags? Are these functions just supposed to 'backup' various tuning and ISA
decisions?
This is to save custom function information that are not restored by
TARGET_SET_CURRENT_FUNCTION. I didn't need it for arm/thumb.
I'm looking at these in the context of LTO. From what I understand, LTO uses
target attributes
to tag each function with target-specific flags so that it can keep track of
the flags when
linking object files compiled with different target flags (e.g. different mcpu
options).
Which hooks are used in this process?
* Is TARGET_COMP_TYPE_ATTRIBUTES the one that's supposed to handle incompatible
attributes
being specified? (for example incompatible endianness or architecture levels)?
like TARGET_ATTRIBUTE_TABLE, it's different and doesn't pertain to
attribute target
Thanks for the help!
Kyrill
Cheers
Christian
Thanks for any insight,
Kyrill
Re: [RFC] Design for flag bit outputs from asms
On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool wrote: > > Since it is pre-processed, there is no real reason to overlap this with > the constraints namespace; we could have e.g. "=@[xy]" (and "@[xy]" for > inputs) mean the target needs to do some "xy" transform here. In fact, standing out visually would be just a good thing, since it's pretty special even from a usage standpoint. And are you actually planning to have flags as inputs? Because *that* sounds like a bad idea. It's pretty hard to turn a boolean into a flag value, while pretty much any archiecture has an operation like "setcc" to go the other way. And I don't think your machine descriptions have anything to "generate flags". You'd have to add fragile and complex machinery for something it is unlikely anybody ever wants. Flag *outputs* people definitely want. Flag inputs? Yeah, I can absolutely see the carry flag being useful for multi-precision arithmetic, but it's *so* hard to guarantee that it still is live, that in practice the compiler would likely have to re-generate it from a value anyway, so ... So I'd go for output-only, and make the syntax be something very visually unambiguous. That "=@[xy]" format looks fine, where "xy" would be very architecture-dependent. Or make it even *more* specific by using "CC" for condition codes, and make the syntax "=@CC[xy]", in case you ever want to use the "@" marker for any other kind of magic constraint. Linus
Re: [RFC] Design for flag bit outputs from asms
On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote: > On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool > wrote: > > > > Since it is pre-processed, there is no real reason to overlap this with > > the constraints namespace; we could have e.g. "=@[xy]" (and "@[xy]" for > > inputs) mean the target needs to do some "xy" transform here. > > In fact, standing out visually would be just a good thing, since it's > pretty special even from a usage standpoint. > > And are you actually planning to have flags as inputs? Because *that* > sounds like a bad idea. It's pretty hard to turn a boolean into a flag > value, while pretty much any archiecture has an operation like "setcc" > to go the other way. And I don't think your machine descriptions have > anything to "generate flags". You'd have to add fragile and complex > machinery for something it is unlikely anybody ever wants. It isn't hard (or expensive) to turn integers into flags, on many targets. It is nice to allow this at least in the generic part of the code -- what targets do in their target hook is up to them. It isn't fragile or complex. Not useful on some archs, yes I certainly believe that. But the lovely thing about Richard's proposal is that it actually is a very simple addition to what the compiler already does, there are no hard new optimisations needed, it's just a bit of munging to allow the user to write an asm with condition code in/outs. Allowing inputs is just another bool argument to the target hook. I'd rather have this more orthogonal than more specialised; it can be used for much more than just condition codes. It's not like the "more general" syntax would be a burden, as far as I see. Segher
Re: Shared object compiled with g++ is not unloaded
So, really no ideas on this issue? Or this behavior is considered normal? 2015-04-26 1:38 GMT+03:00 Max Dmitrichenko : > Hi all! > > I've faced with strange behavior when I investigated a bug on a rather > new distros of Linux. I'm not sure that it is a bug of gcc, but may be > someone can bring some light to it. > > So, my project heavily uses plugins which are dynamically loaded with > dlopen() and unloaded with dlclose() functions. I've got report that > some (not all) plugins are not unloaded: they remain in the process > map and if you put a new version of binary it's not loaded until > program is finished and started again. This happens only on rather new > distros: RHEL 7x (gcc 4.8), Debian 7 (gcc 4.7) and last versions of > Ubuntu (gcc 4.7 - 4.9). While on RHEL 6.x and Debian 6.x (gcc 4.4 on > both) everything works as expected. Checked only on x86_64 > architecture. > > So I "bisected" the code to find why this happens. I've found that if > plugin contains a static variable in the inlined function, then > dlclose() leaves the SO in the memory. Also I've found that it happens > only if it is compiled with g++. The same example renamed to *.c and > compiled with gcc works OK. > > Attached is the sample which reproduces this effect. Use make command > to build 'test' executable and 'test.so' shared object, then run: > $ ./test > > If it outputs something like: > 7fc80cdf2000-7fc80cdf3000 r-xp fe:02 5902461 > /home/tests/so/test.so > 7fc80cdf3000-7fc80cff2000 ---p 1000 fe:02 5902461 > /home/tests/so/test.so > 7fc80cff2000-7fc80cff3000 rw-p fe:02 5902461 > /home/tests/so/test.so > > then shared object was not unloaded. Remove "inline" keyword in so.cpp > and everything works fine. > > That bad thing is that some parts of boost also make the plugin > unloadable and this can be controlled. > > So, is it a bug? If no, can it be somehow workarounded? > -- > With best regards > Max Dmitrichenko -- -- With best regards Max Dmitrichenko
Re: Shared object compiled with g++ is not unloaded
On Tue, May 05, 2015 at 09:01:03PM +0300, Max Dmitrichenko wrote: > So, really no ideas on this issue? Or this behavior is considered normal? It is not a bug, it is how STB_GNU_UNIQUE symbols work. With gcc 4.8.4, or 4.9.2, 5.1 or trunk you can actually use -fno-gnu-unique if you are ok with its consequences. Jakub
GOMP: ICV: run-sched-var - Why is dynamic default and not static?
Hi, in gcc/libgomp/env.c the ICV run-sched-var is defined as run_sched_var = GFS_DYNAMIC It would be more natural to define it as GFS_STATIC, since the default schedule is also static in gomp. Is there any reason for this decision? Both ICVs run-sched-var and def-sched-var are implementation defined, but differ in gomp? Here are the quotes from the OpenMP spec 3.1: run-sched-var - controls the schedule that the runtime schedule clause uses for loop regions. There is one copy of this ICV per data environment. ( OMP_SCHEDULE, omp_get_schedule(), Implementation defined ) def-sched-var - controls the implementation defined default scheduling of loop regions. There is one copy of this ICV for the whole program. ( Implementation defined ) Cheers, Andreas
Re: Compiler warnings while compiling gcc with clang
On 5 May 2015 at 12:39, Aditya K wrote: > There are however, other differences between class and struct > (http://stackoverflow.com/a/999810/811335) i.e., > > 1. In absence of an access-specifier for a base class, public is assumed when > the derived class is declared struct and private is assumed when the class is > declared class. Yes, everyone here knows that. That is only relevant to the definition of the class, which can only occur once. For the purposes of declarations that are not definitions there is no difference. > 2. class can be used in place of a typename to declare a template parameter, > while the struct cannot. Completely irrelevant in this context. The use of 'class' in a template parameter list has nothing to do with struct or class types, nor forward declarations of struct or class types.
Re: Is it Okay for GCC to do the following simplifications with "-ffast-math" flag
On 05/05/2015 07:27 AM, Renlin Li wrote:
Hi all,
For the following illustrative code,
double f1(int x) { return (double)(float)x; } --> return (double)x;
int f2(double x) { return (int)(float)x; } --> return (int)x;
Is it Okay for the compiler to do the simplifications shown above with
fast-match enabled?
Standard practice these days for this kind of stuff is to have separate
flags for the various kinds of transformations. -ffast-math can then
turn on those which are usually OK.
It certainly helps if the proposed transformation is safe across
industry standard benchmarks.It also helps if you can show real
world cases where it helps and the domains where the transformations
result in unexpected results.
Ultimately it's a judgment call based on those kind of factors.
jeff
Merging debug-early work?
Gentlemen!
I believe I have done as much as is reasonable for a merge, but I'd like
to get your opinion before I post a huge patch to the list.
The branch bootstraps with one regression in GCC
(gcc.dg/debug/dwarf2/stacked-qualified-types-3.c) and none for GDB.
The GCC regression is a missed optimization while merging the common
denominator of a set of qualifiers for a type within a DIE. For
example, if two types share "const volatile" (say "const volatile int"
and "const volatile char"), dwarf2out outputs things in the most
efficient manner as to share the maximum common type DIEs. This is not
working in the branch as TYPE_MAIN_VARIANTs are not complete by the time
early dwarf is run. If it is possible, I'd like to work on this one
regression post-merge. Not a big deal if you disagree, but I'd prefer
to postpone on this non crucial bit.
A few caveats...
Richi wants to play around with free-lang-data in the non LTO path. I
haven't not done so, and it's left as an exercise to the reader :).
Shortly after the merge I'll work on a pass to prune unused decl DIEs as
we're presently creating more DIEs than mainline. This was expected,
and if I understood Jason correctly, it is ok to work on this
post-merge. However, even without such a pass, the .debug_info size
difference is reasonable:
gcc/* (except testsuite):
Total .debug_info size for [debug-early]: 91081591.00
Total .debug_info size for [mainline]: 84777565.00
Total change: 7.44%
libstdc++-v3/* (except testsuite):
Total .debug_info size for [debug-early]: 5173014.00
Total .debug_info size for [mainline]: 5044971.00
Total change: 2.54%
x86_64-unknown-linux-gnu/*
Total .debug_info size for [debug-early]: 5893131.00
Total .debug_info size for [mainline]: 5694176.00
Total change: 3.49%
The above stats are for "size -A | grep debug_info...".
Within gcc there were a handful of files that were significantly bigger
(twice as much), and at least the 3-4 I investigated were all due to
extra unused DIEs that will be handled by a DECL DIE optimization pass.
Specifically, there are cases where external variables have their DIEs
generated, because we cannot look at TREE_USED within early dwarf.
Stuff like this will get a debug info (which is not terribly bad IMO):
struct somestruct { int somefield; };
extern struct somestruct *sometable;
The other common scenario is the ICF pass which will mark hunks as
undebuggable late in the compilation process (by setting
DECL_IGNORED_P)-- actually any pass calling expand_hunk(). This happens
for something like c-family/stub-objc.c which have multiple identical
stubs and get folded into one function.
So...all in all, the .debug_info increase is within what was expected
when we started this project (3-7%). Actually, I'm pleasantly surprised
it's not 10-15%. I expect to get this down significantly in short time.
Thoughts on moving forward? Is the stacked qualifier regression a show
stopper? Is the .debug_info size regression acceptable?
And of course... I'm not going anywhere. Unfortunately, I'm not even
going on vacation... so I'm here to fix the fallout ;-).
Aldy
gcc-5-20150505 is now available
Snapshot gcc-5-20150505 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150505/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 222830 You'll find: gcc-5-20150505.tar.bz2 Complete GCC MD5=8acc1b53380be0dd56e67990ba1fc06e SHA1=aec7cada891b1870fdeb579eb743ff7cbe601cad Diffs from 5-20150428 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[OR1K port] where do I change the function frame structure
Greetings Please .. where (in what file, dir) of the gcc (4.9.1) source should I rummage in order to change the sequence of instructions eventually emitted to do a function call? I mean to target the sequence of saves of to-be-clobbered registers, change of stack/frame pointer ... and the reverse of that sequence that one finds around a function call in the compiled code. I'm looking at the OR1K port, which I would like to port further to a related architecture. I understand that I probably should be changing the RTL constructed somewhere near the front end, and that I will also have to do a bit of looking after what assembler is emitted at the back end. But for now, please point me at the right area of the code and I'll be able to get specific. Instead of decrementing the stack pointer on call, then incrementing it again on return, I want to save the stack pointer, then decrement it, and copy back from the saved copy instead of incrementing it again on return. This is similar to what happens to a frame pointer, when there is a frame pointer ... I hope somebody can direct me to the right area of the source code. Regards to all PTB
Re: Is it Okay for GCC to do the following simplifications with "-ffast-math" flag
On 05/05/2015 08:27 AM, Renlin Li wrote:
Hi all,
For the following illustrative code,
double f1(int x) { return (double)(float)x; } --> return (double)x;
int f2(double x) { return (int)(float)x; } --> return (int)x;
Is it Okay for the compiler to do the simplifications shown above with
fast-match enabled?
Such a transformation would yield different results
for integers that are exactly representable in double
but not in float. For example, the smallest positive
integer with such a property in IEEE 754, 16,777,217,
converts to 16,777,216 in float. I'm not a math expert
but such a result would seem unexpected even with
-ffast-math.
Martin
Regards,
Renlin Li
RE: Compiler warnings while compiling gcc with clang
So, I analyzed other warnings and following is the list of relevant warning that I could collect. Hope this is useful. gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left hand side of this comparison ../../gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses] if ((!type == FUNC || address || !opt_for_fn (decl, optimize_size)) gcc/expr.c:5271:9: warning: comparison of constant -1 with expression of type 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare] ../../gcc/expr.c:5271:9: warning: comparison of constant -1 with expression of type 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare] if (!SUBREG_CHECK_PROMOTED_SIGN (target, ^~~ There was a similar bug posted some time ago (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271) gcc/reload1.c:470:28: warning: incrementing expression of type bool is deprecated [-Wdeprecated-increment-bool] ../../gcc/reload1.c:470:28: warning: incrementing expression of type bool is deprecated [-Wdeprecated-increment-bool] spill_indirect_levels++; ~^ Seems like for this bug we need to change the declaration of bool this_target_reload::x_spill_indirect_levels to an int. Even the comment there mentions that this variable might take other integral values. /* Nonzero if indirect addressing is supported on the machine; this means that spilling (REG n) does not require reloading it into a register in order to do (MEM (REG n)) or (MEM (PLUS (REG n) (CONST_INT c))). The value indicates the level of indirect addressing supported, e.g., two means that (MEM (MEM (REG n))) is also valid if (REG n) does not get a hard register. */ bool x_spill_indirect_levels; gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] ../../gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] *second = GEN_INT (CONST_DOUBLE_HIGH (value)); ^ ../../gcc/rtl.h:1757:30: note: expanded from macro 'CONST_DOUBLE_HIGH' #define CONST_DOUBLE_HIGH(r) XCMWINT (r, 1, CONST_DOUBLE, VOIDmode) ^ ~ ../../gcc/rtl.h:1123:36: note: expanded from macro 'XCMWINT' #define XCMWINT(RTX, N, C, M) ((RTX)->u.hwint[N]) ^ ../../gcc/rtl.h:3193:51: note: expanded from macro 'GEN_INT' #define GEN_INT(N) gen_rtx_CONST_INT (VOIDmode, (N)) ^ ../../gcc/rtl.h:397:5: note: array 'hwint' declared here HOST_WIDE_INT hwint[1]; ^ ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' # define HOST_WIDE_INT long ^ gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' (aka 'vec') [-Winvalid-offsetof] ../../gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' (aka 'vec, va_heap, vl_embed>') [-Winvalid-offsetof] return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); ^ ~ /home/hiraditya/work/llvm/install-release/bin/../lib/clang/3.7.0/include/stddef.h:120:24: note: expanded from macro 'offsetof' #define offsetof(t, d) __builtin_offsetof(t, d) genrtl.h:435:3: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] ./genrtl.h:435:3: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] XWINT (rt, 1) = arg1; ^ ~ ../../gcc/rtl.h:1120:29: note: expanded from macro 'XWINT' #define XWINT(RTX, N) ((RTX)->u.hwint[N]) ^ ../../gcc/rtl.h:397:5: note: array 'hwint' declared here HOST_WIDE_INT hwint[1]; ^ ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' # define HOST_WIDE_INT long gcc/final.c:3957:8: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] ../../gcc/final.c:3957:8: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
Re: Compiler warnings while compiling gcc with clang
> On May 5, 2015, at 8:13 PM, Aditya K wrote: > > So, I analyzed other warnings and following is the list of relevant warning > that I could collect. Hope this is useful. > > > gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left hand > side of this comparison > ../../gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left > hand side of this comparison [-Wlogical-not-parentheses] > if ((!type == FUNC || address || !opt_for_fn (decl, optimize_size)) > > gcc/expr.c:5271:9: warning: comparison of constant -1 with expression of type > 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare] > ../../gcc/expr.c:5271:9: warning: comparison of constant -1 with expression > of type 'unsigned int' is always false > [-Wtautological-constant-out-of-range-compare] > if (!SUBREG_CHECK_PROMOTED_SIGN (target, >^~~ > > There was a similar bug posted some time ago > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271) > > > gcc/reload1.c:470:28: warning: incrementing expression of type bool is > deprecated [-Wdeprecated-increment-bool] > ../../gcc/reload1.c:470:28: warning: incrementing expression of type bool is > deprecated [-Wdeprecated-increment-bool] > spill_indirect_levels++; > ~^ > > Seems like for this bug we need to change the declaration of > > bool this_target_reload::x_spill_indirect_levels to an int. Even the comment > there mentions that this variable might take > other integral values. > > /* Nonzero if indirect addressing is supported on the machine; this means > that spilling (REG n) does not require reloading it into a register in > order to do (MEM (REG n)) or (MEM (PLUS (REG n) (CONST_INT c))). The > value indicates the level of indirect addressing supported, e.g., two > means that (MEM (MEM (REG n))) is also valid if (REG n) does not get > a hard register. */ > bool x_spill_indirect_levels; > > > > > gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the array > (which contains 1 element) [-Warray-bounds] > ../../gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the > array (which contains 1 element) [-Warray-bounds] > *second = GEN_INT (CONST_DOUBLE_HIGH (value)); > ^ These warnings are bogus due to the array being the last element of the structure. Please file that with clang. Thanks, Andrew > > ../../gcc/rtl.h:1757:30: note: expanded from macro 'CONST_DOUBLE_HIGH' > #define CONST_DOUBLE_HIGH(r) XCMWINT (r, 1, CONST_DOUBLE, VOIDmode) > ^ ~ > ../../gcc/rtl.h:1123:36: note: expanded from macro 'XCMWINT' > #define XCMWINT(RTX, N, C, M) ((RTX)->u.hwint[N]) > ^ > ../../gcc/rtl.h:3193:51: note: expanded from macro 'GEN_INT' > #define GEN_INT(N) gen_rtx_CONST_INT (VOIDmode, (N)) > ^ > ../../gcc/rtl.h:397:5: note: array 'hwint' declared here > HOST_WIDE_INT hwint[1]; > ^ > ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' > # define HOST_WIDE_INT long > ^ > > > > gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' (aka > 'vec') [-Winvalid-offsetof] > ../../gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' > (aka 'vec, va_heap, vl_embed>') > [-Winvalid-offsetof] > return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); > ^ ~ > /home/hiraditya/work/llvm/install-release/bin/../lib/clang/3.7.0/include/stddef.h:120:24: > note: expanded from macro 'offsetof' > #define offsetof(t, d) __builtin_offsetof(t, d) > > > > > genrtl.h:435:3: warning: array index 1 is past the end of the array (which > contains 1 element) [-Warray-bounds] > ./genrtl.h:435:3: warning: array index 1 is past the end of the array (which > contains 1 element) [-Warray-bounds] > XWINT (rt, 1) = arg1; > ^ ~ > ../../gcc/rtl.h:1120:29: note: expanded from macro 'XWINT' > #define XWINT(RTX, N) ((RTX)->u.hwint[N]) > ^ > ../../gcc/rtl.h:397:5: note: array 'hwint' declared here > HOST_WIDE_INT hwint[1]; > ^ > ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' > # define HOST_W
RE: Compiler warnings while compiling gcc with clang
> CC: jwakely@gmail.com; renato.go...@linaro.org; gcc@gcc.gnu.org > From: pins...@gmail.com > Subject: Re: Compiler warnings while compiling gcc with clang > Date: Tue, 5 May 2015 20:19:04 -0700 > To: hiradi...@msn.com > > > > > >> On May 5, 2015, at 8:13 PM, Aditya K wrote: >> >> So, I analyzed other warnings and following is the list of relevant warning >> that I could collect. Hope this is useful. >> >> >> gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left hand >> side of this comparison >> ../../gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left >> hand side of this comparison [-Wlogical-not-parentheses] >> if ((!type == FUNC || address || !opt_for_fn (decl, optimize_size)) >> >> gcc/expr.c:5271:9: warning: comparison of constant -1 with expression of >> type 'unsigned int' is always false >> [-Wtautological-constant-out-of-range-compare] >> ../../gcc/expr.c:5271:9: warning: comparison of constant -1 with expression >> of type 'unsigned int' is always false >> [-Wtautological-constant-out-of-range-compare] >> if (!SUBREG_CHECK_PROMOTED_SIGN (target, >> ^~~ >> >> There was a similar bug posted some time ago >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271) >> >> >> gcc/reload1.c:470:28: warning: incrementing expression of type bool is >> deprecated [-Wdeprecated-increment-bool] >> ../../gcc/reload1.c:470:28: warning: incrementing expression of type bool is >> deprecated [-Wdeprecated-increment-bool] >> spill_indirect_levels++; >> ~^ >> >> Seems like for this bug we need to change the declaration of >> >> bool this_target_reload::x_spill_indirect_levels to an int. Even the comment >> there mentions that this variable might take >> other integral values. >> >> /* Nonzero if indirect addressing is supported on the machine; this means >> that spilling (REG n) does not require reloading it into a register in >> order to do (MEM (REG n)) or (MEM (PLUS (REG n) (CONST_INT c))). The >> value indicates the level of indirect addressing supported, e.g., two >> means that (MEM (MEM (REG n))) is also valid if (REG n) does not get >> a hard register. */ >> bool x_spill_indirect_levels; >> >> >> >> >> gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the array >> (which contains 1 element) [-Warray-bounds] >> ../../gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the >> array (which contains 1 element) [-Warray-bounds] >> *second = GEN_INT (CONST_DOUBLE_HIGH (value)); >> ^ > > These warnings are bogus due to the array being the last element of the > structure. > > Please file that with clang. > IIRC, C++ does not allow flexible array members. Thanks, -Aditya > Thanks, > Andrew > > > >> >> ../../gcc/rtl.h:1757:30: note: expanded from macro 'CONST_DOUBLE_HIGH' >> #define CONST_DOUBLE_HIGH(r) XCMWINT (r, 1, CONST_DOUBLE, VOIDmode) >> ^ ~ >> ../../gcc/rtl.h:1123:36: note: expanded from macro 'XCMWINT' >> #define XCMWINT(RTX, N, C, M) ((RTX)->u.hwint[N]) >> ^ >> ../../gcc/rtl.h:3193:51: note: expanded from macro 'GEN_INT' >> #define GEN_INT(N) gen_rtx_CONST_INT (VOIDmode, (N)) >> ^ >> ../../gcc/rtl.h:397:5: note: array 'hwint' declared here >> HOST_WIDE_INT hwint[1]; >> ^ >> ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' >> # define HOST_WIDE_INT long >> ^ >> >> >> >> gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' (aka >> 'vec') [-Winvalid-offsetof] >> ../../gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' >> (aka 'vec, va_heap, vl_embed>') >> [-Winvalid-offsetof] >> return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); >> ^ ~ >> /home/hiraditya/work/llvm/install-release/bin/../lib/clang/3.7.0/include/stddef.h:120:24: >> note: expanded from macro 'offsetof' >> #define offsetof(t, d) __builtin_offsetof(t, d) >> >> >> >> >> genrtl.h:435:3: warning: array index 1 is past the end of the array (which >> contains 1 element) [-Warray-bounds] >> ./genrtl.h:435:3: warning: array index 1 is past the end of the array (which >> contains 1 element) [-Warray-bounds] >> XWINT (rt, 1) = arg1; >> ^ ~ >> ../../gcc/rtl.h:1120:29: note: expanded from macro 'XWINT' >> #define XWINT(RTX, N) ((RTX)->u.hwint[N]) >> ^ >> ../../gcc/rtl.h:397:5: note: array 'hwint' declared here >> HOST_WIDE_INT hwint[1]; >> ^ >> ../../gcc/hwint.h:54:26: note:
Re: Compiler warnings while compiling gcc with clang
On Tue, May 5, 2015 at 9:00 PM, Aditya K wrote: > > > >> CC: jwakely@gmail.com; renato.go...@linaro.org; gcc@gcc.gnu.org >> From: pins...@gmail.com >> Subject: Re: Compiler warnings while compiling gcc with clang >> Date: Tue, 5 May 2015 20:19:04 -0700 >> To: hiradi...@msn.com >> >> >> >> >> >>> On May 5, 2015, at 8:13 PM, Aditya K wrote: >>> >>> So, I analyzed other warnings and following is the list of relevant warning >>> that I could collect. Hope this is useful. >>> >>> >>> gcc/ipa-icf.c:508:12: warning: logical not is only applied to the left hand >>> side of this comparison >>> ../../gcc/ipa-icf.c:508:12: warning: logical not is only applied to the >>> left hand side of this comparison [-Wlogical-not-parentheses] >>> if ((!type == FUNC || address || !opt_for_fn (decl, optimize_size)) >>> >>> gcc/expr.c:5271:9: warning: comparison of constant -1 with expression of >>> type 'unsigned int' is always false >>> [-Wtautological-constant-out-of-range-compare] >>> ../../gcc/expr.c:5271:9: warning: comparison of constant -1 with expression >>> of type 'unsigned int' is always false >>> [-Wtautological-constant-out-of-range-compare] >>> if (!SUBREG_CHECK_PROMOTED_SIGN (target, >>> ^~~ >>> >>> There was a similar bug posted some time ago >>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271) >>> >>> >>> gcc/reload1.c:470:28: warning: incrementing expression of type bool is >>> deprecated [-Wdeprecated-increment-bool] >>> ../../gcc/reload1.c:470:28: warning: incrementing expression of type bool >>> is deprecated [-Wdeprecated-increment-bool] >>> spill_indirect_levels++; >>> ~^ >>> >>> Seems like for this bug we need to change the declaration of >>> >>> bool this_target_reload::x_spill_indirect_levels to an int. Even the >>> comment there mentions that this variable might take >>> other integral values. >>> >>> /* Nonzero if indirect addressing is supported on the machine; this means >>> that spilling (REG n) does not require reloading it into a register in >>> order to do (MEM (REG n)) or (MEM (PLUS (REG n) (CONST_INT c))). The >>> value indicates the level of indirect addressing supported, e.g., two >>> means that (MEM (MEM (REG n))) is also valid if (REG n) does not get >>> a hard register. */ >>> bool x_spill_indirect_levels; >>> >>> >>> >>> >>> gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the array >>> (which contains 1 element) [-Warray-bounds] >>> ../../gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the >>> array (which contains 1 element) [-Warray-bounds] >>> *second = GEN_INT (CONST_DOUBLE_HIGH (value)); >>> ^ >> >> These warnings are bogus due to the array being the last element of the >> structure. >> >> Please file that with clang. >> > > IIRC, C++ does not allow flexible array members. But this has been a common extension for many years now (since C++ and C have been around). So warning is useless. Thanks, Andrew > > Thanks, > -Aditya > > >> Thanks, >> Andrew >> >> >> >>> >>> ../../gcc/rtl.h:1757:30: note: expanded from macro 'CONST_DOUBLE_HIGH' >>> #define CONST_DOUBLE_HIGH(r) XCMWINT (r, 1, CONST_DOUBLE, VOIDmode) >>> ^ ~ >>> ../../gcc/rtl.h:1123:36: note: expanded from macro 'XCMWINT' >>> #define XCMWINT(RTX, N, C, M) ((RTX)->u.hwint[N]) >>> ^ >>> ../../gcc/rtl.h:3193:51: note: expanded from macro 'GEN_INT' >>> #define GEN_INT(N) gen_rtx_CONST_INT (VOIDmode, (N)) >>> ^ >>> ../../gcc/rtl.h:397:5: note: array 'hwint' declared here >>> HOST_WIDE_INT hwint[1]; >>> ^ >>> ../../gcc/hwint.h:54:26: note: expanded from macro 'HOST_WIDE_INT' >>> # define HOST_WIDE_INT long >>> ^ >>> >>> >>> >>> gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' (aka >>> 'vec') [-Winvalid-offsetof] >>> ../../gcc/vec.h:1048:10: warning: offset of on non-POD type 'vec_embedded' >>> (aka 'vec, va_heap, vl_embed>') >>> [-Winvalid-offsetof] >>> return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); >>> ^ ~ >>> /home/hiraditya/work/llvm/install-release/bin/../lib/clang/3.7.0/include/stddef.h:120:24: >>> note: expanded from macro 'offsetof' >>> #define offsetof(t, d) __builtin_offsetof(t, d) >>> >>> >>> >>> >>> genrtl.h:435:3: warning: array index 1 is past the end of the array (which >>> contains 1 element) [-Warray-bounds] >>> ./genrtl.h:435:3: warning: array index 1 is past the end of the array >>> (wh
