[wwwdocs] Typo in description of __builtin_expect_with_probability
Hello, I'd like to report a typo in description of «__builtin_expect_with_probability»: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins The description starts with "The built-in has same semantics as *__builtin_expect_with_probability*", but it seems like *__builtin_expect* should be there. Thanks!
Re: "aligned" attribute with too-large argument
> On Oct 29, 2018, at 4:08 PM, Martin Sebor wrote:
>
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>>
>>
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>>>
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large
for the platform. But when applied to functions, there is no error check.
The same applies to label alignment (from the -falign-labels switch).
The result is an ICE in my target code because it is asked to output
assembly language for an alignment not supported by the target.
Should these cases also produce error messages? Or should the back end
ignore attempts to align too much?
>>>
>>> check_user_alignment() in c-attribs.c rejects excessive alignments
>>> the same for functions and variables:
>>>
>>> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>>> {
>>>error ("requested alignment is too large");
>>>return -1;
>>> }
>>>
>>> so I don't immediately see where this inconsistency comes from
>>> Is there different/more restrictive handling for variables in
>>> the back end? (a test case would be great).
>>
>> I forgot to attach it. Here it is.
>
> I don't see any errors with the test case on x86_64. In GDB I see
> the alignment for ag is 524288 and MAX_OFILE_ALIGNMENT is 2147483648.
> What target do you see the error with?
>
> Martin
There are two related issues.
One is that GCC says the max alignment for variables on x86 is 32768
(MAX_OFILE_ALIGNMENT is 32768). And it enforces that, for variables. But a
request to align a function to 65536 is permitted. Since the assembler doesn't
actually complain, no errors appear.
On pdp11, MAX_OFILE_ALIGNMENT is 2. So in the test file I sent, the aligned(2)
entries are legal and the others are not. Since the target doesn't know how to
generate assembly code for alignment greater than 2, the overly aligned
function results in an ICE. But the overly aligned variables generate error
messages, as expected.
What I want is for function and label alignment to honor MAX_OFILE_ALIGNMENT.
The only alternative is to silently ignore excessive function alignment in the
target code.
paul
Re: "aligned" attribute with too-large argument
On 10/29/2018 09:19 AM, Paul Koning wrote:
On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
On 10/29/2018 07:45 AM, Paul Koning wrote:
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large for
the platform. But when applied to functions, there is no error check. The
same applies to label alignment (from the -falign-labels switch).
The result is an ICE in my target code because it is asked to output assembly
language for an alignment not supported by the target.
Should these cases also produce error messages? Or should the back end ignore
attempts to align too much?
check_user_alignment() in c-attribs.c rejects excessive alignments
the same for functions and variables:
else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
{
error ("requested alignment is too large");
return -1;
}
so I don't immediately see where this inconsistency comes from
Is there different/more restrictive handling for variables in
the back end? (a test case would be great).
I forgot to attach it. Here it is.
I don't see any errors with the test case on x86_64. In GDB I see
the alignment for ag is 524288 and MAX_OFILE_ALIGNMENT is 2147483648.
What target do you see the error with?
Martin
Suitable regression test for vectorizer patches?
I want to submit some vectorizer patches, what would be a suitable regression test? Preferably some native or cross test that can run on an i7 x86_64 GNU/Linux machine. To give an idea what code I'm patching, here are the patches I got so far: * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Recognize unsigned dot product pattern. Allow widening multiply-add to be used for DOT_PROF_EXPR reductions. * tree-vect-data-refs.c (vect_get_smallest_scalar_type): Treat WIDEN_MULT_PLUS_EXPR like WIDEN_SUM_EXPR. * tree-vect-loop.c (get_initial_def_for_reduction): Likewise. Get VECTYPE from STMT_VINFO_VECTYPE. (vect_determine_vectorization_factor): Allow vcector size input/output mismatch for reduction. (vect_analyze_scalar_cycles_1): When we find a phi for a reduction, put the reduction statement into the phi's STMT_VINFO_RELATED_STMT. * tree-vect-patterns.c (vect_pattern_recog_1): If DOT_PROD_EXPR can't be expanded directly, try to use WIDEN_MULT_PLUS_EXPR instead. Fix bug where a vectorizer reduction split (from TARGET_VECTORIZE_SPLIT_REDUCTION) would end up not being used. * tree-vect-loop.c (vect_create_epilog_for_reduction): If we split the reduction, use the result in Case 3 too.
Re: switch statement type incompatibilities ?
On 10/29/18 1:30 PM, Richard Biener wrote: On October 29, 2018 6:20:25 PM GMT+01:00, Andrew MacLeod wrote: What is valid in a switch statement for type compatibility? I would have expected it to follow what appears to be the gimple "standard" of allowing types that pass the "useless_type_convserion_p()" test. I am doing some switch analysis and an triggering a failure in ADA when the gimple_switch_index() is a signed 64 bit value and the case labels are only 32 bit integers. I would have expected that these needed to be the same precision? I don't seem to get this failure anywhere else. They should be the same type (types_ compatible_p), the same conatraint as operands of comparisons. IIRC we have some checking somewhere - eventually it just checks whether the constants fit in the index type. Fails that test too. (gdb) p types_compatible_p ($19, $16->typed.type) $26 = false (gdb) p types_compatible_p ($16->typed.type, $19) $27 = false now clearly the 32 bit index fit within the 64 bit index, and the default labels handles the rest.. but I'll look and see if I can find why this isnt triggering some checking code somewhere... Andrew (gdb) p print_gimple_stmt (stderr, sw, 0, 0) switch (_22) [67.00%], case 1: [33.00%]> (gdb) p gimple_switch_index (sw) $16 = (tree_node *) 0x7fffee3593f0 (gdb) p print_generic_expr (stderr, $16, 0) _22 (gdb) p print_generic_expr (stderr, $16->typed.type, 0) SIGNED_64 << signed 64 bit index low is the value of CASE_LOW() (gdb) p print_generic_expr (stderr, low, 0) 1 (gdb) p low->typed.type $19 = (tree) 0x7fffefacf5e8 (gdb) p print_generic_expr (stderr, $19, 0) integer (gdb) p low->typed.type->type_common.precision $22 = 32 <<< 32 bit case label (gdb) p type->type_common.precision $23 = 64 (gdb) p useless_type_conversion_p ($16->typed.type, $19) $24 = false (gdb) p useless_type_conversion_p ($19, $16->typed.type) $25 = false Is this valid? If so I'll do the promotion myself but this fails the "is_useless_type_conversion_p ()" test Andrew
Re: switch statement type incompatibilities ?
On October 29, 2018 6:20:25 PM GMT+01:00, Andrew MacLeod wrote: >What is valid in a switch statement for type compatibility? > > I would have expected it to follow what appears to be the gimple >"standard" of allowing types that pass the >"useless_type_convserion_p()" test. > >I am doing some switch analysis and an triggering a failure in ADA when > >the gimple_switch_index() is a signed 64 bit value and the case labels >are only 32 bit integers. I would have expected that these needed to >be >the same precision? I don't seem to get this failure anywhere else. They should be the same type (types_ compatible_p), the same conatraint as operands of comparisons. IIRC we have some checking somewhere - eventually it just checks whether the constants fit in the index type. >(gdb) p print_gimple_stmt (stderr, sw, 0, 0) > >switch (_22) [67.00%], case 1: [33.00%]> > > >(gdb) p gimple_switch_index (sw) >$16 = (tree_node *) 0x7fffee3593f0 >(gdb) p print_generic_expr (stderr, $16, 0) >_22 >(gdb) p print_generic_expr (stderr, $16->typed.type, 0) >SIGNED_64 << signed >64 >bit index > >low is the value of CASE_LOW() > >(gdb) p print_generic_expr (stderr, low, 0) >1 >(gdb) p low->typed.type >$19 = (tree) 0x7fffefacf5e8 >(gdb) p print_generic_expr (stderr, $19, 0) >integer >(gdb) p low->typed.type->type_common.precision >$22 = 32 <<< 32 bit case label >(gdb) p type->type_common.precision >$23 = 64 > >(gdb) p useless_type_conversion_p ($16->typed.type, $19) >$24 = false >(gdb) p useless_type_conversion_p ($19, $16->typed.type) >$25 = false > > >Is this valid? If so I'll do the promotion myself but this fails >the >"is_useless_type_conversion_p ()" test > >Andrew
switch statement type incompatibilities ?
What is valid in a switch statement for type compatibility? I would have expected it to follow what appears to be the gimple "standard" of allowing types that pass the "useless_type_convserion_p()" test. I am doing some switch analysis and an triggering a failure in ADA when the gimple_switch_index() is a signed 64 bit value and the case labels are only 32 bit integers. I would have expected that these needed to be the same precision? I don't seem to get this failure anywhere else. (gdb) p print_gimple_stmt (stderr, sw, 0, 0) switch (_22) [67.00%], case 1: [33.00%]> (gdb) p gimple_switch_index (sw) $16 = (tree_node *) 0x7fffee3593f0 (gdb) p print_generic_expr (stderr, $16, 0) _22 (gdb) p print_generic_expr (stderr, $16->typed.type, 0) SIGNED_64 << signed 64 bit index low is the value of CASE_LOW() (gdb) p print_generic_expr (stderr, low, 0) 1 (gdb) p low->typed.type $19 = (tree) 0x7fffefacf5e8 (gdb) p print_generic_expr (stderr, $19, 0) integer (gdb) p low->typed.type->type_common.precision $22 = 32 <<< 32 bit case label (gdb) p type->type_common.precision $23 = 64 (gdb) p useless_type_conversion_p ($16->typed.type, $19) $24 = false (gdb) p useless_type_conversion_p ($19, $16->typed.type) $25 = false Is this valid? If so I'll do the promotion myself but this fails the "is_useless_type_conversion_p ()" test Andrew
Re: "aligned" attribute with too-large argument
> On Oct 29, 2018, at 11:18 AM, Paul Koning wrote: > > ... > >> That said, attribute problems aren't handled perfectly consistently >> in GCC. Some result in errors, others in warnings, and some are >> silently ignored. I've been tracking the problems I notice in >> Bugzilla (those with "aligned" in their title are: 87524, 84185, >> 82914, 81566, 69502, 65055, 61939). In my view, silently ignoring >> problems without as much as a warning is a bug. But whether they >> should result in warnings or errors can be debated on a case by >> case basis. For instance, it might be appropriate to give >> an error when a negative alignment is specified but just a warning >> when the specified alignment is less than the minimum for the symbol >> for the target. For the case you mention I think an argument could >> be for either, but given the check_user_alignment handling I'd say >> an error would seem to be in line with the current practice. >> >> Martin > > Ok, I'll enter a PR. Done. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 paul
Re: "aligned" attribute with too-large argument
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>> for the platform. But when applied to functions, there is no error check.
>> The same applies to label alignment (from the -falign-labels switch).
>>
>> The result is an ICE in my target code because it is asked to output
>> assembly language for an alignment not supported by the target.
>>
>> Should these cases also produce error messages? Or should the back end
>> ignore attempts to align too much?
>
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
>
> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
> {
> error ("requested alignment is too large");
> return -1;
> }
>
> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).
I forgot to attach it. Here it is.
paul
testalign.c
Description: Binary data
Re: "aligned" attribute with too-large argument
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>> for the platform. But when applied to functions, there is no error check.
>> The same applies to label alignment (from the -falign-labels switch).
>>
>> The result is an ICE in my target code because it is asked to output
>> assembly language for an alignment not supported by the target.
>>
>> Should these cases also produce error messages? Or should the back end
>> ignore attempts to align too much?
>
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
>
> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>{
> error ("requested alignment is too large");
> return -1;
>}
Yes, but that code merely verifies that the requested alignment can be
represented on the host doing the compiling.
> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).
The error I get for variables comes from varasm.c, align_variable:
if (align > MAX_OFILE_ALIGNMENT)
{
error ("alignment of %q+D is greater than maximum object "
"file alignment %d", decl,
MAX_OFILE_ALIGNMENT/BITS_PER_UNIT);
align = MAX_OFILE_ALIGNMENT;
}
There are some other references to MAX_OFILE_ALIGNMENT, but they all seem to be
related to variables. I would think that the same check should also be applied
to other objects that are mentioned in the output file, specifically code
(functions and labels).
I'll attach a test case. On Intel, the max alignment is 32768 so the
declaration of variable "ag" fails on the above error check. But if I comment
out that line, the function alignment is silently accepted and generates the
corresponding assembly file directive (".align 16"). And the assembler accepts
that because apparently 64k alignment IS allowed...
> That said, attribute problems aren't handled perfectly consistently
> in GCC. Some result in errors, others in warnings, and some are
> silently ignored. I've been tracking the problems I notice in
> Bugzilla (those with "aligned" in their title are: 87524, 84185,
> 82914, 81566, 69502, 65055, 61939). In my view, silently ignoring
> problems without as much as a warning is a bug. But whether they
> should result in warnings or errors can be debated on a case by
> case basis. For instance, it might be appropriate to give
> an error when a negative alignment is specified but just a warning
> when the specified alignment is less than the minimum for the symbol
> for the target. For the case you mention I think an argument could
> be for either, but given the check_user_alignment handling I'd say
> an error would seem to be in line with the current practice.
>
> Martin
Ok, I'll enter a PR.
paul
Re: "aligned" attribute with too-large argument
On 10/29/2018 07:45 AM, Paul Koning wrote:
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large for
the platform. But when applied to functions, there is no error check. The
same applies to label alignment (from the -falign-labels switch).
The result is an ICE in my target code because it is asked to output assembly
language for an alignment not supported by the target.
Should these cases also produce error messages? Or should the back end ignore
attempts to align too much?
check_user_alignment() in c-attribs.c rejects excessive alignments
the same for functions and variables:
else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
{
error ("requested alignment is too large");
return -1;
}
so I don't immediately see where this inconsistency comes from
Is there different/more restrictive handling for variables in
the back end? (a test case would be great).
That said, attribute problems aren't handled perfectly consistently
in GCC. Some result in errors, others in warnings, and some are
silently ignored. I've been tracking the problems I notice in
Bugzilla (those with "aligned" in their title are: 87524, 84185,
82914, 81566, 69502, 65055, 61939). In my view, silently ignoring
problems without as much as a warning is a bug. But whether they
should result in warnings or errors can be debated on a case by
case basis. For instance, it might be appropriate to give
an error when a negative alignment is specified but just a warning
when the specified alignment is less than the minimum for the symbol
for the target. For the case you mention I think an argument could
be for either, but given the check_user_alignment handling I'd say
an error would seem to be in line with the current practice.
Martin
"aligned" attribute with too-large argument
I noticed an inconsistency in the handling of the aligned attribute. When applied to variables, I get an error message if the alignment is too large for the platform. But when applied to functions, there is no error check. The same applies to label alignment (from the -falign-labels switch). The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target. Should these cases also produce error messages? Or should the back end ignore attempts to align too much? paul
Re: Tests Failing On x86_64
Patches should be sent to the gcc-patches list, not this one, thanks. On Mon, 29 Oct 2018 at 02:28, nick wrote: > > Greetings all, > > I am getting failing tests when running with: > make bootstrap > make -k check > > The only code I am running is the below patch: > From 8c26b03c27912a367af52fd1e48eafb9b934fdf5 Mon Sep 17 00:00:00 2001 > From: Nicholas Krause > Date: Sun, 28 Oct 2018 22:23:35 -0400 > Subject: [PATCH] Fix bug 86293 > > This fixes the bug on the gcc bugzilla with id, 86293. Basically > a variable is undefined in certain build configuration scentarios > and therefore must be enabled with the attribute marco and the > flag, unused for it to avoid this build error. > > Signed-off-by: Nicholas Krause > --- > libitm/method-serial.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libitm/method-serial.cc b/libitm/method-serial.cc > index e4804946a34..ab23d0b5660 100644 > --- a/libitm/method-serial.cc > +++ b/libitm/method-serial.cc > @@ -306,7 +306,7 @@ GTM::gtm_thread::serialirr_mode () >// We're already serial, so we don't need to ensure privatization > safety >// for other transactions here. >gtm_word priv_time = 0; > - bool ok = disp->trycommit (priv_time); > + bool ok __attribute__((unused)) = disp->trycommit (priv_time); >// Given that we're already serial, the trycommit better work. >assert (ok); > } > -- > 2.17.1 > > It seems to be failing in Running > /home/nick/obdjir/../gcc/libatomic/testsuite/libatomic.c/c.exp ... > as this is the last thing I see but it could be a mistake in my code or > something else. It does > build gcc find through so it seems to be tests failing that are not expected. > Thoughts? > > Cheers, > > Nick
Re: Bug 87663 / Advice needed
On Mon, 29 Oct 2018 at 09:49, Lukas Mosimann wrote: > > Hi all, > > I am trying to solve the afore-mentioned issue > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663 and I need your help. > Manuel kindly pointed me to the mailing list and adviced me to add the > maintainers to CC. His suggestion was to add the C++ maintainers, not the global reviewers. I've changed the CC list for you. >I summed the state of investigation in comment 7 - > you can skip the previous comments to save your time. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663#c7 . > > Is there anyone that can help me tackling this issue and comment on my > observations? I would love to solve this issue - if this is an actual > issue at all - and I am willing to spend time on it, but I need advice > from a more experienced gcc developer as I am new on this specific code. > > Kind regards, > Lukas
Bug 87663 / Advice needed
Hi all, I am trying to solve the afore-mentioned issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663 and I need your help. Manuel kindly pointed me to the mailing list and adviced me to add the maintainers to CC. I summed the state of investigation in comment 7 - you can skip the previous comments to save your time. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663#c7 . Is there anyone that can help me tackling this issue and comment on my observations? I would love to solve this issue - if this is an actual issue at all - and I am willing to spend time on it, but I need advice from a more experienced gcc developer as I am new on this specific code. Kind regards, Lukas
Re:C to Forth compiler
ping :-) -- zhoupeng At 2018-10-27 18:07:25, "zhoupeng" wrote: >Hi all, > >Is there compiler implementions or papers on C to Forth ? > >Thank you for any reply. > >Best, >-- >ZhouPeng
Re: references to individual options in GCC manual
On Okt 25 2018, Martin Sebor wrote: > I was also hoping not to have to add @anchor (since some sort > of anchors must already exist for the Index to work), and for The indices use line numbers. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
