Il 22/04/2013 15.13, Angelo Graziosi ha scritto:
Il 22/04/2013 15.03, Dave Korn ha scritto:
On 22/04/2013 13:51, Angelo Graziosi wrote:
Il 16/04/2013 10.10, Dave Korn ha scritto:
This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
From comment 5 and 9 something should be fi
reed kotler writes:
> Consider the following function:
> void floatvf(float x) {
> }
>
> The compiled with:
> mips-linux-gnu-gcc -mips16 mips16_fpcall.c -S -fPIC -EL
>
>
> The stub looks like this:
>
> __fn_stub_floatvf:
> .setnoreorder
> .cpload$25
> .setreorder
>
On Sunday 21 April 2013, Jonathan Wakely wrote:
> I'm starting to implement some new library features voted into C++14
> at the Bristol meeting and am wondering what feature check to use.
>
> Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to correspond to
> -std=c++1y?
>
> Alternatively we
On 04/22/2013 12:42 PM, Jason Merrill wrote:
The proposal will be at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
It's now been posted at http://isocpp.org/files/papers/N3649.html
Jason
The documentation of __builtin_constant_p is somewhat informal. It just
says:
The function
returns the integer 1 if the argument is known to be a compile-time
constant and 0 if it is not known to be a compile-time constant.
But what is a compile-time constant?
My gut feeling is that anything
On Tue, Apr 23, 2013 at 8:15 AM, Allan Sandfeld Jensen
wrote:
> On Sunday 21 April 2013, Jonathan Wakely wrote:
>> I'm starting to implement some new library features voted into C++14
>> at the Bristol meeting and am wondering what feature check to use.
>>
>> Will there be a macro like _GXX_EXPERI
On Tue, Apr 23, 2013 at 9:01 AM, Piotr Wyderski
wrote:
> Gabriel Dos Reis wrote:
>
>> C++03 was essentially bug fixes to C++98 so we did not make the
>> distinction.
>> C++14 is more than bug fixes to C++11, it contains many new extensions.
>> So I am unsure the situations are similar.
>
> Where c
Joern Rennecke writes:
>
> More importantly. addresses that becomes a SYMBOL_REF should be considered
> constant. I.e. In particular, the addresses of variables with static storage.
> I have a simple patch to recognize these as constants;
> do people agree that this is the right thing to do?
if
Hi,
Gabriel Dos Reis ha scritto:
>There appear to be two targets: C++14 and C++17. Personally, I am
>inclined
>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
This clarified - thanks - I'm wondering if it's safe to assume that the C++14
library is a superset of the C++1
Quoting Andi Kleen :
if (__builtin_constant_p(x) && x == 1) ... and assume the compiler can
collapse at compile time then a SYMBOL_REF wouldn't DTRT.
Unless you set x to the address of a variable / function and this is
constant-propagated, x will not become a SYMBOL_REF.
If x is a variable wit
Hi again,
Paolo Carlini ha scritto:
>Hi,
>
>Gabriel Dos Reis ha scritto:
>
>>There appear to be two targets: C++14 and C++17. Personally, I am
>>inclined
>>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
>
>This clarified - thanks - I'm wondering if it's safe to assume t
Hi,
with GCC 4.1 and GCC 4.4 (RHEL 5.9) the example below prints a value
of 1 for netwait (on x86_64 and s390x). The problem is that the
assignment at /* 2 */ is moved to /* 1 */ during instruction
scheduling.
The quick fix is to make "netwait" volatile. But according to the C
standard (7.13.2.
On 23 April 2013 15:29, Paolo Carlini wrote:
> Hi,
>
> Gabriel Dos Reis ha scritto:
>
>>There appear to be two targets: C++14 and C++17. Personally, I am
>>inclined
>>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
>
> This clarified - thanks - I'm wondering if it's safe to
Hi,
Jonathan Wakely ha scritto:
>But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, we
>check __cplusplus >= 201103L, and so within those chunks we could
>additionally check for some C++14 macro.
Right, forgot that. Great. The >= check we have got now makes things much
easier in
On Tue, Apr 23, 2013 at 9:29 AM, Paolo Carlini wrote:
> Hi,
>
> Gabriel Dos Reis ha scritto:
>
>>There appear to be two targets: C++14 and C++17. Personally, I am
>>inclined
>>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
>
> This clarified - thanks - I'm wondering if it
On Tue, Apr 23, 2013 at 9:47 AM, Jonathan Wakely wrote:
> But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway,
yes, this was a great move; kudos to whoever did it.
> we
> check __cplusplus >= 201103L, and so within those chunks we could
> additionally check for some C++14 macro.
Ag
On 23 April 2013 15:54, Gabriel Dos Reis wrote:
> On Tue, Apr 23, 2013 at 9:47 AM, Jonathan Wakely
> wrote:
>
>> But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway,
>
> yes, this was a great move; kudos to whoever did it.
That was Jason, when he changed the front end to set __cplusp
On 04/23/2013 04:45 PM, Andreas Krebbel wrote:
I was not able to reproduce the problem with head GCC. But I couldn't
find anything which addresses the problem either. So I assume that a
different situation before the scheduling pass hides the problem.
The fix for PR56982 might address this one
I've made a proposal under the guide of application. Is it detailed
and realistic?
By the way, here is a naive version of my implementation of
lookup_name in regex_traits :
https://gist.github.com/innocentim/5445457
It's not GCC style but will be, if everything else's fine. So, am I in
the right
I decided to take a crack at the coremark optimization (PR 54742) for switch
statements. Since I couldn't figure out the existing jump threading
optimization enough to extend it properly, I decided to try a plugin
optimization pass just for this case and see if I could get that to work.
The basic
On 04/23/2013 02:43 PM, Steve Ellcey wrote:
I think I have code that finds the path that I am interested in, but when
I try to use copy_bbs to copy the basic blocks in order to create my new path,
I get segfaults. I was wondering if anyone could help me understand what I
need to do, in addition
Hi,
Here's a simple program:
#include
#include
int main()
{
std::vector vec;
count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
}
The above compiles successfully, but I think it shouldn't. I expect a
message like "error: `count` not declared in scope" because I meant t
On 04/23/2013 11:26 PM, bd satish wrote:
Hi,
Here's a simple program:
#include
#include
int main()
{
std::vector vec;
count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
}
The above compiles successfully, but I think it shouldn't. I expect a
message like "error: `co
Thanks Paolo, ADL is news to me.
On 24 April 2013 01:43, Paolo Carlini wrote:
> You are: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup
>
> Paolo.
>
> Here's a simple program:
>
> #include
> #include
>
> int main()
> {
> std::vector vec;
> count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
> }
>
> The above compiles successfully, but I think it shouldn't. I expect a
> message like "error: `count` not declared in scope" becaus
25 matches
Mail list logo
