public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Martin Liska <marxin@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/marxin/heads/sphinx-final)] sphinx: use proper lexers for target macros Date: Tue, 8 Nov 2022 11:39:20 +0000 (GMT) [thread overview] Message-ID: <20221108113927.36F69385843B@sourceware.org> (raw) https://gcc.gnu.org/g:5800ccf9f03c6bc0ee971686fde3cd10b2a8d867 commit 5800ccf9f03c6bc0ee971686fde3cd10b2a8d867 Author: Martin Liska <mliska@suse.cz> Date: Tue Jul 26 14:14:19 2022 +0200 sphinx: use proper lexers for target macros gcc/ChangeLog: * target.def: Use proper lexers for target macros. * doc/gccint/target-macros/tm.rst.in: Re-generate. Diff: --- gcc/doc/gccint/target-macros/tm.rst.in | 12 ++++++------ gcc/target.def | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/gcc/doc/gccint/target-macros/tm.rst.in b/gcc/doc/gccint/target-macros/tm.rst.in index 17fc9e1b0aa..44f3a3b2222 100644 --- a/gcc/doc/gccint/target-macros/tm.rst.in +++ b/gcc/doc/gccint/target-macros/tm.rst.in @@ -1332,7 +1332,7 @@ Given below example: - .. code-block:: c++ + .. code-block:: gas ldr r10, [r1, 4] add r4, r4, r10 @@ -1349,7 +1349,7 @@ this scheduling fusion pass works. This hook calculates priority for each instruction based on its fustion type, like: - .. code-block:: c++ + .. code-block:: gas ldr r10, [r1, 4] ; fusion_pri=99, pri=96 add r4, r4, r10 ; fusion_pri=100, pri=100 @@ -1364,7 +1364,7 @@ to the priorities. As a result, instructions of same fusion type will be pushed together in instruction flow, like: - .. code-block:: c++ + .. code-block:: gas ldr r11, [r1, 0] ldr r10, [r1, 4] @@ -3876,13 +3876,13 @@ contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame debugging info engine will invoke it on insns of the form - .. code-block:: c++ + .. code-block:: (set (reg) (unspec [...] UNSPEC_INDEX)) and - .. code-block:: c++ + .. code-block:: (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). @@ -3900,7 +3900,7 @@ register :samp:`{R}` and set :samp:`*{factor}` and :samp:`*{offset}` such that the value of the indeterminate is: - .. code-block:: c++ + .. code-block:: value_of(R) / factor - offset diff --git a/gcc/target.def b/gcc/target.def index 7751b7fe7b1..aed1c1d3e22 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -1552,7 +1552,7 @@ instructions.\n\ \n\ Given below example:\n\ \n\ -.. code-block:: c++\n\ +.. code-block:: gas\n\ \n\ ldr r10, [r1, 4]\n\ add r4, r4, r10\n\ @@ -1569,7 +1569,7 @@ loads are actually next to each other in instruction flow. That's where\n\ this scheduling fusion pass works. This hook calculates priority for each\n\ instruction based on its fustion type, like:\n\ \n\ -.. code-block:: c++\n\ +.. code-block:: gas\n\ \n\ ldr r10, [r1, 4] ; fusion_pri=99, pri=96\n\ add r4, r4, r10 ; fusion_pri=100, pri=100\n\ @@ -1584,7 +1584,7 @@ Scheduling fusion pass then sorts all ready to issue instructions according\n\ to the priorities. As a result, instructions of same fusion type will be\n\ pushed together in instruction flow, like:\n\ \n\ -.. code-block:: c++\n\ +.. code-block:: gas\n\ \n\ ldr r11, [r1, 0]\n\ ldr r10, [r1, 4]\n\ @@ -4262,13 +4262,13 @@ DEFHOOK contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame debugging\n\ info engine will invoke it on insns of the form\n\ \n\ -.. code-block:: c++\n\ +.. code-block::\n\ \n\ (set (reg) (unspec [...] UNSPEC_INDEX))\n\ \n\ and\n\ \n\ -.. code-block:: c++\n\ +.. code-block::\n\ \n\ (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).\n\ \n\ @@ -4284,7 +4284,7 @@ expression, with :samp:`{i}` counting from 1. Return the number of a DWARF\n\ register :samp:`{R}` and set :samp:`*{factor}` and :samp:`*{offset}` such\n\ that the value of the indeterminate is:\n\ \n\ -.. code-block:: c++\n\ +.. code-block::\n\ \n\ value_of(R) / factor - offset\n\ \n\
next reply other threads:[~2022-11-08 11:39 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-08 11:39 Martin Liska [this message] -- strict thread matches above, loose matches on Subject: below -- 2022-11-08 14:53 Martin Liska 2022-11-08 14:43 Martin Liska 2022-11-08 14:36 Martin Liska 2022-11-08 14:35 Martin Liska 2022-11-08 12:06 Martin Liska 2022-11-08 10:21 Martin Liska 2022-11-07 14:34 Martin Liska 2022-11-07 14:19 Martin Liska 2022-11-07 14:09 Martin Liska 2022-11-07 14:08 Martin Liska 2022-11-07 14:07 Martin Liska 2022-11-07 13:20 Martin Liska 2022-11-07 13:01 Martin Liska 2022-11-07 12:38 Martin Liska
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221108113927.36F69385843B@sourceware.org \ --to=marxin@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).