Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On Mon, Aug 15, 2016 at 8:59 PM, Prasad Ghangal
wrote:
> On 11 August 2016 at 15:58, Richard Biener wrote:
>> On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
>> wrote:
>>> In this patch I am trying to parse gimple call. But I am getting weird
>>> gimple dump for that.
>>>
>>> for this testcase:
>>> int __GIMPLE() bar()
>>> {
>>> int a;
>>> a = a + 1;
>>> return a;
>>> }
>>>
>>> void __GIMPLE() foo()
>>> {
>>> int b;
>>> b = bar();
>>> }
>>>
>>> I am getting ssa dump as:
>>>
>>> /* Function bar (bar, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>>> symbol_order=0)*/
>>>
>>> int
>>> bar ()
>>> {
>>> struct FRAME.bar FRAME.0;
>>> int a;
>>> void * D_1754;
>>> void * _3;
>>>
>>> bb_2:
>>> _3 = __builtin_dwarf_cfa (0);
>>> FRAME.0.FRAME_BASE.PARENT = _3;
>>> a_6 = a_5(D) + 1;
>>> return a_6;
>>>
>>> }
>>>
>>>
>>>
>>> /* Function foo (foo, funcdef_no=1, decl_uid=1747, cgraph_uid=1,
>>> symbol_order=1)*/
>>>
>>> void
>>> foo ()
>>> {
>>> int b;
>>>
>>> bb_2:
>>> b_3 = bar ();
>>> return;
>>>
>>> }
>>>
>>
>> Somehow foo is treated as nested in bar. Note this even happens
>> without calls if you
>> have two functions in the testcase. Usually this means after
>> finishing parsing of a function
>> you fail to reset. Looks like the following fixes it:
>>
>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>> index 95615bc..b35eada 100644
>> --- a/gcc/c/c-parser.c
>> +++ b/gcc/c/c-parser.c
>> @@ -2164,6 +2165,8 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
>> fnde
>> f_ok,
>> c_parser_parse_gimple_body (parser);
>> in_late_binary_op = saved;
>> cgraph_node::finalize_function (current_function_decl, false);
>> + set_cfun (NULL);
>> + current_function_decl = NULL;
>> timevar_pop (tv);
>> return;
>> }
>>
>> Richard.
>>
> I have updated the patch and committed along with testcases
That's great - note that it's now time to wrap up and prepare a formal
submission of the
work you have done. I'd like to see patch(es) generated from the git
repo and submitted
to gcc-patches together with appropriate ChangeLog entries. I'd also
like to see an
overall summary of achievements refering to your timeline proposal and
I'd like to know
TODOs that you stumbled over.
When you prepare patches that's also a good time to review those yourself for
formatting, missing comments and trivial improvements to clarity that
can be still made.
What I've seen sofar the project is in a usable prototype stage!
Thanks,
Richard.
> Thanks,
> Prasad
>>>
>>> On 9 August 2016 at 14:37, Richard Biener
>>> wrote:
On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal
wrote:
> On 4 August 2016 at 18:29, Richard Biener
> wrote:
>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
>> wrote:
>>> On 2 August 2016 at 14:29, Richard Biener
>>> wrote:
On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
wrote:
> Hi,
>
> I am trying to replace c_parser_paren_condition (parser) in
> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
> described in the patch
>
> I am trying test case
> void __GIMPLE () foo ()
> {
> int a;
> bb_2:
> if (a == 2)
> goto bb_3;
> else
> goto bb_4;
> bb_3:
> a_2 = 4;
> bb_4:
> return;
> }
>
> but it fails to parse gimple expression and produces error as
> /home/prasad/test3.c: In function ‘foo’:
> /home/prasad/test3.c:1:18: error: invalid operands in gimple
> comparison
> void __GIMPLE () foo ()
> ^~~
> if (<<< Unknown tree: c_maybe_const_expr
>
> a >>> == 2) goto bb_3; else goto bb_4;
> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple
> failed
>
> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
It's in parsing the binary expression. Btw, you don't need
lvalue_to_rvalue
conversion or truthvalue conversion - source that would require this
would
not be valid GIMPLE. Let me try to debug:
(gdb) p debug_tree (cond.value)
>>> type >>> size
unit size
align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
precision 32 min max
pointer_to_this >
arg 0 >>> 0x7688b7e0 int>
arg 1 >>> 0x7688b7e0 int>
used SI file t.c line 3 col 7 size >>> 0x76887ee8 32> unit size
align 32 context >>
arg 1 >>> 0x7688b7e0 int> constant 2>
t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
$5 = void
>
[wwwdocs] PATCH for Re: GCC Coding Conventions typo
On Fri, 22 Apr 2016, Chris Gregory wrote: > https://gcc.gnu.org/codingconventions.html#ExternC > > In the `Extern "C"` commentary, the coding conventions says: > > Definitions within the body of a namespace are not indented. > > This should read > > Definitions within the body of an `extern "C"` block are not indented. Thank you for the report, Chris! I just fixed this (finally) by applying the patch below, attributed to you. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.74 diff -u -r1.74 codingconventions.html --- codingconventions.html 27 May 2016 19:25:16 - 1.74 +++ codingconventions.html 16 Aug 2016 09:23:03 - @@ -1304,7 +1304,7 @@ -Definitions within the body of a namespace are not indented. +Definitions within the body of an extern "C" block are not indented. Namespaces
Supporting subreg style patterns
My hardware directly supports instructions of the form subreg:SI(reg:VEC v1,3) = SI:a1 That is, a particular field of a vector register can be used as the target of a move from a general register. Reginfo refuses to recognize that any registers can satisfy this subreg expression and therefore ira/reload/lra uses memory to make the transfer. If I allow vector registers to support SImode, I can get subreg 0 working, but no others since the various fields do not have a register equivalent. Are there any hooks or data structures to support this feature? Are there any examples in supported architectures? Thanks Shmeel
Re: option -mprfchw on 2 different Opteron cpus
On Tue, May 3, 2016 at 12:40 AM, Kumar, Venkataramanan
wrote:
> Hi
>
>> -Original Message-
>> From: NightStrike [mailto:nightstr...@gmail.com]
>> Sent: Monday, May 2, 2016 10:31 PM
>> To: Kumar, Venkataramanan
>> Cc: Uros Bizjak (ubiz...@gmail.com) ;
>> lopeziba...@gmail.com; Jan Hubicka ; Jakub Jelinek
>> ; gcc@gcc.gnu.org
>> Subject: Re: option -mprfchw on 2 different Opteron cpus
>>
>> On Mon, May 2, 2016 at 5:55 AM, Kumar, Venkataramanan
>> wrote:
>> >> If I compile on a k8 Opteron 248 with -march=native, I do not see
>> >> -mprfchw listed in the options in -fverbose-asm. In the assembly, I see
>> this:
>> >>
>> >> prefetcht0 (%rax) # ivtmp.1160
>> >> prefetcht0 304(%rcx) #
>> >> prefetcht0 (%rax) # ivtmp.1160
>> >
>> > In AMD processors -mprfchw flag is used to enable "3dnowprefetch" ISA
>> support.
>> >
>> > (Snip)
>> > CPUID Fn8000_0001_ECX Feature Identifiers Bit 8
>> > 3DNowPrefetch: PREFETCH and PREFETCHW instruction support. See
>> > “PREFETCH” and “PREFETCHW” in APM3
>> > Ref: http://support.amd.com/TechDocs/25481.pdf
>> > (Snip)
>> >
>> > Can you please confirm what this CPUID flag returns on your k8 machine ?.
>> > I believe this ISA is not available on k8 machine so when -march=native is
>> added you don’t see -mprfchw in verbose.
>>
>> Looks like zero? This was generated with the cpuid program from
>> http://www.etallen.com/cpuid.html
>>
>> 3DNow! instruction extensions = true
>> 3DNow! instructions = true
>
> It has 3Dnow support. "prefetchw" is available with 3dnow.
>
>> misaligned SSE mode= false
>> 3DNow! PREFETCH/PREFETCHW instructions = false
>
> It does not have 3DNowprefetch enabling ISA flag -mprftchw is not correct for
> -march=k8.
>
>> OS visible workaround = false
>> instruction based sampling = false
>> >> If I compile on a bdver2 Opteron 6386 SE with -march=k8 (thus trying
>> >> to target the older system), I do see it listed in the options in
>> >> -fverbose-asm. In the assembly, I see this:
>> >
>> > K8 has 3dnow support and there is a patch that replaced 3dnow with
>> prefetchw (3DNowPrefetch).
>> > https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00866.html
>> > So when you add -march=k8 you see -mprfchw getting listed in verbose.
>> >
>> >>
>> >> prefetcht0 (%rax) # ivtmp.1160
>> >> prefetcht0 304(%rcx) #
>> >> prefetchw (%rax) # ivtmp.1160
>> >>
>> >> (The third line is the only difference)
>> >>
>> >
>> > This is my guess without seeing the test case, when write prefetching is
>> requested "prefetchw" is generated.
>> > 3dnow (TARGET_3DNOW) ISA has support for it.
>> >
>> > (Snip)
>> > Support for the PREFETCH and PREFETCHW instructions is indicated by
>> > CPUID Fn8000_0001_ECX[3DNowPrefetch] OR Fn8000_0001_EDX[LM] OR
>> > Fn8000_0001_EDX[3DNow] = 1.
>> > (Snip)
>> > Ref:
>> http://developer.amd.com/wordpress/media/2008/10/24594_APM_v3.pdf
>> >
>> >> In both cases, I'm using gcc 4.9.3. Which is correct for a k8 Opteron
>> >> 248?
>> >>
>> >> Also, FWIW:
>> >>
>> >> 1) The march=native version that uses prefetcht0 is very repeatably
>> >> faster by about 15% in the particular test case I'm looking at.
>> >>
>> >> 2) The compilers in both instances are not just the same version,
>> >> they are the same compiler binary installed on an NFS mount and
>> >> shared to both computers.
>> >
>> > As per GCC4.9.3 source.
>> >
>> > (Snip)
>> > (define_expand "prefetch"
>> > [(prefetch (match_operand 0 "address_operand")
>> > (match_operand:SI 1 "const_int_operand")
>> > (match_operand:SI 2 "const_int_operand"))]
>> > "TARGET_PREFETCH_SSE || TARGET_PRFCHW || TARGET_PREFETCHWT1"
>> > {
>> > bool write = INTVAL (operands[1]) != 0;
>> > int locality = INTVAL (operands[2]);
>> >
>> > gcc_assert (IN_RANGE (locality, 0, 3));
>> >
>> > /* Use 3dNOW prefetch in case we are asking for write prefetch not
>> > supported by SSE counterpart or the SSE prefetch is not available
>> > (K6 machines). Otherwise use SSE prefetch as it allows specifying
>> > of locality. */
>> > if (TARGET_PREFETCHWT1 && write && locality <= 2)
>> > operands[2] = const2_rtx;
>> > else if (TARGET_PRFCHW && (write || !TARGET_PREFETCH_SSE))
>> > operands[2] = GEN_INT (3);
>> > else
>> > operands[1] = const0_rtx;
>> > })
>> > (Snip)
>> >
>> > Write prefetch may be requested (either by auto prefetcher or builtins) but
>> on -march=native, the below check could have become false.
>> >else if (TARGET_PRFCHW && (write || !TARGET_PREFETCH_SSE))
>> > TARGET_PRFCHW is off on native.
>> >
>> > So there are two issues here.
>> >
>> > (1) ISA flags enabled with -march=k8 is different from -march=native on k8
>> machine.
>
> I think we need to file bug for this. Need to check with Uros why the flag
> -mprfchw is shared with 3dnow.
> To work around this issue you can use -mno-prfch
Using LTO-enabled libgfortran
What would it take to use an LTO-enabled version of gfortran? It could turn out to be quite useful for speeding up programs, especially where I/O or array intrinsics are used. I also expect many issues to surface where libgfortran is playing with types in a way that could break LTO, so I would not expect this to be an easy thing. So, ideas anybody? I don't think any other library included with gcc does this, correct? Regards Thomas
Re: Using LTO-enabled libgfortran
On August 16, 2016 7:11:26 PM GMT+02:00, Thomas Koenig wrote: >What would it take to use an LTO-enabled version of gfortran? > >It could turn out to be quite useful for speeding up programs, >especially where I/O or array intrinsics are used. > >I also expect many issues to surface where libgfortran is >playing with types in a way that could break LTO, so I >would not expect this to be an easy thing. > >So, ideas anybody? I don't think any other library included >with gcc does this, correct? Correct. My advice is to simply try. Note this will work only for static libgfortran. Also note that since the LTO option scheme changed to preserve compile-time optimization and target attributes LTOing libgfortran will be less useful than before (you won't get any advantage from extra available ISAs). Richard. >Regards > > Thomas
gcc-5-20160816 is now available
Snapshot gcc-5-20160816 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160816/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 239515 You'll find: gcc-5-20160816.tar.bz2 Complete GCC MD5=b9eea2d8704bf3069699f1f76dc02864 SHA1=010d546ee337fed9b611c61dc1646bcdc3c421e3 Diffs from 5-20160809 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Using LTO-enabled libgfortran
Am 16.08.2016 um 20:57 schrieb Richard Biener: On August 16, 2016 7:11:26 PM GMT+02:00, Thomas Koenig wrote: What would it take to use an LTO-enabled version of gfortran? It could turn out to be quite useful for speeding up programs, especially where I/O or array intrinsics are used. I also expect many issues to surface where libgfortran is playing with types in a way that could break LTO, so I would not expect this to be an easy thing. So, ideas anybody? I don't think any other library included with gcc does this, correct? Correct. My advice is to simply try. I did that, with some interesting results. Just putting -flto -ffat-lto-objects into every CFLAG and FFLAG available into the Makefile of libgfortran (autoconf can come later :-), recompiling gfortran and trying out the program program main real, dimension(10) :: a call random_number(a) write (*,'(E12.5)',advance="no") a end program main led to lto1: warning: type of '_gfortran_st_write' does not match original declaration [-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:3746:1: note: 'st_write' was previously declared here ../../../trunk/libgfortran/io/transfer.c:3746:1: note: code may be misoptimized unless -fno-strict-aliasing is used lto1: warning: type of '_gfortran_transfer_array_write' does not match original declaration [-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:2195:1: note: 'transfer_array_write' was previously declared here ../../../trunk/libgfortran/io/transfer.c:2195:1: note: code may be misoptimized unless -fno-strict-aliasing is used lto1: warning: type of '_gfortran_st_write_done' does not match original declaration [-Wlto-type-mismatch] ../../../trunk/libgfortran/io/transfer.c:3756:1: note: 'st_write_done' was previously declared here ../../../trunk/libgfortran/io/transfer.c:3756:1: note: code may be misoptimized unless -fno-strict-aliasing is used So, the expected surprises appeared... From the disassembly, I could also see that LTO had done some things; there were references to functions like _gfortrani_gf_strerror.constprop.18, write_decimal.isra.5.constprop.11, nml_parse_qualifier.constprop.15 and _gfortran_arandom_r4.constprop.3. So, worth investigating. I'll open a PR. Note this will work only for static libgfortran. Also note that since the LTO option scheme changed to preserve compile-time optimization and target attributes LTOing libgfortran will be less useful than before (you won't get any advantage from extra available ISAs). Once every other problem has been solved :-) I am sure we can address this one. Regards Thomas
