Re: [GSoC] Question about unit tests
On Wed, 2014-06-25 at 20:25 +0600, Roman Gareev wrote: > Dear gcc contributors, > > could you please answer a few questions about unit tests? Is it > possible to use them in gcc? Or maybe there is some analogue? I would > be very grateful for your comments. In GCC we have a DejaGnu based test suite. It's not a framework like CppUnit but you can write unit tests in it, too. For more info see https://gcc.gnu.org/install/test.html http://www.delorie.com/gnu/docs/dejagnu/dejagnu_6.html and the various test case examples in the source tree under gcc/testsuite. Cheers, Oleg
Re: GCC 4.7.4 Released
On Thu, Jun 26, 2014 at 6:50 PM, Óscar Fuentes wrote: > Sergey Boldyrev writes: > >> I've tried to download the latest 4.7.4 version from >> ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.7.4 >> and couldn't successfully check the MD5 sum, >> which is given there in the "md5.sum" file. >> gcc-4.7.4.tar.gz appears OK, >> but gcc-4.7.4.tar.bz2 produces an error. > > Yup. > > $ md5sum gcc-4.7.4.tar.bz2 > 4c696da46297de6ae77a82797d2abe28 gcc-4.7.4.tar.bz2 > > md5.sum contains: > > 50aef90e4c24194451d98170d45d468e gcc-4.7.4.tar.bz2 > md5.sum is created by a cron job and in this case (happened in the past) it raced with the actual upload. I've removed the file which should re-generate it correctly. I also verified the actual md5sum of the file is the same as for the file I uploaded (so no modification happened). Richard.
Re: Question about GCC's standard dependent optimization
On Thu, Jun 26, 2014 at 10:13 PM, Jeff Law wrote:
> On 06/26/14 02:44, Bin.Cheng wrote:
>>
>> Hi,
>> I ran into PR60947, in which GCC understands the return value of
>> memset is the first argument passed in, according to standard, then
>> does optimization like below:
>> movip, sp
>> stmfdsp!, {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr, pc}
>> subfp, ip, #4
>> subsp, sp, #20
>> ldrr8, [r0, #112]
>> addr3, r8, #232
>> addr4, r8, #328
>> .L1064:
>> movr0, r3
>> movr1, #255
>> movr2, #8
>> blmemset
>> addr3, r0, #32 > cmpr3, r4
>> bne.L1064
>>
>> For X insn, GCC takes advantage of standard by using the returned r0
>> directly.
>>
>> My question is, is it always safe for GCC to do such optimization? Do
>> we have an option to disable such standard dependent optimization?
>
> Others have already answered this question.
>
> FWIW, I just locally added the capability to track equivalences between the
> destination argument to the various mem* str* functions and their return
> value in DOM. It triggers, but not terribly often. I'll be looking to see
> if the additional equivalences actually enable any optimizations before
> going through the full bootstrap and test.
>
> It doesn't help your testcase though since optimizer weakness you're showing
> is much later in the optimization pipeline. I wonder if you could model
> this as an implicit copy in IRA and try to encourage IRA to tie the hard reg
> output from memset to the pseudo.
Btw, we have the "fn spec" attribute and gimple_call_return_flags ()
which can return ERF_RETURNS_ARG and you can query which
one by masking with ERF_RETURN_ARG_MASK. That's how
calls.c figures this out. Note we miss to annotate builtins in
builtins.def with proper 'fn spec' attribute.
So rather than hard-coding we should annotate more functions
appropriately.
Richard.
>
> jeff
>
>
Re: Folding a bitfield in a union
On Fri, Jun 27, 2014 at 8:51 AM, Thomas Preud'homme
wrote:
> Greetings everybody,
>
> I'm seeking your advice on how to best solve a bug. The issue has to do with
> folding a bitfield contained in a union. Consider the following example:
>
> union U {
> unsigned int a:24;
> unsigned int b:20;
> } u = { .a = 0x345678 };
>
> int foo (void)
> {
> return u.b;
> }
>
> Currently, folding (fold_nonarray_ctor_reference and fold_ctor_reference)
> does the following:
>
> 1) Compute the difference between bit offset of a and b
> 2) Check that b's area is within a's area in memory
> 3) Do nothing if 1) yields a non-zero difference
> 4) Cast value stored in a according to the size of b by removing bits of
> highest weight (via VIEW_CONVERT_EXPR).
Fact is that 4) already is not working.
/* We are at the end of walk, see if we can view convert the
result. */
if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
/* VIEW_CONVERT_EXPR is defined only for matching sizes. */
&& operand_equal_p (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (ctor)), 0))
while it's true we don't check precision in the gimple-verifier
VIEW_CONVERT_EXPR isn't supposed to be applied to types
with same size but differing precision. VIEW_CONVERT_EXPR
is supposed to _not_ strip any excess bits! (it's supposed to do
"nothing").
fold_view_convert_expr might do the correct thing (but only possibly
because we now use wide_int here...).
> This does not work for big endian targets since bitfield respect byte
> endianness (and I support word endianness) when layed out in memory.
> So a would end up like this (highest addresses on the right):
>
> --
> | Ox34 | 0x56 | 0x78 |
> --
>
> b would be the first two byte and then 4 highest bits of the third byte,
> as if memory was a sequence of bits instead bytes with highest value
> bits at the lowest "bit address"
>
> So the expected result would be 0x34567 but a cast as does
> VIEW_CONVERT_EXPR would return 0x45678. Forbidding folding in such
> case for big endian would work but I've been looking about a way to
> make bitfield folding also work for big endian. The approach I've been
> taking so far is to enhance native_encode_integer and
> native_interpret_integer to take a start parameter and express start
> and len as addressing bits rather than byte. Then in
> fold_nonarray_ctor_reference whenever the constructor is for a
> bitfield, that bitfield is encoded with its bit offset and bit length to
> target memory layout, then interpreted to the host as its type qualifier
> (unsigned int in the above example). Finally, a call to fold_ternary with
> a subcode of BIT_FIELD_REF is made which will encode that integer to
> the target memory layout as the type qualifier and decode it according
> to the bit offset and bit length of bitfield b. Note that juste replacing
> VIEW_CONVERT_EXPR by BIT_FIELD_REF has the advantage of
> allowing folding in simpler solutions like a union of an integer and
> a char which is currently not folded even for little endian target.
Hmm. I wonder if the code behaves correctly for
union {
struct { a : 10; b : 6 } a;
struct { a : 8; b : 8 } b;
} u = { .a = { } };
and reading u.b.a or u.b.b?
That is, is fold_nonarray_ctor_reference doing the right thing with
consecutive bitfield fields?
Is the current code behaving correctly for size % BITS_PER_UNIT == 0?
If so that might be a good fix for branches (who cares about
constant folding bitfield constants ... not many, given the bug you
show).
> However this double conversion between host and target memory
> layout is unelegant and unefficient. I could do just one conversion
> completely in fold_nonarray_ctor_reference but somehow I feel it is
> not the right place to do it. As anybody a better advice?
I wonder if you have a patch to show us how unelegant it is?
Btw, another idea would be to support native_encode for the
whole CONSTRUCTOR and then use native_interpret with
offset/size. Of course for large CONSTRUCTORs that may
be prohibitive (but native_encode could get a start offset as well,
to skip uninteresting bytes).
Being able to native encode a CONSTRUCTOR could be
factored and re-used from asm output.
And it could be used to more efficiently store large aggregate
constant initializers (native encode it and compress it instead
of keeping CONSTRUCTOR).
So any incremental improvement to native_{encode/interpret}_expr
is good.
Richard.
> Best regards,
>
> Thomas Preud'homme
>
>
RE: Folding a bitfield in a union
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 5:32 PM
> > 4) Cast value stored in a according to the size of b by removing bits of
> > highest weight (via VIEW_CONVERT_EXPR).
>
> Fact is that 4) already is not working.
>
> /* We are at the end of walk, see if we can view convert the
> result. */
> if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
> /* VIEW_CONVERT_EXPR is defined only for matching sizes. */
> && operand_equal_p (TYPE_SIZE (type),
> TYPE_SIZE (TREE_TYPE (ctor)), 0))
>
> while it's true we don't check precision in the gimple-verifier
> VIEW_CONVERT_EXPR isn't supposed to be applied to types
> with same size but differing precision. VIEW_CONVERT_EXPR
> is supposed to _not_ strip any excess bits! (it's supposed to do
> "nothing").
Right but since ctor is an integer constant for a bitfield, this would check
the size of the integer type qualifier of the bitfield, which is the source
of the bug.
>
> Hmm. I wonder if the code behaves correctly for
>
> union {
> struct { a : 10; b : 6 } a;
> struct { a : 8; b : 8 } b;
> } u = { .a = { } };
>
> and reading u.b.a or u.b.b?
>
> That is, is fold_nonarray_ctor_reference doing the right thing with
> consecutive bitfield fields?
With my current approach it would for u.b.a but not for u.b.b. The reason
is that fold_ctor_reference will call fold_nonarray_ctor_reference as
long as the constructor is an aggregate type. So for u.b.a it will find the
constructor for u.a.a which completely contains u.b.a and it would work.
This indeed suggest going towards the support for aggregate int
native_encode_expr and native_interpret_expr.
>
> Is the current code behaving correctly for size % BITS_PER_UNIT == 0?
For primitive type (a bitfield could respect this constraint) It does
because the check in fold_ctor_reference would work correctly.
> If so that might be a good fix for branches (who cares about
> constant folding bitfield constants ... not many, given the bug you
> show).
The problem is not really that folding doesn't happen, but that it
happens and gives wrong result. Is wrong code generation (even for
bitfield) not serious enough?
>
> > However this double conversion between host and target memory
> > layout is unelegant and unefficient. I could do just one conversion
> > completely in fold_nonarray_ctor_reference but somehow I feel it is
> > not the right place to do it. As anybody a better advice?
>
> I wonder if you have a patch to show us how unelegant it is?
Not finished yet. I have improved native_interpret_integer but not
native_encode_integer yet. It took me a while to reason about
the various endianness (byte and word) of both target and host.
Hopefully doing native_encode_integer should be easier now.
However, since I have some other task with higher priority to
handle, I think I'll push something that disables folding for bitfield on
big endian target on Monday and continue working on this at some
later time.
> Btw, another idea would be to support native_encode for the
> whole CONSTRUCTOR and then use native_interpret with
> offset/size. Of course for large CONSTRUCTORs that may
> be prohibitive (but native_encode could get a start offset as well,
> to skip uninteresting bytes).
>
> Being able to native encode a CONSTRUCTOR could be
> factored and re-used from asm output.
>
> And it could be used to more efficiently store large aggregate
> constant initializers (native encode it and compress it instead
> of keeping CONSTRUCTOR).
That would also allow to fold example such as the one you
mentioned above. However that's more work than the current
plan so that would be a second step.
>
> So any incremental improvement to native_{encode/interpret}_expr
> is good.
Yeah, also my improvement also should fix some confusion between
CHAR_BIT and BITS_PER_UNIT in the current code (not done yet but
I'll definitely fix that before I propose the patch for review).
Best regards,
Thomas
Re: Folding a bitfield in a union
On Fri, Jun 27, 2014 at 12:02 PM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Friday, June 27, 2014 5:32 PM
>> > 4) Cast value stored in a according to the size of b by removing bits of
>> > highest weight (via VIEW_CONVERT_EXPR).
>>
>> Fact is that 4) already is not working.
>>
>> /* We are at the end of walk, see if we can view convert the
>> result. */
>> if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
>> /* VIEW_CONVERT_EXPR is defined only for matching sizes. */
>> && operand_equal_p (TYPE_SIZE (type),
>> TYPE_SIZE (TREE_TYPE (ctor)), 0))
>>
>> while it's true we don't check precision in the gimple-verifier
>> VIEW_CONVERT_EXPR isn't supposed to be applied to types
>> with same size but differing precision. VIEW_CONVERT_EXPR
>> is supposed to _not_ strip any excess bits! (it's supposed to do
>> "nothing").
>
> Right but since ctor is an integer constant for a bitfield, this would check
> the size of the integer type qualifier of the bitfield, which is the source
> of the bug.
>
>>
>> Hmm. I wonder if the code behaves correctly for
>>
>> union {
>> struct { a : 10; b : 6 } a;
>> struct { a : 8; b : 8 } b;
>> } u = { .a = { } };
>>
>> and reading u.b.a or u.b.b?
>>
>> That is, is fold_nonarray_ctor_reference doing the right thing with
>> consecutive bitfield fields?
>
> With my current approach it would for u.b.a but not for u.b.b. The reason
> is that fold_ctor_reference will call fold_nonarray_ctor_reference as
> long as the constructor is an aggregate type. So for u.b.a it will find the
> constructor for u.a.a which completely contains u.b.a and it would work.
>
> This indeed suggest going towards the support for aggregate int
> native_encode_expr and native_interpret_expr.
>
>>
>> Is the current code behaving correctly for size % BITS_PER_UNIT == 0?
>
> For primitive type (a bitfield could respect this constraint) It does
> because the check in fold_ctor_reference would work correctly.
>
>> If so that might be a good fix for branches (who cares about
>> constant folding bitfield constants ... not many, given the bug you
>> show).
>
> The problem is not really that folding doesn't happen, but that it
> happens and gives wrong result. Is wrong code generation (even for
> bitfield) not serious enough?
Yes - I was specifically looking for an early out to avoid wrong-code.
So, is size % BITS_PER_UNIT != 0 a working fix to avoid the wrong-code
issues with bitfields (on big-endian targets)?
>> > However this double conversion between host and target memory
>> > layout is unelegant and unefficient. I could do just one conversion
>> > completely in fold_nonarray_ctor_reference but somehow I feel it is
>> > not the right place to do it. As anybody a better advice?
>>
>> I wonder if you have a patch to show us how unelegant it is?
>
> Not finished yet. I have improved native_interpret_integer but not
> native_encode_integer yet. It took me a while to reason about
> the various endianness (byte and word) of both target and host.
> Hopefully doing native_encode_integer should be easier now.
>
> However, since I have some other task with higher priority to
> handle, I think I'll push something that disables folding for bitfield on
> big endian target on Monday and continue working on this at some
> later time.
I'd rather disable it for all endianesses - gives us more incentive
to fix it properly.
>> Btw, another idea would be to support native_encode for the
>> whole CONSTRUCTOR and then use native_interpret with
>> offset/size. Of course for large CONSTRUCTORs that may
>> be prohibitive (but native_encode could get a start offset as well,
>> to skip uninteresting bytes).
>>
>> Being able to native encode a CONSTRUCTOR could be
>> factored and re-used from asm output.
>>
>> And it could be used to more efficiently store large aggregate
>> constant initializers (native encode it and compress it instead
>> of keeping CONSTRUCTOR).
>
> That would also allow to fold example such as the one you
> mentioned above. However that's more work than the current
> plan so that would be a second step.
Yeah (the code is already there in varasm.c:output_constructor - it
just uses a different "buffer").
>>
>> So any incremental improvement to native_{encode/interpret}_expr
>> is good.
>
> Yeah, also my improvement also should fix some confusion between
> CHAR_BIT and BITS_PER_UNIT in the current code (not done yet but
> I'll definitely fix that before I propose the patch for review).
Thanks,
Richard.
> Best regards,
>
> Thomas
>
>
How to duplicate a loop including basic_blocks and edges?
Hello everybody,
I want to make a copy of a loop, but it seems that the function duplicate_loop
does not work the way I need it.
It does not copy basic_blocks and edges.
What I need is this transformation
// Original
int foo () {
int i, b;
i = 0;
b = 50;
for (; i <= b; ++b) {
LOOP_BODY
}
}
// By copying the loop,
// and adapting the first condition.
int foo () {
int i, b;
i = 0;
b = 50;
for (; i < b; ++b) {
LOOP_BODY
}
for (; i <= b; ++b) {
LOOP_BODY
}
}
// Expected result, which is basically the same as above.
int foo () {
int i, b;
i = 0;
b = 50;
for (; i < b; ++b) {
LOOP_BODY
}
if (i == b) {
LOOP_BODY
++b;
}
}
So it should peel the last iteration of the loop, which is possible
when we have a GE_EXPR or a LE_EXPR and the step is 1.
Is there some functions or similar code that I could use as an example?
tree_duplicate_sese_region cannot handle regions containing a loop (as far as I
can tell).
duplicate_loop_to_header_edge peels from the beginning and not from the end.
I tried that with some postprocessing steps, that redirect some edges, without
success so far.
I wonder if this is a good way to go or is there a better solution.
Or should I copy everything by hand with get_loop_body and then create new
basic_blocks and edges?
Thank you and best regards,
Benedikt
clang 3.4.1 (and 3.3) compilation failed with gcc 4.7.4
Hello. After updating gcc from 4.7.3 to 4.7.4 on our illumos distribution (OpenIndiana Hipster) I can't longer compile clang. Compilation fails with llvm[5]: Compiling CIndexCodeCompletion.cpp for Release+Asserts build (PIC) llvm[5]: Linking Release+Asserts executable clang-check (without symbols) Undefined first referenced symbol in file vtable for clang::tooling::FrontendActionFactory* clang::tooling::newFrontendActionFactory(clang_check::ClangCheckActionFactory*, clang::tooling::SourceFileCallbacks*)::FrontendActionFactoryAdapter::ConsumerFactoryAdaptor /export/home/alp/srcs/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check/Release+Asserts/ClangCheck.o ld: fatal: symbol referencing errors. No output written to /export/home/alp/srcs/oi-userland/components/clang/build/i86/Release+Asserts/bin/clang-check collect2: error: ld returned 1 exit status make[5]: *** [/export/home/alp/srcs/oi-userland/components/clang/build/i86/Release+Asserts/bin/clang-check] Error 1 make[5]: Leaving directory `/export/home/alp/srcs/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check' make[4]: *** [clang-check/.makeall] Error 2 Tried to compile it with -O0, results are the same: /usr/gcc/4.7/bin/g++ -I/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/include -I/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check -I/export/home/alp/srcs/tests/oi-userland/components/clang/llvm-3.3.src/include -I/export/home/alp/srcs/tests/oi-userland/components/clang/llvm-3.3.src/tools/clang/tools/clang-check -D_DEBUG -include llvm/Support/Solaris.h -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/export/home/alp/srcs/tests/oi-userland/components/clang/llvm-3.3.src/tools/clang/tools/clang-check/../../include -I/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check/../../include -O3 -fomit-frame-pointer -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m32 -m32 -Wl,-R -Wl,'$ORIGIN/../lib' -Wl,-R -Wl,/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/Release+Asserts/bin -L/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/Release+Asserts/lib -L/export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/Release+Asserts/lib -m32 -m32 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings-Wno-maybe-uninitialized -Wno-missing-field-initializers -o /export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/Release+Asserts/bin/clang-check /export/home/alp/srcs/tests/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check/Release+Asserts/ClangCheck.o -lclangFrontend -lclangSerialization -lclangDriver -lclangTooling -lclangParse -lclangSema -lclangAnalysis -lclangRewriteFrontend -lclangRewriteCore -lclangEdit -lclangAST -lclangLex -lclangBasic \ -lLLVMBitReader -lLLVMAsmParser -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCAsmParser -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -lz -lpthread -lmalloc -lm Undefined first referenced symbol in file vtable for clang::tooling::FrontendActionFactory* clang::tooling::newFrontendActionFactory(clang_check::ClangCheckActionFactory*, clang::tooling::EndOfSourceFileCallback*)::FrontendActionFactoryAdapter::ConsumerFactoryAdaptor /export/home/alp/srcs/tests/oi-userland/components/clang/buil
