Re: Switch to ISL 0.16.1
On Sun, 12 Jun 2016, Gerald Pfeifer wrote: > Hi Richi, > > On Mon, 15 Feb 2016, Richard Biener wrote: > > the following patch switches download_prerequesites to use ISL 0.16.1 > > (just put that into infrastructure/). > > > > I've verified it works for me (on the gcc-5 branch and trunk). > > > > Ok? > > I did not see any responses, nor the patch committed, and have > seen ISL 0.16 being used more widely (and it is one of the versions > documented in gcc/doc/install.texi), so "Go ahead" I'd say. > > No point in sticking to old versions via download_prerequisites, > when general users would already be on newer versions. Committed. Richard. > Gerald > > > Index: contrib/download_prerequisites > > === > > --- contrib/download_prerequisites (revision 233418) > > +++ contrib/download_prerequisites (working copy) > > @@ -48,7 +48,7 @@ ln -sf $MPC mpc || exit 1 > > > > # Necessary to build GCC with the Graphite loop optimizations. > > if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then > > - ISL=isl-0.15 > > + ISL=isl-0.16.1 > > > >wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2 || exit 1 > >tar xjf $ISL.tar.bz2 || exit 1 > > > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Return value on MIPS N64 ABI
Hi,
Looks the return value of TestNewA is passed on $f0/$f2 from
disassembly code. I don't known why the return value of TestNewB is
passed on $v0/$v1? a bug?
229 00012c40 <_Z8TestNewAv>:
23012c40: 3c030002lui v1,0x2
23112c44: 0079182ddaddu v1,v1,t9
23212c48: 64638400daddiu v1,v1,-31744
23312c4c: dc628050ld v0,-32688(v1)
23412c50: 67bdffe0daddiu sp,sp,-32
23512c54: d4400e68ldc1$f0,3688(v0)
23612c58: dc628050ld v0,-32688(v1)
23712c5c: 67bd0020daddiu sp,sp,32
23812c60: 03e8jr ra
23912c64: d4420e70ldc1$f2,3696(v0)
240
241 00012c68 <_Z8TestNewBv>:
24212c68: 3c0307f9lui v1,0x7f9
24312c6c: 3c0207f7lui v0,0x7f7
24412c70: 3463ori v1,v1,0x
24512c74: 3442ori v0,v0,0x
24612c78: 00031cb8dsllv1,v1,0x12
24712c7c: 000214b8dsllv0,v0,0x12
24812c80: 3463cccdori v1,v1,0xcccd
24912c84: 3442cccdori v0,v0,0xcccd
25012c88: 67bdfff0daddiu sp,sp,-16
25112c8c: 00031c78dsllv1,v1,0x11
25212c90: 00021478dsllv0,v0,0x11
25312c94: 6463999adaddiu v1,v1,-26214
25412c98: 6442999adaddiu v0,v0,-26214
25512c9c: 03e8jr ra
25612ca0: 67bd0010daddiu sp,sp,16
// test.cpp
// gcc -march=mips64r2 -mabi=64 -O3 -o test test.cpp
#include
class TestA
{
public:
double l;
double h;
TestA(double l, double h) : l(l), h(h) {}
};
class TestB : public TestA
{
public:
TestB(const TestA& a) : TestA(a) {}
};
TestA
TestNewA(void)
{
return TestA(0.1, 0.2);
}
TestB
TestNewB(void)
{
return TestA(0.1, 0.2);
}
int
main(int argch, char *argv[])
{
TestA a = TestNewA();
printf("%lf, %lf\n", a.l, a.h);
TestB b = TestNewB();
printf("%lf, %lf\n", b.l, b.h);
return 0;
}
Re: avr-gcc: incorrect first operand of a subreg? (PR71103)
Ping!
On Tue, 2016-05-31 at 19:47 +, Pitchumani Sivanupandi wrote:
> Hi,
>
> avr-gcc was crashing for below test case.
> command line: avr-gcc -mmcu=atmega328p -O1 test.c
>
> struct ResponseStruct{
> unsigned char responseLength;
> char *response;
> };
>
> static char response[5];
> struct ResponseStruct something(){
> struct ResponseStruct returnValue;
> returnValue.responseLength = 5;
> returnValue.response = response + 1;
> return returnValue;
> }
>
> Output:
> >
> > test.c:12:1: error: unrecognizable insn:
> > }
> > ^
> > (insn 6 5 7 2 (set (subreg:QI (reg:PSI 42 [ D.1499 ]) 1)
> > (subreg:QI (const:HI (plus:HI (symbol_ref:HI ("response")
> > [flags 0x2] )
> > (const_int -1 [0x
> > ]))) 0)) test.c:11 -1
> > (nil))
> > test.c:12:1: internal compiler error: in extract_insn, at
> > recog.c:2287
> > 0xd51195 _fatal_insn(char const*, rtx_def const*, char const*, int,
> > char const*)
> > /home/rudran/code/gcc/gcc/rtl-error.c:108
> Source operand is a subreg which has const operand as first operand.
> Subreg shall have pseudo, mem or hard registers as fist operand.
> Ref: https://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html
>
> For the reported case it has const expression. Isn't that incorrect?
> validate_subreg doesn't seem to reject this case. How can we avoid
> such
> case (avr target)?
>
> Regards,
> Pitchumani
RE: Return value on MIPS N64 ABI
Heiher writes:
> Looks the return value of TestNewA is passed on $f0/$f2 from disassembly
> code. I don't known why the return value of TestNewB is passed on
> $v0/$v1? a bug?
I believe this is an area where GNU strays from the N64 ABI definition but
is defacto standard. TestA is a struct of two floating point fields which
is passed and returned in FP registers. TestB is a struct of a struct of
two floating point fields (or at least I think that is the interpretation).
The ABI does say that this should be flattened and be seen as simply two
floating point fields but GCC does not and passes it in integer registers
instead. Or at least the ABI says this for arguments but not results.
The relevant bit of the ABI we are not adhering to is 'Structs,unions' on
page 7 which covers arguments, however the corresponding text for results
does not include the part about ignoring the struct field structure
when determining between floating point and integer chunks.
https://dmz-portal.ba.imgtec.org/mw/images/6/6f/007-2816-005-1.pdf
FWIW: Clang/LLVM ABI implementation matches GCC in this regard as we run
cross linking tests and use GCC as 'correct'.
Thanks,
Matthew
> 229 00012c40 <_Z8TestNewAv>:
> 23012c40: 3c030002lui v1,0x2
> 23112c44: 0079182ddaddu v1,v1,t9
> 23212c48: 64638400daddiu v1,v1,-31744
> 23312c4c: dc628050ld v0,-32688(v1)
> 23412c50: 67bdffe0daddiu sp,sp,-32
> 23512c54: d4400e68ldc1$f0,3688(v0)
> 23612c58: dc628050ld v0,-32688(v1)
> 23712c5c: 67bd0020daddiu sp,sp,32
> 23812c60: 03e8jr ra
> 23912c64: d4420e70ldc1$f2,3696(v0)
> 240
> 241 00012c68 <_Z8TestNewBv>:
> 24212c68: 3c0307f9lui v1,0x7f9
> 24312c6c: 3c0207f7lui v0,0x7f7
> 24412c70: 3463ori v1,v1,0x
> 24512c74: 3442ori v0,v0,0x
> 24612c78: 00031cb8dsllv1,v1,0x12
> 24712c7c: 000214b8dsllv0,v0,0x12
> 24812c80: 3463cccdori v1,v1,0xcccd
> 24912c84: 3442cccdori v0,v0,0xcccd
> 25012c88: 67bdfff0daddiu sp,sp,-16
> 25112c8c: 00031c78dsllv1,v1,0x11
> 25212c90: 00021478dsllv0,v0,0x11
> 25312c94: 6463999adaddiu v1,v1,-26214
> 25412c98: 6442999adaddiu v0,v0,-26214
> 25512c9c: 03e8jr ra
> 25612ca0: 67bd0010daddiu sp,sp,16
>
> // test.cpp
> // gcc -march=mips64r2 -mabi=64 -O3 -o test test.cpp #include
>
> class TestA
> {
> public:
> double l;
> double h;
>
> TestA(double l, double h) : l(l), h(h) {} };
>
> class TestB : public TestA
> {
> public:
> TestB(const TestA& a) : TestA(a) {} };
>
> TestA
> TestNewA(void)
> {
> return TestA(0.1, 0.2);
> }
>
> TestB
> TestNewB(void)
> {
> return TestA(0.1, 0.2);
> }
>
> int
> main(int argch, char *argv[])
> {
> TestA a = TestNewA();
> printf("%lf, %lf\n", a.l, a.h);
>
> TestB b = TestNewB();
> printf("%lf, %lf\n", b.l, b.h);
>
> return 0;
> }
Re: [Patch 0,1a] Improving effectiveness and generality of autovectorization using unified representation.
On Thursday 09 June 2016 05:45 PM, Richard Biener wrote: On Thu, Jun 9, 2016 at 10:54 AM, Richard Biener wrote: On Tue, Jun 7, 2016 at 3:59 PM, Sameera Deshpande wrote: Hi Richard, This is with reference to our discussion at GNU Tools Cauldron 2015 regarding my talk titled "Improving the effectiveness and generality of GCC auto-vectorization." Further to our prototype implementation of the concept, we have started implementing this concept in GCC. We are following incremental model to add language support in our front-end, and corresponding back-end (for auto-vectorizer) will be added for feature completion. Looking at the complexity and scale of the project, we have divided this project into subtasks listed below, for ease of implementation, testing and review. 0. Add new pass to perform autovectorization using unified representation - Current GCC framework does not give complete overview of the loop to be vectorized : it either breaks the loop across body, or across iterations. Because of which these data structures can not be reused for our approach which gathers all the information of loop body at one place using primitive permute operations. Hence, define new data structures and populate them. 1. Add support for vectorization of LOAD/STORE instructions a. Create permute order tree for the loop with LOAD and STORE instructions for single or multi-dimensional arrays, aggregates within nested loops. b. Basic transformation phase to generate vectorized code for the primitive reorder tree generated at stage 1a using tree tiling algorithm. This phase handles code generation for SCATTER, GATHER, stridded memory accesses etc. along with permute instruction generation. 2. Implementation of k-arity promotion/reduction : The permute nodes within primitive reorder tree generated from input program can have any arity. However, the target can support maximum of arity = 2 in most of the cases. Hence, we need to promote or reduce the arity of permute order tree to enable successful tree tiling. 3. Vector size reduction : Depending upon the vector size for target, reduce vector size per statement and adjust the loop count for vectorized loop accordingly. 4. Support simple arithmetic operations : a. Add support for analyzing statements with simple arithmetic operations like +, -, *, / for vectorization, and create primitive reorder tree with compute_op. b. Generate vector code for primitive reorder tree generated at stage 4a using tree tiling algorithm - here support for complex patterns like multiply-add should be checked and appropriate instruction to be generated. 5. Support reduction operation : a. Add support for reduction operation analysis and primitive reorder tree generation. The reduction operation needs special handling, as the finish statement should COLLAPSE the temporary reduction vector TEMP_VAR into original reduction variable. b. The code generation for primitive reorder tree does not need any handling - as reduction tree is same as tree generated in 4a, with only difference that in 4a, the destination is MEMREF (because of STORE operation) and for reduction it is TEMP_VAR. At this stage, generate code for COLLAPSE node in finish statements. 6. Support other vectorizable statements like complex arithmetic operations, bitwise operations, type conversions etc. a. Add support for analysis and primitive reorder tree generation. b. Vector code generation. 7. Cost effective tree tiling algorithm : Till now, the tree tiling is happening without considering cost of computation. However, there can be multiple target instructions covering the tree - hence, instead of picking first matched largest instruction cover, select the instruction cover based on cost of instruction given in .md for the target. 8. Optimizations on created primitive reorder tree : This stage is open ended, and depending upon perf analysis, the scope of it can be defined. The current patch I have attached herewith handles stage 0 and 1a : Adds new pass to perform autovectorization using unified representation, defines new data structures to cater to this requirement and creates primitive reorder tree for LOAD/STORE instructions within the loop. The whole loop is represented using the ITER_NODE, which have information about - The preparatory statements for vectorization to be executed before entering the loop (like initialization of vectors, prepping for reduction operations, peeling etc.) - Vectorizable loop body represented as PRIMOP_TREE (primitive reordering tree) - Final statements (For peeling, variable loop bound, COLLAPSE operation for reduction etc.) - Other loop attributes (loop bound, peeling needed, dependences, etc.) Memory accesses within a loop have definite repetitive pattern which can be captured using primitive permute operators which can be used to determine desired permute order for the vector computations. The PRI
gcc -gdwarf-2 -gstrict-dwarf produces bad debug_loc entries
I'm running into an issue with start/end values of debug_loc entries
being absolute addresses instead of offsets when a file is compiled
with -gdwarf-2 and -gstrict-dwarf and there are virtual methods in
that file. gcc 4.4.7, but I've seen it under 4.8'ish.
I'm new enough to dwarf stuff to not be 100% sure that this is a bug
vs. I'm just missing a field somewhere that indicates that these
debug_loc entries are in a different format but on the other hand,
readelf also seems confused about this.
An example file:
#include
struct class1
{
class1() { printf("blah\n"); }
virtual ~class1() { }
};
int main()
{
class1 c1;
return 0;
}
# g++ -gdwarf-2 -gstrict-dwarf -o foo foo.cpp
# readelf -W -w -x .debug_loc foo > foo.debuginfo
from the foo.debuginfo file:
The compile_unit shows 0x400664 as its lowpc:
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c> DW_AT_producer: (indirect string, offset: 0xab): GNU
C++ 4.4.7 20120313 (Red Hat 4.4.7-17)
<10> DW_AT_language: 4(C++)
<11> DW_AT_name: (indirect string, offset: 0x29): foo.cpp
<15> DW_AT_comp_dir: (indirect string, offset: 0x41):
<19> DW_AT_low_pc : 0x400664
<21> DW_AT_high_pc : 0x400693
<29> DW_AT_stmt_list : 0x0
But the debug_loc section shows start addresses in the 0x8 range:
Contents of the .debug_loc section:
Offset BeginEnd Expression
00800cf8 00800cf9 (DW_OP_breg7: 8)
00800cf9 00800cfc (DW_OP_breg7: 16)
00800cfc 00800d1a (DW_OP_breg6: 16)
00800d1a 00800d1b (DW_OP_breg7: 8)
(800cf8 == lowpc 0x400664 + 0x400694)
Hex dump of section '.debug_loc':
0x 94064000 95064000 ..@...@.
0x0010 02007708 95064000 98064000 ..w...@...@.
0x0020 02007710 98064000 ..w...@.
0x0030 b6064000 02007610 b6064000 ..@...v...@.
0x0040 b7064000 02007708 ..@...w.
Is this is a known bug or issue or am I missing something?
Re: _Bool and trap representations
On 2016-06-08 17:37, Martin Sebor wrote:
On 06/08/2016 12:36 AM, Alexander Cherepanov wrote:
Hi!
If a variable of type _Bool contains something different from 0 and 1
its use amounts to UB in gcc and clang. There is a couple of examples in
[1] ([2] is also interesting).
[1] https://github.com/TrustInSoft/tis-interpreter/issues/39
[2] https://github.com/TrustInSoft/tis-interpreter/issues/100
But my question is about the following example:
--
#include
int main()
{
_Bool b;
*(char *)&b = 123;
printf("%d\n", *(char *)&b);
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
123
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1
--
gcc version: gcc (GCC) 7.0.0 20160604 (experimental)
Similar example with long double:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71522
It seems that padding in _Bool is treated as permanently unspecified. Is
this behavior intentional? What's the theory behind it?
One possible explanations is C11, 6.2.6.2p1, which reads: "The values of
any padding bits are unspecified." But it's somewhat a stretch to
conclude from it that the values of padding bits cannot be specified
even with explicit assignment.
Another possible approach is to refer to Committee Response for Question
1 in DR 260 which reads: "Values may have any bit-pattern that validly
represents them and the implementation is free to move between alternate
representations (for example, it may normalize pointers, floating-point
representations etc.). [...] the actual bit-pattern may change without
direct action of the program."
There has been quite a bit of discussion among the committee on
this subject lately (the last part is the subject of DR #451,
though it's discussed in the context of uninitialized objects
with indeterminate values).
Are there notes from these discussions or something?
I would hesitate to call it
consensus but I think it would be fair to say that the opinion
of the vocal majority is that implementations aren't intended
to spontaneously change valid (i.e., determinate) representations
of objects in the absence of an access to the value of the object.
Thanks for the info. IMHO this part of DR 260 has even more serious
consequences than the part about pointer provenance. It effectively
prohibits manual byte-by-byte (or any non-atomic) copying of objects for
types like long double. If an implementation decides to normalize a
value in a variable during copying it will see an inconsistent
representation, e.g. a trap representation. It's a sure way to get total
garbage. I don't know if allowing implementations to normalize values is
useful but the current language in DR 260 allows too much.
As for valid/determinate representation this is another place where
distinction between a value and a representation is worth stressing.
Uninitialized variables are a clear case -- both its value and
representation are indeterminate. But what if we set some part of
representation of a variable -- it doesn't yet have a determinate value
but we want the part that we have set to be preserved. Another
interesting example is a pointer after free() -- its representation is
kinda determinate but its value is indeterminate.
--
Alexander Cherepanov
JonY appointed Cygwin and mingw-w64 maintainer
I am pleased to announce that the GCC Steering Committee has appointed Jon Y as Cygwin and mingw-w64 maintainer. Please join me in congratulating Jon on his new role. Jon, please update your listing in the MAINTAINERS file. Happy hacking! David
Re: _Bool and trap representations
On Mon, 13 Jun 2016, Alexander Cherepanov wrote: > Thanks for the info. IMHO this part of DR 260 has even more serious > consequences than the part about pointer provenance. It effectively prohibits > manual byte-by-byte (or any non-atomic) copying of objects for types like long > double. If an implementation decides to normalize a value in a variable during > copying it will see an inconsistent representation, e.g. a trap > representation. It's a sure way to get total garbage. I don't know if allowing No, that's not the case; even if representations can change during byte-by-byte copying, such copying of long double values is *still* safe. All long double values for x86 long double have exactly one valid representation in the value bits, and if the padding bits change during copying it doesn't matter; it's only representations that are already trap representations (unnormals, pseudo-* etc.) that might be interpreted inconsistently. Likewise for IBM long double; the only cases of more than one representation for a value are (a) a zero low part might have either sign (in which case an arbitrary choice of bytes from the two representations still gives a valid representation of the same value) and (b) the low part of a NaN is of no significance. -- Joseph S. Myers jos...@codesourcery.com
Re: _Bool and trap representations
On 2016-06-13 22:51, Joseph Myers wrote:
On Mon, 13 Jun 2016, Alexander Cherepanov wrote:
Thanks for the info. IMHO this part of DR 260 has even more serious
consequences than the part about pointer provenance. It effectively prohibits
manual byte-by-byte (or any non-atomic) copying of objects for types like long
double. If an implementation decides to normalize a value in a variable during
copying it will see an inconsistent representation, e.g. a trap
representation. It's a sure way to get total garbage. I don't know if allowing
No, that's not the case; even if representations can change during
byte-by-byte copying, such copying of long double values is *still* safe.
All long double values for x86 long double have exactly one valid
representation in the value bits, and if the padding bits change during
copying it doesn't matter; it's only representations that are already trap
representations (unnormals, pseudo-* etc.) that might be interpreted
inconsistently.
The problem is that parts of representations of two different ordinary
values can form a trap representation.
Suppose x = 1.0 and y = 0.0, i.e. they have the following
representations (from high bytes to low bytes):
padding signint & frac
& exp
|---| |---| |-|
x: 00 00 00 00 00 00 3f ff 80 00 00 00 00 00 00 00
y: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Suppose that we copy from x to y byte-by-byte starting from high bytes.
And suppose the normalization kicks in after copying 8 bytes. We have
already copied the sign and the exponent but haven't yet overwritten the
'Integer' bit of Significand so we have the following representation:
z: 00 00 00 00 00 00 3f ff 00 00 00 00 00 00 00 00
This is an unnormal and current gcc normalization converts it into 0.0
throwing the exponent away. Copying the remaining 8 bytes leads to a
pseudo-denormal:
w: 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00
But this is already a minor detail.
The code to see how gcc normalizes 'z':
--
#include
#include
int main()
{
long double d0, d;
memcpy(&d0,
"\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00",
sizeof d0);
d = d0;
printf("d = %Lf\n", d);
for (unsigned char *p = (unsigned char *)&d + sizeof d; p > (unsigned
char *)&d;)
printf("%02x ", *--p);
printf("\n");
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
d = 0.00
00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00
--
gcc version: gcc (GCC) 7.0.0 20160613 (experimental)
--
Alexander Cherepanov
Re: _Bool and trap representations
On Tue, 14 Jun 2016, Alexander Cherepanov wrote: > The problem is that parts of representations of two different ordinary values > can form a trap representation. Oh, you're talking about normalizing the destination rather than the source of the copy? -- Joseph S. Myers jos...@codesourcery.com
Re: _Bool and trap representations
On 2016-06-14 00:13, Joseph Myers wrote: On Tue, 14 Jun 2016, Alexander Cherepanov wrote: The problem is that parts of representations of two different ordinary values can form a trap representation. Oh, you're talking about normalizing the destination rather than the source of the copy? Yes. I don't see this problem with a current gcc so the problem is hypothetical AFAICT. -- Alexander Cherepanov
Re: CppCoreGuidelines warnings
On Sat, Jun 11, 2016 at 8:57 PM, Christopher Di Bella wrote: >> I'm currently waiting on approval from my employer before I move ahead >with anything > > My employer has given me the okay to contribute to gcc, provided that I > follow some fairly straightforward rules. Most of these things are given, > such as "don't contribute to gcc while at work", "don't put work code in your > contributions or vice versa", etc. Of course, my company needs to make it > clear that I understand these rules before I'm given a green light. > >> Note also that if you want to learn the process, small patches do not need >any legal papers > > I'm going to start with a few minor patches, which I refrained from until I > they gave approval, and then move up in the world. > >> You can coordinate with me about front end changes. > > I am hoping you mean compiler front-end (i.e. syntax, semantic, static > analysis, etc.), rather than application front-end (flags, etc.), as > the compiler front-end is the section I'm most interested in contributing to. Yes, that's right. > >> To incorporate the checks into GCC would probably involve changes to ... >the C++ library > > I'm also happy to contribute to both an improved C++ Standard Library and > stdlibc++, but don't want to spread myself too thin (I'm gearing my career for > compiler development, and thus would like to work on the front-end a little > more). Would it be better to work on this before, after, or in parallel with > the > front-end? That's really up to you. If you're most interested in the front end, starting there makes sense. > >> Currently yes, but it was supposed to be released as open source. >> Some of the C++ Core Guidelines checks are already implemented in >clang-tidy: > > Does this mean that in your opinion, we (mostly me) should contribute to > one of those projects instead, or are they just cool projects to watch? They might be interesting to look at, but we'd definitely like to have support for this in GCC. Jason
