RE: cpp0x test suite PASS/FAIL
Ok so it's a problem local to my environment that I must fix. I've downloaded
the lastest dejagnu 1.5.1 but it doesn't solve the problem.
I found in no documentation the selector 'target c++98' but it should exist
somewhere because about 20 c++11 tests use it and FAIL the same way.
I'll try to investigate further (tcl is a pain for me :) )
Selim
-Message d'origine-
De : Joseph Myers [mailto:jos...@codesourcery.com]
Envoyé : mardi 10 décembre 2013 18:57
À : BELBACHIR Selim
Cc : gcc@gcc.gnu.org
Objet : RE: cpp0x test suite PASS/FAIL
On Tue, 10 Dec 2013, BELBACHIR Selim wrote:
> The selector 'target c++98' (in { dg-error "std=" "std" { target c++98
> } } for example) do not prevent the FAIL to be printed when -std=c++11
> options is used.
Well, that would be a bug in one of (a) the test harness code, (b) the way the
selector is used, (c) your DejaGnu installation. In none of those cases is
ignoring the FAIL appropriate; both (a) and (c) could well cause other problems
with inaccurate test results elsewhere in the testsuite.
You'll need to investigate why DejaGnu isn't behaving as intended on your
system.
--
Joseph S. Myers
jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
On Tue, Dec 10, 2013 at 7:42 PM, DJ Delorie wrote: > >> (For the types you do have, there's a need to define C++ name mangling. > > I mentioned this before, and I don't have a good solution for it. > Both C++ and LTO need a mangled form of __intN types. LTO shouldn't need any of this. Ideally we'd reduce the number of middle-end visible global trees down to the set that is fully defined by the target C ABI. All extra standard types relevant for frontends would simply be streamed (you can as well stream all trees, including the global ones - we chose to not stream them as optimization though and because of pointer comparisons with them throughout the middle-end, notably for va_list stuff). Richard.
RE: Issues with GCSE pre step and double hard registers
> I don't think this is not the right fix for the problem. GCSE doesn't handle > expressions containing hard registers, oprs_unchanged_p should never even > see expressions involving hard registers. I was afraid of this one. > > What is the expression that is recorded as anticipated in insn 38? Is it > "mho:SI > 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note? > Instruction 38. As far as I can see, a solution is to use a split pattern after register allocation to describe the multiplication (now it is done in the expand). Another one, is to force the gcse to check the regnotes (REG_EQUAL) rather than the instruction itself. Best, Claudiu
RE: Issues with GCSE pre step and double hard registers
> What is the expression that is recorded as anticipated in insn 38? Is it > "mho:SI > 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note? Just to be clear, the anticipated operation is "mho:SI 0>>9x31". //Claudiu
RE: cpp0x test suite PASS/FAIL
I found a potential problem in "dejagnu-1.5.1/lib/framework.exp" (or previous
version)
As I said before, in my case, the selector 'target std=c++98' doesn't seems to
prevent the FAIL when -std=c++11 options is used in compiler flags.
I noticed that -std=c++11 is my last compiler flag and in function
"check_conditional_xfail" from dejagnu-1.5.1/lib/framework.exp (called by
check-flags from gcc-4.7.3/gcc/testsuite/lib/target-supports-dg.exp) I saw the
following lines :
verbose "Looking for $opt to exclude in the compiler flags" 2
foreach j "$opt" {
if {[string match "* $j *" $compiler_flags]} {
verbose "Found $j to exclude in the compiler flags" 2
incr excl_hit
}
}
'string match' uses "* $j *" , i.e. a white space is required after each option
in order to be properly matched. When an option is the last compiler flag then
it cannot be matched because it is not followed by a white space. This explains
why the dg-error is not ignored when compiler with -std=c++11 even if selector
'target c++98' is used.
I may be the only one to meet this exact problem because for some reasons
-std=c++xx options is my last flag AND some tests use a selector on this
particular flag. But, imho the problem can be met on any other flag as far as
it is the last compiler flag.
Answer : (a) bug in the test harness code
Am I right ?
Selim
-Message d'origine-
De : Joseph Myers [mailto:jos...@codesourcery.com]
Envoyé : mardi 10 décembre 2013 18:57
À : BELBACHIR Selim
Cc : gcc@gcc.gnu.org
Objet : RE: cpp0x test suite PASS/FAIL
On Tue, 10 Dec 2013, BELBACHIR Selim wrote:
> The selector 'target c++98' (in { dg-error "std=" "std" { target c++98
> } } for example) do not prevent the FAIL to be printed when -std=c++11
> options is used.
Well, that would be a bug in one of (a) the test harness code, (b) the way the
selector is used, (c) your DejaGnu installation. In none of those cases is
ignoring the FAIL appropriate; both (a) and (c) could well cause other problems
with inaccurate test results elsewhere in the testsuite.
You'll need to investigate why DejaGnu isn't behaving as intended on your
system.
--
Joseph S. Myers
jos...@codesourcery.com
Re: break in statement expression in while condition fails to compile
On Tue, Dec 10, 2013 at 10:16 PM, Florian Weimer wrote:
> On 12/10/2013 02:21 PM, Prathamesh Kulkarni wrote:
>>
>> The following code fails to compile with gcc-4.8.2.
>>
>> int main(void)
>> {
>> while ( ({ break; 0; }) )
>> ;
>> return 0;
>> }
>>
>> foo.c:3:14: error: break statement not within loop or switch
>> while ( ({ break; 0; }) )
>>^
>> Is this a compile-error or is it a bug in GCC ?
>> clang-3.2 seems to compile it.
>>
>> I came across a thread on this issue
>> in context of for loop, but I couldn't get a definite answer.
>> http://gcc.gnu.org/ml/gcc-help/2013-07/msg00100.html
>
>
> There's also bug .
Thanks for pointing it out.
>From the bug-report (comment 4):
Here is what the c++ standard says :
"The break statement shall occur only in an iteration-statement or a switch
statement and causes termination of the smallest enclosing iteration-statement
or switch statement; control passes to the statement following the terminated
statement, if any."
So the break (if the expression statement extension is activated) is considered
in the inner loop with this extension.
So I guess g++ should compile it ?
g++ rejects it too:
foo.cpp:3:14: error: break statement not within loop or switch
while ( ({ break; 0; }) )
>
> I think it's fine to reject such code.
>
> --
> Florian Weimer / Red Hat Product Security Team
Thanks and Regards,
Prathamesh
Re: break in statement expression in while condition fails to compile
On Wed, Dec 11, 2013 at 07:13:47PM +0530, Prathamesh Kulkarni wrote:
> >From the bug-report (comment 4):
> Here is what the c++ standard says :
> "The break statement shall occur only in an iteration-statement or a switch
> statement and causes termination of the smallest enclosing iteration-statement
> or switch statement; control passes to the statement following the terminated
> statement, if any."
> So the break (if the expression statement extension is activated) is
> considered
> in the inner loop with this extension.
>
> So I guess g++ should compile it ?
> g++ rejects it too:
> foo.cpp:3:14: error: break statement not within loop or switch
>while ( ({ break; 0; }) )
Statement expressions are GCC extensions and without that extension,
you can't put a break or continue anywhere in a loop but in the loop
body, so the exact wording of the standard isn't that important, for
standard conforming C and C++ that wording nuances make no difference, what
matters is how we define the extension and (ideally) document it if it isn't
documented yet. Similarly what exactly clang implements here isn't that
important, as they just implemented the GCC extension, either correctly, or
not.
Jakub
replace do-while macros with static inline functions
I was wondering if it was a good idea to replace do-while macros with
static inline functions returning void, where appropriate ?
By "where appropriate" I mean:
a) call to macro contains no side-effects
b) macro does not modify the arguments.
c) macro does not use any preprocessor operators (like ##)
d) macro does not get undefined or is conditionally defined.
e) macro is not type independent (use inline template for these?)
f) Any other case ?
Example:
Consider C_EXPR_APPEND macro defined in c-tree.h:
/* Append a new c_expr_t element to V. */
#define C_EXPR_APPEND(V, ELEM) \
do { \
c_expr_t __elem = (ELEM); \
vec_safe_push (V, __elem); \
} while (0)
It is called at two places in c-parser.c:
0 c-parser.c 6140 C_EXPR_APPEND (cexpr_list, expr);
1 c-parser.c 6145 C_EXPR_APPEND (cexpr_list, expr);
Shall be replaced by:
static inline void
C_EXPR_APPEND( vec * V, c_expr_t ELEM)
{
vec_safe_push(V, ELEM);
}
I will volunteer to do it, if it's accepted.
Thanks and Regards,
Prathamesh
Are you the owner of gcc.gnu.org?
Hello, I found your email on the site and I was curious about something. Let me know if you're the right person to talk to. Thank you, Jennifer Walker
