Question about PR preprocessor/60723
I am trying to understand the status of this bug and the patch
that fixes it. It looks like a patch was submitted and checked
in for 5.0 to fix the problem reported and I see the new
behavior caused by the patch in GCC 5.X compilers. This behavior
caused a number of issues with configures and scripts that examined
preprocessed output as is mentioned in the bug report for PR 60723.
There was a later bug, 64864, complaining about the behavior and
that was closed as invalid.
But when I look at GCC 6.X or ToT compilers I do not see the same
behavior as 5.X. Was this patch reverted or was a new patch submitted
that undid some of this patches behavior? I couldn't find any revert or
new patch to replace the original one so I am not sure when or why
the code changed back after the 5.X releases.
Here is a test case that I am preprocessing with g++ -E:
#include
class foo {
void operator= ( bool bit);
operator bool() const;
};
GCC 5.4 breaks up the operator delcarations with line markers and GCC 6.2
does not.
Steve Ellcey
sell...@caviumnetworks.com
Re: [RFC] GCC port for ARM's Scalable Vector Extension
Richard Sandiford writes: > We have various other changes that aren't yet in the branch. The two > main ones are: > > (a) Support for gather loads and scatter stores. This includes support > for using gathers and scatters for strided loads and stores, or for > grouped loads and stores whose group size is too large for a more > efficient approach. > > (b) Support for vectorising uncounted loops, i.e. those in which the number > of iterations isn't known before the loop starts. This has two modes: > > (i) Use alignment to avoid partial faults in speculative loads, > if alignment is reachable for all loads and if there are no other > statements with side effects. > > (ii) Use the SVE first-faulting instruction for general speculative > loads. This is the more general case and works regardless of > alignment. > > We hope to upload these changes to the branch soon. FWIW, I've now uploaded those other changes to the branch. The commit messages use: [Branch only patch -- not intended for trunk in its current state] to mark the patches that we know need tidying up a bit for trunk. I didn't send them to gcc-patches@ because I thought they would be noise. The new patches span the range r243045:r243080 inclusive. Thanks, Richard
Re: Aliasing of arrays
On Wed, 30 Nov 2016, Richard Biener wrote: > but that probably shouldn't apply to array types. The idea is that > objects of the same type cannot overlap. Maybe Joseph can clarify whether > and array object of known size really constitutes an object in that sense. This is one of the ambiguous cases about which objects are relevant for type-based aliasing rules. I think it's best not to optimize this (that is, to treat the objects as being the individual array elements, so the arrays can overlap by an exact multiple of the element size - meaning the ultimate element size in the case of multidimensional arrays, so e.g. two int[4][5] arrays could be offset by one int from each other). -- Joseph S. Myers jos...@codesourcery.com
Re: [libgomp] No references to env.c -> no libgomp construction
- Alexander Monakov schrieb: > Hello, > > On Tue, 29 Nov 2016, Sebastian Huber wrote: > > * env.c: Split out ICV definitions into... > > * icv.c: ...here (new file) and... > > * icv-device.c: ...here. New file. > > > > the env.c contains now only local symbols (at least for target *-rtems*-*): > > > [...] > > > > Thus the libgomp constructor is not linked in into executables. > > Thanks for the report. This issue affects only static libgomp.a (and not on > NVPTX where env.c is deliberately empty). > > I think the minimal solution here is to #include from icv.c instead of > compiling it separately (using <> inclusion rather than "" so in case of NVPTX > we pick up the empty config/nvptx/env.c from toplevel icv.c). > > A slightly more involved but perhaps a preferable approach is to remove > config/nvptx/env.c, introduce LIBGOMP_OFFLOADED_ONLY macro, and use it to > guard inclusion of env.c from icv.c (which then can use the #include "env.c" > form). I guess its sufficient to move pthread_attr_t gomp_thread_attr; from team.c (NVPTX seems to provide its own team.c) to env.c. This generates a reference from team.c to env.c and the constructor is pulled in. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Aliasing of arrays
On Wed, Nov 30, 2016 at 2:19 PM, Alexander Cherepanov
wrote:
> Hi!
>
> Pascal Cuoq communicated to me the following example:
>
> int ar1(int (*p)[3], int (*q)[3])
> {
> (*p)[0] = 1;
> (*q)[1] = 2;
> return (*p)[0];
> }
>
> gcc of versions 4.9.2 and 7.0.0 20161129 optimize it with -O2 on the premise
> that elements with different indices don't alias:
>
> :
>0: c7 47 0c 01 00 00 00movl $0x1,0xc(%rdi)
>7: b8 01 00 00 00 mov$0x1,%eax
>c: c7 46 10 02 00 00 00movl $0x2,0x10(%rsi)
> 13: c3 retq
>
> That's fine. But then I expect that gcc will also assume that arrays of
> different known lengths don't alias, i.e. that gcc will optimize this
> example:
>
> int ar2(int (*p)[8], int (*q)[7]) {
> (*p)[3] = 1;
> (*q)[3] = 2;
> return (*p)[3];
> }
>
> But this is not optimized:
>
> 0020 :
> 20: c7 47 0c 01 00 00 00movl $0x1,0xc(%rdi)
> 27: c7 46 0c 02 00 00 00movl $0x2,0xc(%rsi)
> 2e: 8b 47 0cmov0xc(%rdi),%eax
>
> Is this behavior fully intentional, is the first example optimized too
> aggressively, is an optimization missed in the second example, or is the
> situation more complex?
I think it's a bug that we optimize ar1. We run into
static bool
indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
...
/* If both references are through the same type, they do not alias
if the accesses do not overlap. This does extra disambiguation
for mixed/pointer accesses but requires strict aliasing. */
if ((TREE_CODE (base1) != TARGET_MEM_REF
|| (!TMR_INDEX (base1) && !TMR_INDEX2 (base1)))
&& (TREE_CODE (base2) != TARGET_MEM_REF
|| (!TMR_INDEX (base2) && !TMR_INDEX2 (base2)))
&& same_type_for_tbaa (TREE_TYPE (base1), TREE_TYPE (ptrtype1)) == 1
&& same_type_for_tbaa (TREE_TYPE (base2), TREE_TYPE (ptrtype2)) == 1
&& same_type_for_tbaa (TREE_TYPE (ptrtype1),
TREE_TYPE (ptrtype2)) == 1)
return ranges_overlap_p (offset1, max_size1, offset2, max_size2);
but that probably shouldn't apply to array types. The idea is that
objects of the same type cannot overlap. Maybe Joseph can clarify whether
and array object of known size really constitutes an object in that sense.
For the ar2 case the types are not equal and thus we do not use that trick
(and all array types irrespective of size get the same alias set, so
TBAA doesn't
apply here).
Richard.
>
> --
> Alexander Cherepanov
Aliasing of arrays
Hi!
Pascal Cuoq communicated to me the following example:
int ar1(int (*p)[3], int (*q)[3])
{
(*p)[0] = 1;
(*q)[1] = 2;
return (*p)[0];
}
gcc of versions 4.9.2 and 7.0.0 20161129 optimize it with -O2 on the
premise that elements with different indices don't alias:
:
0: c7 47 0c 01 00 00 00movl $0x1,0xc(%rdi)
7: b8 01 00 00 00 mov$0x1,%eax
c: c7 46 10 02 00 00 00movl $0x2,0x10(%rsi)
13: c3 retq
That's fine. But then I expect that gcc will also assume that arrays of
different known lengths don't alias, i.e. that gcc will optimize this
example:
int ar2(int (*p)[8], int (*q)[7]) {
(*p)[3] = 1;
(*q)[3] = 2;
return (*p)[3];
}
But this is not optimized:
0020 :
20: c7 47 0c 01 00 00 00movl $0x1,0xc(%rdi)
27: c7 46 0c 02 00 00 00movl $0x2,0xc(%rsi)
2e: 8b 47 0cmov0xc(%rdi),%eax
Is this behavior fully intentional, is the first example optimized too
aggressively, is an optimization missed in the second example, or is the
situation more complex?
--
Alexander Cherepanov
