Bad link on webpage
On the page, http://gcc.gnu.org/gcc-4.0/changes.html, the link http://www.nedprod.com/programs/gccvisibility.html (near the end of the document) contains ``DOMAIN HOLDING PAGE This is a holding page for a domain registered by Total Registrations on behalf of a customer. At this present time the owner of the domain name has simply registered the name and has not chosen to host a web site or receive email through it. ''
Re: Nonzero result when left-shift greater than width of unsigned type
On Fri, Apr 13, 2007 at 05:38:03AM -0400, Ken Takusagawa wrote:
> What's going on here? I'm expecting the answer 0, but get 2.
>
> #include
> int main(){
> unsigned x=1;
> printf("%u\n",(x<<33));
> /* outputs "2" on gcc 4.1.2 on x86_32 */
>
> /*
>[#4] The result of E1 << E2 is E1 left-shifted E2 bit
>positions; vacated bits are filled with zeros. If E1 has an
>unsigned type, the value of the result is E1*2^E2, reduced
>modulo one more than the maximum value representable in the
>result type.
>
>http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm
> */
Read from just 1 paragraph above the last sentence:
[#3] The integer promotions are performed on each of the
operands. The type of the result is that of the promoted
left operand. If the value of the right operand is negative |
or is greater than or equal to the width of the promoted
left operand, the behavior is undefined.
Ciao, Marcus
Re: GCC 4.0 RC1 Available
Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem triggering in ncurses (all platforms) PR/20929 triggers a miscompilation of Mozilla. At least 20126 should probably be considered for 4.0. Ciao, Marcus pgpfY5yLSUi6C.pgp Description: PGP signature
Re: Matching and testing against smulhsm3
On 2020-02-09 19:02, Segher Boessenkool wrote:
On Sun, Feb 09, 2020 at 12:15:03PM +0100, m wrote:
On 2020-02-07 16:44, Segher Boessenkool wrote:
(define_insn "smulhshi3"
[(set (match_operand:HI 0 "register_operand" "=r")
(truncate:HI
(ashiftrt:SI
(mult:SI
(sign_extend:SI (match_operand:HI 1
"register_operand" "r"))
(sign_extend:SI (match_operand:HI 2
"register_operand" "r")))
(const_int 15]
"TARGET_PACKED_OPS"
"mulq.h\\t%0, %1, %2")
However, I am unable to trigger this code path. I have tried with the
following C code:
short mulq(short op1, short op2) {
return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
}
But I just get the regular 4-instruction result (2x sign extend, 1x mul,
1x shift).
What does -fdump-rtl-combine-all show it tried? *Did* it try anything?
Cool option. I'm not really sure how to read the output tough. The
closest it seems to try to match is this:
For every combination tried, it shows "Trying 2 -> 6:" etc., followed by
the instructions it started with (which is very important), and then
what worked and what didn't, and more debug information.
I usually need to see that whole block (everything until the next
"Trying:").
I've attached the full output of -fdump-rtl-combine-all.
Failed to match this instruction:
(set (reg:SI 85)
(ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0))
(reg:SI 83 [ op2D.1381 ]))
(const_int 15 [0xf])))
It seems that it has already decided to split the instruction into
several operations (the truncate operation is not there, and the second
sign_extend:SI (subreg:HI ...) is also missing).
The code probably sign-extends the result; I need to see the full thing
to really know. Similarly, the sign_extend of a const_int is not
canonical rtl, it always is written as just a const_int.
You'll probably need to write a few extra patterns to recognise all the
options here.
I haven't had much time to dig more into this, but I hope to do so soon.
Regards,
Marcus
;; Function mulq (mulq, funcdef_no=0, decl_uid=1382, cgraph_uid=1,
symbol_order=0)
Pass statistics of "combine":
scanning new insn with uid = 21.
rescanning insn with uid = 2.
scanning new insn with uid = 22.
rescanning insn with uid = 4.
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
mulq
Dataflow summary:
def_info->table_size = 20, use_info->table_size = 18
;; fully invalidated by EH 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7
[s7] 8 [s8] 9 [s9] 10 [s10] 11 [s11] 12 [s12] 13 [s13] 14 [s14]
;; hardware regs used 28 [sp] 64 [?fp] 65 [?ap]
;; regular block artificial uses26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; eh block artificial uses 26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; entry block defs 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8
[s8] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; exit block uses 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp]
;; regs ever live 1 [s1] 2 [s2]
;; ref usage r1={2d,3u} r2={1d,1u} r3={1d} r4={1d} r5={1d} r6={1d} r7={1d}
r8={1d} r26={1d,2u} r28={1d,2u} r30={1d,1u} r64={1d,2u} r65={1d,1u} r78={1d,1u}
r80={1d,1u} r82={1d,1u} r83={1d,1u} r84={1d,1u} r85={1d,1u} r86={1d,1u}
r87={1d,1u}
;;total ref usage 42{22d,20u,0e} in 10{10 regular + 0 call} insns.
( )->[0]->( 2 )
;; bb 0 artificial_defs: { d1(1){ }d2(2){ }d3(3){ }d4(4){ }d5(5){ }d6(6){
}d7(7){ }d8(8){ }d9(26){ }d10(28){ }d11(30){ }d12(64){ }d13(65){ }}
;; bb 0 artificial_uses: { }
;; lr in
;; lr use
;; lr def 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8 [s8] 26
[fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live in
;; live gen 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8 [s8] 26
[fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live kill
;; lr out 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live out 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
( 0 )->[2]->( 1 )
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(26){ }u1(28){ }u2(64){ }u3(65){ }}
;; lr in1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; lr use 1 [s1] 2 [s2] 26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; lr def 1 [s1] 78 80 82 83 84 85 86 87
;; live in 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live gen 1 [s1] 78 80 82 83 84 85
;; live kill
;; lr out 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live out 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
( 2 )->[1]->( )
;; bb 1 artificial_defs: { }
;; bb 1 artificial_uses: { u13(1){ }u14(26){ }u15(28){ }u16(30){ }u17(64){ }}
;; lr in
Re: Matching and testing against smulhsm3
Hi Segher, Thanks for the analysis! On 2020-02-17 02:12, Segher Boessenkool wrote: Hi! On Sun, Feb 16, 2020 at 09:52:12PM +0100, Marcus Geelnard wrote: (define_insn "smulhshi3" [(set (match_operand:HI 0 "register_operand" "=r") (truncate:HI (ashiftrt:SI (mult:SI (sign_extend:SI (match_operand:HI 1 "register_operand" "r")) (sign_extend:SI (match_operand:HI 2 "register_operand" "r"))) (const_int 15] "TARGET_PACKED_OPS" "mulq.h\\t%0, %1, %2") insn_cost 4 for21: r86:SI=s1:SI REG_DEAD s1:SI insn_cost 4 for 2: r78:SI=r86:SI REG_DEAD r86:SI insn_cost 4 for22: r87:SI=s2:SI REG_DEAD s2:SI insn_cost 4 for 4: r80:SI=r87:SI REG_DEAD r87:SI insn_cost 4 for 9: r82:SI=sign_extend(r78:SI#0) REG_DEAD r78:SI insn_cost 4 for10: r83:SI=sign_extend(r80:SI#0) REG_DEAD r80:SI insn_cost 20 for11: r84:SI=r82:SI*r83:SI REG_DEAD r83:SI REG_DEAD r82:SI insn_cost 8 for12: r85:SI=r84:SI>>0xf REG_DEAD r84:SI insn_cost 4 for18: s1:HI=r85:SI#0 REG_DEAD r85:SI insn_cost 0 for19: use s1:HI 21 and 22 remain like this, so that register allocation can use whatever registers work best here. Trying 2 -> 9: Successfully matched this instruction: Trying 4 -> 10: Successfully matched this instruction: As expected here. Trying 9 -> 11: Failed to match this instruction: (set (reg:SI 84) (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0)) (reg:SI 83 [ op2D.1381 ]))) Trying 10 -> 11: Failed to match this instruction: (set (reg:SI 84) (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) (reg:SI 82 [ op1D.1380 ]))) Neither sign_extend combines with the mult on its own. Trying 10, 9 -> 11: Failed to match this instruction: (set (reg:SI 84) (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) (sign_extend:SI (subreg:HI (reg:SI 86) 0 And neither do both together. Do you have an instruction that can do this? How expensive is it? Unfortunately I don't have an instruction specifically for mult:SI (sign_extend:SI (HI)) (sign_extend:SI (HI)). Trying 11 -> 12: 11: r84:SI=r82:SI*r83:SI REG_DEAD r83:SI REG_DEAD r82:SI 12: r85:SI=r84:SI>>0xf REG_DEAD r84:SI Failed to match this instruction: (set (reg:SI 85) (ashiftrt:SI (mult:SI (reg:SI 82 [ op1D.1380 ]) (reg:SI 83 [ op2D.1381 ])) (const_int 15 [0xf]))) Good ;-) Trying 9, 11 -> 12: Failed to match this instruction: (set (reg:SI 85) (ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0)) (reg:SI 83 [ op2D.1381 ])) (const_int 15 [0xf]))) Trying 10, 11 -> 12: Failed to match this instruction: (set (reg:SI 85) (ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) (reg:SI 82 [ op1D.1380 ])) (const_int 15 [0xf]))) Neither of those work, that is fine as well. But, 9+10+11+12 is not tried. See https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/combine.c;h=d44b9c3bf950e52dce5089f7297a9fc7fb28dcfd;hb=HEAD#l2728 for why we don't here: most 4-insn combinations (where no 3-insn subset of it leads to a valid insn) do not go anywhere, and there are *many* such combinations that can be tried. Instructions with a binary op with a constant source count as one "ngood", and instructions that are just a move from a constant into something count as two "ngood". Shifts are counted separately, in "nshift". So here we get ngood=0 and nshift=1, but we need one of them to be at least 2 to try a 4-insn combo. Maybe we should have an "nextend" as well? Many targets use something like this for widening multiplies. I'll try something like that, but it won't make it into GCC 10 (we're in development stage 4 for it now). In the meantime, you can add a pattern for the result of 9+10+11: (set (match_operand:SI ...) (mult:SI (sign_extend:SI (match_operand:HI ...)) (sign_extend:SI (match_operand:HI ... (which you then have to handle, of course, either with a machine insn if that exists, or some other way, a libcall perhaps; you already have some way to do mulsi3 I guess?) Yes, I have mulsi3, but the thing is that I have instructions that exactly match the definition of smulhsqi3/smulhshi3/smulhssi3. They're called MULQ.B, MULQ.H and MULQ (for Q-format fixed point), and they typically have a throughput of 1 operation / cycle. See [1]. I'd really like to find a way to tell gcc to emit those instructions. If naive C code does not generate a matching pattern (it would be nice if it did, though), is there something else that can be used (e.g. a builtin)? Again, thanks! I'll dig further. /Marcus [1] https://github.com/mrisc32/mrisc32/blob/master/doc/Instructions.md#multiply-and-divide-instructions
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18 August 2015 at 10:25, Alex Velenko wrote: > > > On 31/07/15 12:04, Alex Velenko wrote: >> >> On 29/07/15 23:14, Jeff Law wrote: >>> >>> On 07/28/2015 12:18 PM, Alex Velenko wrote: >>>> >>>> On 21/04/15 06:27, Jeff Law wrote: >>>>> >>>>> On 04/20/2015 01:09 AM, Shiva Chen wrote: >>>>>> >>>>>> Hi, Jeff >>>>>> >>>>>> Thanks for your advice. >>>>>> >>>>>> can_replace_by.patch is the new patch to handle both cases. >>>>>> >>>>>> pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump >>>>>> >>>>>> pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump >>>>>> after patch can_replace_by.patch >>>>>> >>>>>> Could you help me to review the patch? >>>>> >>>>> Thanks. This looks pretty good. >>>>> >>>>> I expanded the comment for the new function a bit and renamed the >>>>> function in an effort to clarify its purpose. From reviewing >>>>> can_replace_by, it seems it should have been handling this case, but >>>>> clearly wasn't due to implementation details. >>>>> >>>>> I then bootstrapped and regression tested the patch on x86_64-linux-gnu >>>>> where it passed. I also instrumented that compiler to see how often >>>>> this code triggers. During a bootstrap it triggers a couple hundred >>>>> times (which is obviously a proxy for cross jumping improvements). So >>>>> it's triggering regularly on x86_64, which is good. >>>>> >>>>> I also verified that this fixes BZ64916 for an arm-non-eabi toolchain >>>>> configured with --with-arch=armv7. >>>>> >>>>> Installed on the trunk. No new testcase as it's covered by existing >>>>> tests. >>>>> >>>>> Thanks,, >>>>> jeff >>>>> >>>> >>>> Hi, >>>> I see this patch been committed in r56 on trunk. Is it okay to port >>>> this to fsf-5? >>> >>> It's not a regression, so backporting it would be generally frowned >>> upon. If you feel strongly about it, you should ask Jakub, Joseph or >>> Richi (the release managers) for an exception to the general policy. >>> >>> jeff >>> >> Hi Jakub, >> Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c >> at the time, so I think it is a good idea to port. Please, see >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 >> Kind regards, >> Alex > > > Ping! > > Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I > think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus
Re: Merging Apple's Objective-C 2.0 compiler changes
On 9/13/10 2:04 PM, Ian Lance Taylor wrote: Therefore, I see a clear benefit to clang->gcc, but I do not see a clear benefit to gcc->llvm. Suppose you have large Fortran applications, and want to accelerate parts of them on graphics processors. Several of the OpenCL implementations use LLVM for runtime code generation, so one could compile the application to LTO, and let it go through some expensive stages of the GCC optimizer, and have LLVM bitcode staged for final translation to the GPU ISA. In general, make the distinction between heavy ahead-of-time compilation and light just-in-time compilation along the lines of GCC and LLVM.
Re: plugin hooks for plugin-provided builtins?
On 9/14/10 8:46 AM, Basile Starynkevitch wrote: My current work aims to translate some Gimple into OpenCL source code, thus providing GCC with the ability to take advantage of GPU running their proprietary OpenCL compilers without asking the user to learn OpenCL. My understanding is that Gimple does not have the notion of data parallel operations. For example, in Fortran, array operators are lowered to scalarized form. OpenCL does have these semantics. kernels enqueued as an NDRanges are item-by-item data parallel and there are often not any loops expressed in the kernel itself. And kernels that do have lots of control logic, and use lots of registers, global memory, etc. will tend not to work well on GPUs. Remember that for geographical & political reasons all my GCC work is more "source to source" that "source to machine" oriented. I don't have the expertise, and I am not legitimate (internally in my CEA LIST organization at least, and also w.r.t. of funding French government agencies) to work on anything close to the target processor or silicon in GCC. It seems to me a "source to source" compiler should definitely retain high level constructs like array operators, DO ALL, OpenMP directives, etc. Marcus
Re: plugin hooks for plugin-provided builtins?
On 9/14/10 10:58 AM, Basile Starynkevitch wrote: It seems to me a "source to source" compiler should definitely retain high level constructs like array operators, DO ALL, OpenMP directives, etc One can use #pragma-s& builtin-s& attributes for these. This is why I was trying to push the idea of plugin hooks for builtins. In this use case, what is the GCC middle-end *for* if it does not understand data parallel operations? Even GENERIC lacks the notion, right? (We've been working directly from the Fortran parse tree.) Marcus
Re: dejagnu multilib options and dg-{add|additional-}options
On 23 July 2013 17:40, Janis Johnson wrote:
> On 07/22/2013 02:59 AM, Vidya Praveen wrote:
>> Hello,
>>
>> There are 42 test files (25 under gcc.dg) that specifies
>>
>> { dg-add-options bind_pic_locally }
>>
>> in the regression testsuite. The procedure add_options_for_bind_pic_locally
>> from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is
>> passed
>> respectively. But this is added before the dejagnu multilib options are
>> added.
>> So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
>> (see gcc/common.opt). This should have been the behaviour since the patch
>> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all -fPIC
>> & -fPIE variants in a Negative loop, was applied.
>>
>> I tried fixing this in dejagnu/target.exp by adding the multilib options
>> before
>> the other options:
>>
>> default_target_compile:
>>
>> < append add_flags " [board_info $dest multilib_flags]"
>> ---
>>> set add_flags " [board_info $dest multilib_flags] $add_flags"
>>
>> and ran regressions for x86_64-unknown-linux-gnu before and after the change.
>> The only difference in the results after the change was 24 new PASSes which
>> are from the testcases which either use bind_pic_locally or that use
>> -fno-pic.
>>
>> (Interestingly, there are many test files that bind_pic_locally pass without
>> any issue before and after the change.)
>>
>> I tend to think that the options added from the test files should always win.
>> Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
>> best place to fix this and the way it tried to fix? Any better suggestions?
>>
>> Though this case is to do with -fPIC, I'm sure there are other options which
>> when they come as multilib options might have same issue with the some of the
>> options added by the test files or the default options.
>>
>> Regards
>> VP
>
> Ideally we would ask for that change in DejaGnu, but relying on such a
> change would require everyone testing GCC to upgrade to a version of
> DejaGnu with that fix, and I don't think we're ready to do that.
>
> Tests that add options that might override or conflict with multilib
> flags should check for those flags first and skip the test if they are
> used. For examples, see tests in gcc.target/arm that use dg-skip-if.
Umm, the purpose of bind_pic_locally appears to be to detect the use
of -fPIC and override that behavior with -fPIE. If I understand the
above paragraph correctly then bind_pic_locally is fundamentally
broken and all of the tests that use it need rewriting to skip if
-fPIC or -fpic is in use?
Cheers
/Marcus
DOC PATCH: attribute(alloc_size)
Hi, addition of alloc_size attribute to the changes.html. Ciao, Marcus Index: htdocs/gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.57 diff -u -r1.57 changes.html --- htdocs/gcc-4.3/changes.html 25 May 2007 17:20:59 - 1.57 +++ htdocs/gcc-4.3/changes.html 1 Jun 2007 16:28:01 - @@ -199,6 +199,18 @@ the diverse warnings enabled by -Wextra. + +A new function attribute alloc_size has been added to +mark up malloc style functions. For constant sized +allocations this can be used to find out the size of the returned +pointer using the __builtin_object_size() function +for buffer overflow checking and similar. +This supplements the already built-in malloc and +calloc constant size handling and is useful for any +allocator function like g_malloc() from glib2 or HeapAlloc() +from the Win32 implementation in Wine. + + C++
Re: DOC PATCH: attribute(alloc_size)
On Fri, Jun 01, 2007 at 06:28:52PM +0200, Marcus Meissner wrote: > Hi, > > addition of alloc_size attribute to the changes.html. > > Ciao, Marcus Less plugging of examples as suggested by Dirk... Index: htdocs/gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.57 diff -u -r1.57 changes.html --- htdocs/gcc-4.3/changes.html 25 May 2007 17:20:59 - 1.57 +++ htdocs/gcc-4.3/changes.html 1 Jun 2007 16:59:02 - @@ -199,6 +199,16 @@ the diverse warnings enabled by -Wextra. + +A new function attribute alloc_size has been added to +mark up malloc style functions. For constant sized +allocations this can be used to find out the size of the returned +pointer using the __builtin_object_size() function +for buffer overflow checking and similar. +This supplements the already built-in malloc and +calloc constant size handling. + + C++
Re: RFH: GPLv3
On Fri, Jul 13, 2007 at 08:54:17AM -0700, Michael Eager wrote: > Robert Dewar wrote: > >Nicholas Nethercote wrote: > > > >>One way to view it: the license is a feature. Therefore changing the > >>license is changing a feature. Therefore what was going to be 4.2.2 > >>should become 4.3.0. > > > >I certainly agree that the license is a feature, and a pretty > >important one for many users. > > There's a saying "if you call a dog's tail a leg, how many legs > does a dog have. Four. Calling its tail a leg doesn't make it one." > > Version numbers have been based on binary compatibility > and interoperability between versions. > > Saying that license is an interoperability issue doesn't make it one. GPLv3+ code is however incompatible to GPLv2+ code, so it warrants a major version bump. Ciao, Marcus
Re: How widely used are and ?
On Thu, Oct 25, 2007 at 09:40:06PM -0700, Joe Buck wrote:
> The thread arguing about this has gone on for a while, so I think
> it's time to gather some data to answer the question of just how bad
> it will be if we accept the decision to move ext/hash_set and ext_hash_map
> into a different directory and to deprecate them.
>
> Any of you out there who put out distros or port collections: how many
> packages in your distro use these classes? You can grep for
>
> '# *include *
> I'm particularly interested in the "Debian number", since the package
> collection is so large. Other information about use of these classes
> will be interesting as well.
For SUSE the ones the grep above found:
- kdevelop3
- amarok
- xmms-kde
- apt
- abiword
- pan
- scim
- kseg
- pdns
Mostly one or two occurences.
Ciao, Marcus
RE: WPP capabilities in gcc
GNU gettext with Emacs source context might do it. You'd have to invent your own tags, in lieu of of __FILE__, etc. https://www.gnu.org/software/gettext/manual/html_node/C-Sources-Context.html#C-Sources-Context It seems to me the general problem is that C preprocessor does not give you the full power of C. One cannot simply define a function to hash the __FILE__ string at compile time. There's no quasi-quote like in Lisp or Haskell. Marcus -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Shoham Peller Sent: Sunday, April 26, 2015 3:53 PM To: Jonathan Wakely Cc: gcc@gcc.gnu.org; Guy Lewin Subject: Re: WPP capabilities in gcc SystemTap does not give a solution for this, and is not really intended for this use: * It's no cross-platform, it's for Linux * It doesn't allow the developer to write the text he wants * It doesn't parse the tracing string The solution I'm talking about is: * cross platform * Will allow you to write arbitrary trace string * Parses the string and the parameters in it (%s, %d) and makes sure they are traced too. On Mon, Apr 27, 2015 at 12:21 AM, Jonathan Wakely wrote: > On 26 April 2015 at 18:47, Shoham Peller wrote: >> 1. Can you think of a way to achieve this with gcc? > > Insert SystemTap probe points.
loading output of -fdump-tree-original-raw
Hi all, For the purposes of static analysis, can the output of -fdump-tree-original-raw complete for reconstructing GENERIC data? Packages like treehydra are intriguing, but they aren't complete, for example, for Fortran. Thanks, Marcus Daniels
Re: loading output of -fdump-tree-original-raw
Andrew Pinski wrote: How about doing a plugin instead? I took a peek at the Treehydra plugin from Mozilla that does pre-GENERIC for C++. That looks like it would work, but we're concerned with Fortran, and indeed would like to preserve things like Fortran array-level operators. The GENERIC dump file approach has the advantage that it is low commitment and not require any build-time apparatus. Do you think it would be as easy to create a plugin? (It would be nice to be able to take it to the next level and influence code generation.) Thanks, Marcus
Re: plugin hooks for plugin-provided builtins?
> The GCC middle end use is for me mandatory (since it is contractual). I > am expecting to work on Gimple to OpenCL translation, whatever that > means. The saling point it that starting from GCC & gimple gives the > hypothetical enduser all the power of GCC. Given the current limitations of Gimple, another area to focus on could be task parallelism (rather than data parallelism). In that case a language like [Google] Go (via GCC) might make a better talking point than C or Fortran. That is, some very multithreaded application that touches data in an irregular and unpredictable fashion. The OpenCL angle would be to facilitate multiplexing the coroutines on GPU hardware.
