Re: GCC Common-Function-Attributes/const
[CC gcc list and Sandra] Thanks for the suggestions. I agree that the documentation should make it possible to answer at least the basic questions on your list. We'll see about incorporating them. In general, attributes that affect optimization are implemented at a level where higher-level distinctions like those between pointers and references, or between classes with user-defined ctors vs PODs, are immaterial. It's probably worth making that clear in some preamble rather than for each individual attribute. As far as requests for new attributes or features of existing attributes I would suggest to raise those individually as enhancements in Bugzilla where they can be appropriately prioritized. Martin For context: https://gcc.gnu.org/ml/gcc/2018-11/msg00138.html On 11/27/18 8:05 AM, cmdLP #CODE wrote: Thank you for the reply. *My suggestions for the documentation* The documentation should inform if you can annotate c++ member functions with these attributes (pure, const). (It would make sence to interpret the whole object referenced by *this as a parameter) The documentation should clarify how it handles structs/classes/unions and references. Does it threat references like pointers? Does it only allow PODs/trivial types to be returned, or does it invoke the copy constructor, when it is used again? (Eg.(assume PODs/trivial types are no problem) std::variant or std::optional with trivial types shouldn't be a problem, but std::variant and std::optional are not trivial). There should be a way to express, that a returnvalue of a function never changes until another function is called. In my first e-mail I defined a class map, which has a getter and setter method; it is obvious, that calling get with the same key again yields the same value. It should be optimized to just one call to get. But the value might change, if you call set with the same key. The old returnvalue cannot be used anymore. After that all calls to get can be merged again. This could improve the performance of libraries using associative arrays. cmdLP
GSOC
I am Siddhartha Sen,currently pursuing my B.Tech degree in Information Science and Engineering,2nd year. I have taken a keen interest in your projects and have some ideas of my own as well. I am really interested in working with you in G-SOC 2019. I am proficient in C and C++ and am eager to work on brushing my skills in whichever field required. I have already checked out the GCC trunk source-code and am being able to build GCC from it.I have run the testsuite and saved the results. However, upon building it and saving it again, the results don't match. I apologise for my lack of knowledge but any help on your part would be great. Thank You.
Re: Not quoted option names in errors and warnings
On 11/21/18 1:48 AM, Martin Sebor wrote:
> On 11/20/2018 12:54 PM, Martin Liška wrote:
>> On 11/20/18 4:24 PM, Martin Sebor wrote:
>>> On 11/20/2018 03:10 AM, Martin Liška wrote:
On 11/15/18 5:54 PM, Martin Sebor wrote:
> On 11/15/2018 03:12 AM, Martin Liška wrote:
>> Hi.
>>
>> I've done a quick grep of gcc/po/gcc.pot and I see quite a lot of
>> missing quotations
>> of option names (~400). Is it something we should fix? How
>> important is that?
>
> That's quite a few... I've been fixing these as I notice them,
> usually as part of related changes. The most onerous part of
> the cleanup is adjusting tests, especially under the target-
> specific ones. It's (obviously) not critical but I think it
> would be nice to make the quoting consistent throughout over
> time (if not in one go) and then put in place a -Wformat
> checker to detect the missing quoting as new diagnostics are
> introduced. Do you think it might be scriptable?
Hi.
Are you talking about a proper GCC warning that will be triggered
once a warning
message is missing quotations?
I can definitely cook a patch in next stage1 and the testsuite fall
out should
be easy to come with.
>>>
>>> Yes, issuing a -Wformat warning for __gcc_diag__ functions is what
>>> I'm thinking of. A checker that would look for substrings within
>>> the format string that match the "-[Wfm][a-z][a-z_1-9]*" patterns
>>> (or anything else that matches an option) and point them out if
>>> they're not enclosed in a pair of %< %> (or suggest to use %qs).
>>>
>>> Martin
>>
>> Sounds good to me. Well, I can imagine doing that for GCC 9 release.
>> When will you find spare cycles for the warning? In can prepare
>> the warning/error messages patch.
>
> I don't expect to have the time to work on the warning until
> sometime in stage 1 (as an enhancement I also wouldn't expect
> it to be approved, but maybe you can get away with it ;-)
>
> Martin
That's fine, I've just noticed that to my TODO list for next stage1.
One related question: Is it fine to use apostrophes in dg-error/dg-warning
patterns.
E.g.
gcc/testsuite/g++.dg/cpp1z/decomp48.C: return s; // { dg-warning
"reference to local variable 's' returned" }
shouldn't that be { dg-warning "reference to local variable .s. returned" }?
Martin
Re: Not quoted option names in errors and warnings
On Tue, 27 Nov 2018, Martin Liška wrote: > One related question: Is it fine to use apostrophes in > dg-error/dg-warning patterns. In general the testsuite sets LC_ALL to C (and to C.ASCII on platforms where C means C.UTF-8), so yes. -- Joseph S. Myers jos...@codesourcery.com
define_subst question
I want to use define_subst like this: (define_subst "vec_merge_with_vcc" [(set (match_operand 0) (match_operand 1)) (set (match_operand 2) (match_operand 3))] "" [(parallel [(set (match_dup 0) (vec_merge (match_dup 1) (match_operand 4 "" "0") (match_operand 5 "" "e"))) (set (match_dup 2) (and (match_dup 3) (match_operand 5 "" "e")))])]) (Predicates and modes removed for brevity.) This works perfectly except for operand 5. :-( The problem is that I can't find a way to make them "match". As it is the substitution creates two operands, with different numbers, which obviously is not what I want. The manual says that I can't do (match_dup 5), and indeed trying that results in a segmentation fault. The "e" register class actually contains only one register, so I tried using (reg:DI EXEC_REG) for the second instance, but that caused an ICE elsewhere. I could use an unspec to make the second reference implicit, or just lie to the compiler and pretend it's not there, but How can I do this properly, please? Thanks Andrew
Re: ICEs in print_operand() of the rs6000 backend with invalid input assembly
Hi! On Mon, Nov 26, 2018 at 08:41:24AM +0700, Arseny Solokha wrote: > > On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote: > >> I've found recently that rs6000 and powerpcspe backends can easily trip > >> over > >> various gcc_unreachable()'s and gcc_assert()'s in their respective copies > >> of > >> print_operand() when provided with some invalid assembly (i.e. assembly > >> written > >> for other architectures). > > > > Yup. They should use output_operand_lossage instead. > > Isn't it something that should be mentioned in the Internals manual? It is a general principle that the compiler should only ICE for an internal error, so never for unexpected use input. Most existing backends use output_operand_lossage, so everyone writing a new backend should see it, anyway. > > Bonus points if you can find some way to test > > this in the testsuite (preferably for all targets), testing many kinds > > of input args (reg, imm, memory) and all output modifiers. > > For now I use a trivial script that simply tries to compile everything it > finds, > each file with a new set of -mcpu value, optimization options and --param > options. Maybe enhancing the testsuite to facilitate some kind of fuzzing out > of > the box could be a proper task for the GSoC? See what Jakub committed in r266515, maybe you can do something like that for all targets and all modifier letters? Any error is correct, just not an ICE? https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.target/powerpc/pr88188.c?view=markup&pathrev=266515 Segher
Re: question about attribute aligned for functions
On 11/26/18 3:37 PM, Jeff Law wrote:
On 11/23/18 12:31 PM, Martin Sebor wrote:
GCC currently accepts the declaration of f0 below but ignores
the attribute. On aarch64 (and I presume on other targets with
a default function alignment greater than 1), GCC rejects f1
with an error, even though it accepts -falign-functions=1
without as much as a warning.
Clang, on the other hand, rejects f0 with a hard error because
the alignment is not a power of two, but accepts f1 and appears
to honor the attribute. It also accepts -falign-functions=1.
I think diagnosing f0 with a warning is helpful because an explicit
zero alignment is most likely a mistake (especially when it comes
from a macro or some computation).
But I don't see a good reason to reject a program that specifies
a smaller alignment for a function when the default (or minimum)
alignment is greater. A smaller alignment is trivially satisfied
by a greater alignment so either accepting it or dropping it seems
preferable to failing with an error (either could be with or without
a warning).
__attribute__ ((aligned (0))) void f0 (void); // accepted, ignored
__attribute__ ((aligned (1))) void f1 (void); // aarch64 error
__attribute__ ((aligned (4))) void f4 (void); // okay
Does anyone know why GCC rejects the program, or can anyone think
of a reason why GCC should not behave as suggested above?
Note we have targets that support single byte opcodes and do not have
any requirements for functions starting on any boundary. mn103 comes to
mind.
However, the attribute can't be used to decrease a function's alignment,
so values of 0 or 1 are in practice totally uninteresting and one could
make an argument to warn for them.
The attribute does reduce the default alignment at least on some
targets. For instance, on x86_64 it lowers it from the default
16 to as little as 2, but it silently ignores 1.
At the same time, the following passes on x86_64:
__attribute__ ((aligned (1))) void f1 (void) { }
_Static_assert (__alignof__ (f1) == 1); // wrong alignof result
__attribute__ ((aligned)) void f0 (void) { }
_Static_assert (__alignof__ (f0) == 16);
__attribute__ ((aligned (2))) void f2 (void) { }
_Static_assert (__alignof__ (f2) == 2);
but the assembly shows no .align directive for f1, .align 16 for
f0, and .align 2 for f2, and the object file shows f1 first with
padding up to 16-bytes, followed by f0 padded to a 2 byte
boundary, followed by f2. The picture stays the same when f1()
is declared without the attribute (i.e., it's 16-byte aligned
by default). So __alignof__ reports the wrong alignment for
the f1 declared aligned (1).
Whether or not to warn in general if the alignment attribute is smaller
than the default may be subject to debate. I guess it depends on the
general intent that we'd find in real world codes.
I would expect real world code to care about achieving at least
the specified alignment.
A less restrictive alignment requirement is satisfied by providing
a more restrictive one, and (the above notwithstanding) the manual
documents that
You cannot use this attribute to decrease the alignment of
a function, only to increase it.
So I wouldn't expect real code to be relying on decreasing
the alignment.
That said, since GCC does make it possible to decrease the default
alignment of functions, I can think of no reason for it not to
continue when it's possible. I.e., on targets with underaligned
instruction reads to be honor requests for underaligned functions.
On strictly aligned targets I think the safe thing to do is to
quietly ignore requests for smaller alignments by default, and
perhaps provide a new option to request a warning (with the warning
being disabled by default).
Do you see a problem with this approach?
Martin
Re: question about attribute aligned for functions
On 11/27/18 11:57 AM, Martin Sebor wrote:
On 11/26/18 3:37 PM, Jeff Law wrote:
On 11/23/18 12:31 PM, Martin Sebor wrote:
GCC currently accepts the declaration of f0 below but ignores
the attribute. On aarch64 (and I presume on other targets with
a default function alignment greater than 1), GCC rejects f1
with an error, even though it accepts -falign-functions=1
without as much as a warning.
Clang, on the other hand, rejects f0 with a hard error because
the alignment is not a power of two, but accepts f1 and appears
to honor the attribute. It also accepts -falign-functions=1.
I think diagnosing f0 with a warning is helpful because an explicit
zero alignment is most likely a mistake (especially when it comes
from a macro or some computation).
But I don't see a good reason to reject a program that specifies
a smaller alignment for a function when the default (or minimum)
alignment is greater. A smaller alignment is trivially satisfied
by a greater alignment so either accepting it or dropping it seems
preferable to failing with an error (either could be with or without
a warning).
__attribute__ ((aligned (0))) void f0 (void); // accepted, ignored
__attribute__ ((aligned (1))) void f1 (void); // aarch64 error
__attribute__ ((aligned (4))) void f4 (void); // okay
Does anyone know why GCC rejects the program, or can anyone think
of a reason why GCC should not behave as suggested above?
Note we have targets that support single byte opcodes and do not have
any requirements for functions starting on any boundary. mn103 comes to
mind.
However, the attribute can't be used to decrease a function's alignment,
so values of 0 or 1 are in practice totally uninteresting and one could
make an argument to warn for them.
The attribute does reduce the default alignment at least on some
targets. For instance, on x86_64 it lowers it from the default
16 to as little as 2, but it silently ignores 1.
At the same time, the following passes on x86_64:
__attribute__ ((aligned (1))) void f1 (void) { }
_Static_assert (__alignof__ (f1) == 1); // wrong alignof result
__attribute__ ((aligned)) void f0 (void) { }
_Static_assert (__alignof__ (f0) == 16);
__attribute__ ((aligned (2))) void f2 (void) { }
_Static_assert (__alignof__ (f2) == 2);
but the assembly shows no .align directive for f1, .align 16 for
f0, and .align 2 for f2, and the object file shows f1 first with
padding up to 16-bytes, followed by f0 padded to a 2 byte
boundary, followed by f2. The picture stays the same when f1()
is declared without the attribute (i.e., it's 16-byte aligned
by default). So __alignof__ reports the wrong alignment for
the f1 declared aligned (1).
Actually, after some thought and experimenting I don't believe
the alignment __alignof__ reports is wrong. It's the best it
can do. The actual alignment of the function in the object file
could be greater (e.g., depending on what other functions are
before or after it), and that should be fine.
GCC should also be able to optimize the size of the emitted code
by rearranging functions based on both their size and alignment
requirements, perhaps by increasing both for some functions if
that reduces the size overall. This optimization can only be
done after __alignof__ expressions have been evaluated.
So with that, I think the argument to attribute aligned must
inevitably be viewed as the lower bound on a function's (or even
variable's) alignment, and specifying a value that's smaller than
what's ultimately provided should be accepted without a warning.
I think that should hold for strictly aligned targets like sparc
with a minimum alignment greater than 1 as well as for relaxed
ones like i386 with a minimum alignment of 1.
I will make this change to the aligned attribute handler to avoid
the failures in the builtin-has-attribute-*.c tests on strictly
aligned targets.
Whether or not to warn in general if the alignment attribute is smaller
than the default may be subject to debate. I guess it depends on the
general intent that we'd find in real world codes.
I would expect real world code to care about achieving at least
the specified alignment.
A less restrictive alignment requirement is satisfied by providing
a more restrictive one, and (the above notwithstanding) the manual
documents that
You cannot use this attribute to decrease the alignment of
a function, only to increase it.
So I wouldn't expect real code to be relying on decreasing
the alignment.
That said, since GCC does make it possible to decrease the default
alignment of functions, I can think of no reason for it not to
continue when it's possible. I.e., on targets with underaligned
instruction reads to be honor requests for underaligned functions.
On strictly aligned targets I think the safe thing to do is to
quietly ignore requests for smaller alignments by default, and
perhaps provide a new option to request a warning (with the warning
being disabled by default).
Do y
Re: Proposal to add FDO profile quality related diagnostics
Usecase : The usecase is to get a high-level assessment of the quality of function profiles available (-Wcoverage-mismatch and -Wmissing-profile are useful in the same spirit). For large codebases, it is useful to make the profile quality information more handy for ease of development. Doing a full gcov run is more cumbersome than keeping the warning flag ENABLED in the codebase at compile/development time to catch these. For these reasons, I do think that atleast adding the summary-level diagnostic is useful in general - "warning: XX out of YY functions not exercised in training run [-Wprofile-quality]" This lets the user make the decision of whether and how to drill down. Now for drill down, I agree gcov/lcov is a good choice. But a full gcov run is sometimes a deterrent for large codebases. For this reason, my proposal has a second-level option in the form of opt-info msgs/-Wprofile-quality=all (depending on whether we choose OPTION 1 or OPTION 2). Regarding the function level detail being too noisy : I sort of agree with that comment. But I am of the opinion that I would rather leave it to the user to infer the profile quality as per the application characteristics. Thanks Indu On 11/22/2018 03:58 AM, Martin Liška wrote: On 11/21/18 4:47 AM, Andi Kleen wrote: Indu Bhagat writes: Proposal to add diagnostics to know which functions were not run in the training run in FDO. Don't you think the warning will be very noisy? I assume most programs have a lot of cold error handling functions etc. that are never executed in a normal execution. Like how does it look like for a gcc build for example? I guess like this: https://users.suse.com/~mliska/lcov/ Indu, have you thought about using gcov/lcov rather than inventing a new warning (or opt info)? Can you please define exactly your use case? Martin I suspect it would need some heuristics to cut it down at least, like if the function ends with exit (perhaps propagated through the call tree) it's not flagged. Or if there is warning for a function don't warn about callees that are not called from somewhere else. -Andi
Re: Proposal to add FDO profile quality related diagnostics
> > Regarding the function level detail being too noisy : I sort of agree with > that > comment. But I am of the opinion that I would rather leave it to the user to > infer the profile quality as per the application characteristics. Makes sense I guess. But I would keep the drill down as opt-info. opt-info is better designed for really high volume data like this. -Andi
