"error: static assertion failed: [...]" (was: [GCC Wiki] Update of "DiagnosticsGuidelines" by MartinSebor)
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static assertion failed: "foo"
_Static_assert(0, "foo");
^~
..., and for C++ we diagnost:
[...]:4:1: error: static assertion failed: foo
static_assert(0, "foo");
^
("foo" quoted vs. un-quoted.) Assuming this difference between C and C++
diagnostics is not intentional, which one should we settle on? I thought
I'd like the un-quoted version better, but judging by Martin's recent
wiki change (see below), "foo" is a string constant, so should be quoted
in diagnostics? If yes, OK to commit to trunk the obvious changes (plus
any testsuite updates)?
For reference:
On Tue, 12 Jul 2016 22:34:17 -, GCC Wiki wrote:
> The "DiagnosticsGuidelines" page has been changed by MartinSebor:
> https://gcc.gnu.org/wiki/DiagnosticsGuidelines?action=diff&rev1=7&rev2=8
>
> Comment:
> Added a table of contents and a Quoting section.
> + === Quoting ===
> +
> + The following elements should be quoted in GCC diagnostics, either using
> the {{{q}}} modifier in a directive such as {{{%qE}}}, or by enclosing the
> quoted text in a pair of {{{%<}}} and {{{%>}}} directives:
> +
> + * Language keywords.
> + * Tokens.
> + * Boolean, numerical, character, and string constants that appear in the
> source code.
> + * Identifiers, including function, macro, type, and variable names.
> +
> + Other elements such as numbers that do no refer to numeric constants that
> appear in the source code should not be quoted. For example, in the message:
> + {{{#!highlight c++ numbers=disable
> + argument %d of %qE must be a pointer type
> + }}}
> + since the argument number does not refer to a numerical constant in the
> source code it should not be quoted.
Grüße
Thomas
signature.asc
Description: PGP signature
Re: SPR access
Hi,
No problem - helping out is one way users can contribute to the gcc
community, to save the gcc developers a little effort.
Next time, however, keep questions like this on the gcc-help mailing
list - it is for asking for help with using gcc. The gcc@gcc.gnu.org
mailing list is for development of the compiler itself.
mvh.,
David
On 13/07/16 16:39, tutruong0...@gmail.com wrote:
> Hi,
>
> Thank you for your answer.
> It is very useful for me.
>
> Best regards;
>
> Truong TT
>
>> On Jul 8, 2016, at 11:07 PM, David Brown wrote:
>>
>> Hi,
>>
>> (You have something wrong with your emails - the subject for your post
>> had a copy of most of the body of the email. I have changed it to
>> something smaller.)
>>
>> You can't use a function argument for the number of the SPR, because the
>> assembler requires the SPR at assembly time to generate the full mtspr
>> instruction. My solution was to use a macro for this, rather than a
>> function (even a static inline function won't work):
>>
>> #define readSpr(sp) ({ uint32_t res; \
>>asm volatile (" mfspr %[res], %[spr] " : \
>>[res] "=r" (res) : \
>>[spr] "i" (sp) ); \
>>res; })
>>
>> #define writeSpr(sp, va) \
>>asm volatile (" mtspr %[spr], %[val] " : \
>>: \
>>[spr] "i" (sp), [val] "r" (va) )
>>
>>
>> mvh.,
>>
>> David
>>
>>
>>
>>> On 08/07/16 16:16, Tran Tu Truong wrote:
>>> Dear Mr/Ms;
>>>
>>> I am Truong, working at Vietnam human engineering in Vietnam.
>>> Now, I am using D32 Design Studio for programming MPC5777C micro
>>> controller (GNU C Compiler 4.9). I've already made a sample inline asm
>>> code in .C file ase bellow:
>>> void set_spr ( uint32_t spr_num, uint32_t val )
>>> {
>>> asm volalatile ("mtspr %0, %1"
>>> :
>>> :"r"(spr_num), "r"(val)
>>> );
>>> }
>>> This code does not work correct (It should work but not work). I found
>>> out the constraints operands [:"r"(spr_num),] is not correct. I thinks
>>> it better if spr_num is be referred as a constant not a register ( ex:
>>> mtspr 120, val ). But I don't know how to revise.
>>> I also referred on
>>> https://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints
>>> about PowerPC but I cannot understand clearly.So, could you please
>>> help me to explain about that?
>>> If you have the instruction about "constraints for asm operands" for
>>> MPC5777C micro controller, please provide me.
>>>
>>> Thank you.
>>> --Tran Tu Truong--
>>
Re: SPR access
Hi,
Thank you for your answer.
It is very useful for me.
Best regards;
Truong TT
> On Jul 8, 2016, at 11:07 PM, David Brown wrote:
>
> Hi,
>
> (You have something wrong with your emails - the subject for your post
> had a copy of most of the body of the email. I have changed it to
> something smaller.)
>
> You can't use a function argument for the number of the SPR, because the
> assembler requires the SPR at assembly time to generate the full mtspr
> instruction. My solution was to use a macro for this, rather than a
> function (even a static inline function won't work):
>
> #define readSpr(sp) ({ uint32_t res; \
>asm volatile (" mfspr %[res], %[spr] " : \
>[res] "=r" (res) : \
>[spr] "i" (sp) ); \
>res; })
>
> #define writeSpr(sp, va) \
>asm volatile (" mtspr %[spr], %[val] " : \
>: \
>[spr] "i" (sp), [val] "r" (va) )
>
>
> mvh.,
>
> David
>
>
>
>> On 08/07/16 16:16, Tran Tu Truong wrote:
>> Dear Mr/Ms;
>>
>> I am Truong, working at Vietnam human engineering in Vietnam.
>> Now, I am using D32 Design Studio for programming MPC5777C micro
>> controller (GNU C Compiler 4.9). I've already made a sample inline asm
>> code in .C file ase bellow:
>> void set_spr ( uint32_t spr_num, uint32_t val )
>> {
>> asm volalatile ("mtspr %0, %1"
>> :
>> :"r"(spr_num), "r"(val)
>> );
>> }
>> This code does not work correct (It should work but not work). I found
>> out the constraints operands [:"r"(spr_num),] is not correct. I thinks
>> it better if spr_num is be referred as a constant not a register ( ex:
>> mtspr 120, val ). But I don't know how to revise.
>> I also referred on
>> https://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints
>> about PowerPC but I cannot understand clearly.So, could you please
>> help me to explain about that?
>> If you have the instruction about "constraints for asm operands" for
>> MPC5777C micro controller, please provide me.
>>
>> Thank you.
>> --Tran Tu Truong--
>
gcc-4.9-20160713 is now available
Snapshot gcc-4.9-20160713 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160713/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 238314 You'll find: gcc-4.9-20160713.tar.bz2 Complete GCC MD5=bda65eaa21e3f3dfa3a548eff2e0229e SHA1=563bef1e99c2739c8f3deb01157e6d92ba7e3ad9 Diffs from 4.9-20160706 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
Hi Matthew, I'm back to this effort now, thanks for patience. > Thanks for the update. I've read through the whole proposal again and > it looks good. I'd like to discuss legacy objects a bit more though... Thanks for your review. > > 3.4 Relocatable Object Generation > > > > Tools that produce relocatable objects such as the assembler shall > > always produce a SHT_MIPS_ABIFLAGS section according to the IEEE Std 754 > > compliance mode selected. In the absence of any explicit user > > instructions the `strict' mode shall be assumed. No new `legacy' > > objects shall be produced. > > Is it necessary to say that no new legacy objects can be created? It is of course not necessary in the sense that we are free to make a decision here rather than being constrained by hardware or another technical requirement. However I think only supporting the two explicit `strict' and `relaxed' modes makes the solution proposed consistent, and has indeed been the basis of my design. The principle I have followed here has been that it's the author of software who knows exactly what his code requires for correct operation, and sets the correct flags in the Makefile or whatever build system he uses. Joseph's earlier proposal to have a generic `-fieee' option rather than a target one fits here very well in that the author can stick it in the build system without the exact knowledge of what target-specific constraints may be. Such an option would preferably be placed such that it is not accidentally lost e.g. with an OS distribution packager's CFLAGS override, which is typically made in a system-wide automated way when a distribution is build. Still a distribution packager or another person building their piece of software of interest, perhaps individually, has control here, being able to change build options one way or another, at least by patching Makefiles if necessary. So they can choose `strict' or `relaxed' as needed. Finally the system administrator configuring a system or the individual user running software has the least knowledge of the low-level requirements of individual pieces of software. So ideally we'd not even have these kernel override modes and unconditionally treat `legacy' binaries as `strict', under the principle of the least surprise. Realistically however that would make the transition to R5/R6 very painful for people, requiring them to rebuild all software previously built for the legacy NaN encoding, even though only a small subset of software actually relies on the semantics of signalling NaNs. And this is exactly where the idea of a user-selectable kernel acceptance mode came from. I expect that both existing and new installations on legacy-NaN hardware will continue operating with the `strict' conformance mode and won't ever have to switch that as any new software built for pre-R5 targets and with the 2008-NaN encoding in mind will be built as `relaxed' binaries. Whereas virtually all R5/R6 installations will run in the `relaxed' conformance mode, permitting the use of any existing pre-R5 `legacy' binaries, however with the risk of some of them producing the wrong results. Consequently allowing new tools to build more `legacy' binaries will just let the issue continue where the mode software being run in depends on the hardware configuration rather than a conscious choice of the software packager. Whereas support for running `legacy' binaries in the `relaxed' mode is really there to help people transition. > I think there is value in still being able to generate legacy objects because > of the fact that strict executables leave no room for override at runtime. > Apart from the fact that strict cannot be disabled there is otherwise no > difference between legacy and strict compliance modes. Can you please be more specific? Where's the value from letting people override the mode of software known to require signalling NaN support? > I believe the strict option is really intended for conscious use so that > programmers who know they need it, can use it. Ordinary users still get the > casual safety they need as legacy objects are just as good as strict until > overridden. If we lose the ability to override then in some environments we > will accumulate lots of needlessly strict executables just because of a tools > upgrade whereas the old tools would have generated executables that were as > safe but also could be overridden by kernel options. I think the casual safety is an illusion. As soon as a user gets an execution error from a legacy-NaN legacy binary on 2008-NaN hardware (or vice versa), they'll hit Google or discussion list archives for a solution, find the `ieee754=relaxed' kernel option, stick it into their bootloader configuration and forget about it, running all their software from the on in the `relaxed' mode anyway. Eventually distributions will probably do that as well even if they built their own pack
Re: "error: static assertion failed: [...]"
On 07/13/2016 07:26 AM, Thomas Schwinge wrote:
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static assertion failed: "foo"
_Static_assert(0, "foo");
^~
..., and for C++ we diagnost:
[...]:4:1: error: static assertion failed: foo
static_assert(0, "foo");
^
("foo" quoted vs. un-quoted.) Assuming this difference between C and C++
diagnostics is not intentional, which one should we settle on? I thought
I'd like the un-quoted version better, but judging by Martin's recent
wiki change (see below), "foo" is a string constant, so should be quoted
in diagnostics? If yes, OK to commit to trunk the obvious changes (plus
any testsuite updates)?
I hadn't thought of this case. I don't have a personal preference
but I can provide a few data points to help with the decision (or
maybe muddy the waters).
Neither the C nor the C++ standard specifies whether or not to
include the quotes. Both simply require that
...the implementation shall produce a diagnostic message that
includes the text of the string literal, ...
Of the compilers I tried (Clang, EDG eccp, IBM XLC, Microsoft
Visual C++, and Oracle CC), more include the quotes in both
languages than not. IBM XLC only quotes the C++ text, the
opposite of G++. Visual C++ doesn't quote the C++ text and
doesn't understand the C11 _Static_assert.
From other similar constructs, C and C++ specify that the #error
directive include the preprocessing tokens that follow it (i.e.,
including quotes).
GCC doesn't include the quotes when printing the string argument
in attribute error.
Martin
For reference:
On Tue, 12 Jul 2016 22:34:17 -, GCC Wiki wrote:
The "DiagnosticsGuidelines" page has been changed by MartinSebor:
https://gcc.gnu.org/wiki/DiagnosticsGuidelines?action=diff&rev1=7&rev2=8
Comment:
Added a table of contents and a Quoting section.
+ === Quoting ===
+
+ The following elements should be quoted in GCC diagnostics, either using the
{{{q}}} modifier in a directive such as {{{%qE}}}, or by enclosing the quoted text in
a pair of {{{%<}}} and {{{%>}}} directives:
+
+ * Language keywords.
+ * Tokens.
+ * Boolean, numerical, character, and string constants that appear in the
source code.
+ * Identifiers, including function, macro, type, and variable names.
+
+ Other elements such as numbers that do no refer to numeric constants that
appear in the source code should not be quoted. For example, in the message:
+ {{{#!highlight c++ numbers=disable
+ argument %d of %qE must be a pointer type
+ }}}
+ since the argument number does not refer to a numerical constant in the
source code it should not be quoted.
Grüße
Thomas
Re: "error: static assertion failed: [...]" (was: [GCC Wiki] Update of "DiagnosticsGuidelines" by MartinSebor)
On 13/07/16 14:26, Thomas Schwinge wrote:
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static assertion failed: "foo"
_Static_assert(0, "foo");
^~
..., and for C++ we diagnost:
[...]:4:1: error: static assertion failed: foo
static_assert(0, "foo");
^
("foo" quoted vs. un-quoted.) Assuming this difference between C and C++
diagnostics is not intentional, which one should we settle on? I thought
I'd like the un-quoted version better, but judging by Martin's recent
wiki change (see below), "foo" is a string constant, so should be quoted
in diagnostics? If yes, OK to commit to trunk the obvious changes (plus
any testsuite updates)?
From a diagnostics point-of-view, neither version is quoted:
c/c-parser.c: error_at (assert_loc, "static assertion failed: %E", string);
cp/semantics.c: error ("static assertion failed: %s",
To be "quoted", it would need to use either %q or %<%>. Note that %qs would
produce `foo' not "foo". Nevertheless, we probably want to print 'x' for
character literals and not `'x'' and "string" for string literals and not
`string'. Thus, the wiki should probably be amended to clarify this.
Also, there is a substantial difference between %E and %s when the string
contains control characters such as \n \t \u etc. Clang uses something similar
to %E.
For comparison, we use %s to print
test.c:1:9: note: #pragma message:
string
#pragma message "\nstring"
^
Cheers,
Manuel.
