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 i
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
> 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?
> 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
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 fun
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 sta
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-statem
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 #
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
