Re: Failure building current snapshot [Cygwin]
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 fixed but with current snapshot, 4.9-20130421, it seems that the build fails in the same way: Nothing's been checked in yet. Tests look good though, so we should be able to proceed soon. Ah, sorry for the noise then.. Just for the record, applying the patch in comment #8 works just fine and snapshot 4.9-20130421 builds... Thanks! Ciao, Angelo.
Re: mips16 stubs
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
> .reloc0,R_MIPS_NONE,floatvf
> la$25,__fn_local_floatvf
> mfc1$4,$f12
> jr$25
> .end__fn_stub_floatvf
> __fn_local_floatvf = floatvf
>
>
> What is the purpose of this .reloc and this __fn_local_floatvf = floatvf ?
__fn_local_floatvf = floatvf creates a local symbol alias for a
locally-defined global function. The idea is that:
la $25, __fn_local_floatvf
then uses a page GOT access, ensuring the stub does not force the
creation of stub-specific GOT entries.
The difficulty with:
la $25, floatvf
is that it would appear to the assembler and linker as a global GOT
reference (because floatvf is global). However, the relocation actually
resolves to the MIPS16 function, whereas other non-stub instances of:
la $25, floatvf
should resolve to the stub. So we would have the strange (and currently
unsupported) situation that the same symbol could need two GOT entries,
one local entry pointing to the MIPS16 address and one global entry
containing the canonical function address (i.e. the stub). Or,
if floatvf is hidden, we could end up with two different local GOT
entries for the same symbol.
The .reloc ensures that the first relocation in the stub section points
to the stubbed function (rather than its alias). That's how the linker
works out which function is being stubbed.
Thanks,
Richard
Re: Macro for C++14 support
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 could set the value of __cplusplus to 201400L but I'm > not sure that's strictly allowed. Isn't C++14 only an update of the standard library not the language, and should that affect how GCC treats it? If that is the case (I could have missed something). Would it be possible to include it under C++11 support instead of having to have users update their GCC switches just to link to a libstdc++ with slightly more features? Best regards `Allan
Re: [lambda] Latest experimental polymorphic lambda patches
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
RFD: Should __builtin_constant_p approximate CONSTANT_P ?
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 that is CONSTANT_P at rtl level should qualify. But then, fold_builtin_constant_p goes to a lot of trouble to reject perfectly fine addresses. Not only the address of the first element of a character array should be considered constant, but any constant offset should be fine. 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?
Re: Macro for C++14 support
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_EXPERIMENTAL_CXX1Y__ to correspond to >> -std=c++1y? >> >> Alternatively we could set the value of __cplusplus to 201400L but I'm >> not sure that's strictly allowed. > > Isn't C++14 only an update of the standard library not the language, As explained in numerous postings, that isn't the case. See http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting -- Gaby
Re: Macro for C++14 support
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 can I find more about the upcoming standard? Google seems to be > confused by a popular isotope of carbon... :-/ > > Best regards, Piotr Until WG21 releases the post-Bristol mailing, you can check http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting In general, http://www.isocpp.org/ is the "official" website of WG21; you can find more information there about C++ and more. -- Gaby
Re: RFD: Should __builtin_constant_p approximate CONSTANT_P ?
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 someone writes if (__builtin_constant_p(x) && x == 1) ... and assume the compiler can collapse at compile time then a SYMBOL_REF wouldn't DTRT. I've seen quite a bit such code. So I would prefer to accept only numbers known at compile time already. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: Macro for C++14 support
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++11 one: in that case passing -std=c++14 would also automatically define the C++11 macro and I see a tiny front-end patch going in followed by smooth progress in library. Otherwise - if -std=c++14 does *not* automatically define the C++11 macro too - we also need a ton of boring changes in the library, where things become wrapped in C++11 macro || C++14 macro. Did I explain myself clearly enough? Paolo
Re: RFD: Should __builtin_constant_p approximate CONSTANT_P ?
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 with static storage, it will be a MEM (symbol_ref). &x will be a SYMBOL_REF.
Re: Macro for C++14 support
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 that the >C++14 library is a superset of the C++11 one: in that case passing >-std=c++14 would also automatically define the C++11 macro Well, on second thought, I think we could do this anyway and be done in the wast majority of cases. Then, in special cases, where say the same facility is different in the two standards, we can always check both macros. I see now the issue mostly as a documentation issue: we would have to explain the users that -std=c++14 defines the C++11 macro too. This is *not* the same as -std=c++11 vs -std=c++98. If it's a problem, back to the huge search&replace ;) Paolo
setjmp/longjmp: Wrong code generation
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.1) this should only be necessary if the value is
modified between setjmp and longjmp.
http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html#Incompatibilities
shows an example which also modifies the variable between
setjmp/longjmp. However, a sentence in the same section is more
general and suggests to always use volatile: "When you use setjmp and
longjmp, the only automatic variables guaranteed to remain valid are
those declared volatile."
I'm wondering whether the behaviour in the example below is accepted
and is supposed to be covered by the paragraph on the
"incompatibilies" page or whether we should try to fix this? In the
end it is still a standard violation so I think we should?!
A possible fix might be to consider all function calls in the function
scope of setjmp to be full scheduling barriers.
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.
Bye,
-Andreas-
#include
#include
jmp_buf jmpbuf;
void __attribute__((noinline))
calls_longjmp()
{
longjmp(jmpbuf, 2);
}
int __attribute__((noinline))
foo ()
{
return 42;
}
void __attribute__((noinline))
bar (int netwait, int cnt)
{
int i;
int err;
while (netwait)
{
netwait = 0;
for (i = cnt; --i >= 0;)
{
if (setjmp(jmpbuf) == 0)
{
err = foo ();
/* 1 */
if (err != 2344)
calls_longjmp();
netwait = 1; /* 2 */
}
else
{
printf ("netwait: %d\n", netwait);
netwait = 0;
}
}
}
}
int
main ()
{
bar (1, 1);
}
Re: Macro for C++14 support
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 assume that the C++14 > library is a superset of the C++11 one: in that case passing -std=c++14 would > also automatically define the C++11 macro and I see a tiny front-end patch > going in followed by smooth progress in library. Otherwise - if -std=c++14 > does *not* automatically define the C++11 macro too - we also need a ton of > boring changes in the library, where things become wrapped in C++11 macro || > C++14 macro. Did I explain myself clearly enough? If the ~thread motion, N3636, passed then the C++11 and C++14 libraries are incompatible. N3657 adds new member function overloads to existing library types, but should do so in a backward-compatible way (that was the point of the final revision of Joaquin's paper.) 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.
Re: Macro for C++14 support
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 the C++11 -> C++14 transition. Thus fine, just >= 201103L + the macro is all we need. Paolo
Re: Macro for C++14 support
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's safe to assume that the C++14 > library is a superset of the C++11 one: in that case passing -std=c++14 would > also automatically define the C++11 macro and I see a tiny front-end patch > going in followed by smooth progress in library. Otherwise - if -std=c++14 > does *not* automatically define the C++11 macro too - we also need a ton of > boring changes in the library, where things become wrapped in C++11 macro || > C++14 macro. Did I explain myself clearly enough? > > Paolo > > There was the drama about thread::~thread; I don't know how it was finally resolved. But I was under the impression that that issue and another from library broke some ABI. Benjamin might have more information. -- Gaby
Re: Macro for C++14 support
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. Agreed. -- Gaby
Re: Macro for C++14 support
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 __cplusplus correctly.
Re: setjmp/longjmp: Wrong code generation
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 in a reliable fashion, too. -- Florian Weimer / Red Hat Product Security Team
[GSoC] Does this proposal look good?
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 direction? Thanks! -- Tim Shen Completing C++11 regex * The Project This proposal aims to implement regex interfaces required by the C++11 standard as much as the student can. Besides, I get a clear status here(http://stackoverflow.com/questions/12530406/is-gcc4-7-buggy-about-regular-expressions) and here(http://gcc.gnu.org/bugzilla/show%5C_bug.cgi?id=53631) :) * Goal To finish: regex_traits format in match_results regex_iterator regex_token_iterator different styles in basic_regex * Time-line May 27 - June 30 Read basic regex and regex nfa, try submit small patches, get familiar with GCC workflow, coding and documenting style July 1 - July 7 Complete regex traits July 8 - July 14 Implement format in match results July 15 - July 21 Implement regex iterator July 22 - July 28 Implement regex token iterator July 29 - Aug 31 Implement different styles(basic, extended, awk, grep and egrep) Sep 1 - Sep 16 Undefined so far. Must have some ideas at that time. * Details ** regex_traits Not tough. However on how to implement transform_primary for all platform, I need to ask in the mail list or ask the mentor. ** Format string, iterators Shouldn't be tough. This is a deeper practicing. ** Different regex styles It's the core part. I should already know anything about basic_regex and regex_nfa(even have made changes, I'm very interested in algorithms of compiling to NFA/DFAs and executing approaches). Then get to know all flavors of regular expressions. My experiences of compilers may help.
How do I modify SSA and copy basic blocks?
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 idea is to find a path from where a variable is assigned a constant
value to where that variable is used in a switch statement. Then I want to
duplicate the blocks in that path (thus removing any alternative entry points
into the path that may give the variable a different value) and plug it into
the cfg.
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 to calling copy_bbs, to create my new path and keep
the various ssa and cfg information up to date, either by modifying it or by
blowing it away and regenerating it, I am not worried about compilation speed
at this point so if regenerating all the SSA/cfg data is easiest, I am happy
to do that.
Attached is my plugin as it exists right now and a simple test case using a
switch statement. I am not including the actual coremark code because it is
copyrighted. If you run my example you will see output showing 4 places where
I think I can do my optimization. For example we assign t the value of 0 in
block 2 and from there we go to block 8 and (possibly) to block 3 where we have
our switch statement.
So what I try to do is copy blocks 8 and 3 and change the edge from block
2 to block 8 to go from block 2 to my new copy of block 8 which should
then go to the new copy of block 3. After this we should be able to
optimize the new copy of block 3 to finish with a goto to the 'case 0'
label instead of with a switch/goto.
If you remove the '#if 0' in my code where I comment out the call to
copy_bbs, you will get a seg fault, this is the code that I need help
with. For example, If I copy block 8 and block 3, and there is an edge
from 8 to 3, does copy_bbs automatically create a new edge pointing from the
copy of block 8 to block 3 and replace that in the copied blocks? I think it
does, but I am not sure.
Steve Ellcey
sell...@imgtec.com
Output from the test program using my new optimization phase.
In plugin, registering new pass
Block 2 assigns variable t a constant value of 0
Basic blocks (leading from basic block 2 to switch) are:
8
3
Block 4 assigns variable t a constant value of 1
Basic blocks (leading from basic block 4 to switch) are:
7
8
3
Block 5 assigns variable t a constant value of 2
Basic blocks (leading from basic block 5 to switch) are:
7
8
3
Block 6 assigns variable t a constant value of 1
Basic blocks (leading from basic block 6 to switch) are:
7
8
3
/* This file implements an optimization where, when a variable is set
to a constant value and there is a path that leads from this definition
to a switch statement that uses that variable as its controlling expression
we duplicate the blocks on this path and change the switch goto to a
direct goto to the label of the switch block that control would goto based
on the value of the variable. */
#include
#include
#include
#include
#include
#include
#include
#include
#include
int plugin_is_GPL_compatible;
/* Helper function for find_path, visited_bbs is used to make sure we don't
fall into an infinite loop. */
static int
find_path_1(basic_block start_bb, basic_block end_bb, struct pointer_set_t *visited_bbs)
{
edge_iterator ei;
edge e;
if (start_bb == end_bb) return 1;
if (!pointer_set_insert (visited_bbs, start_bb))
{
FOR_EACH_EDGE (e, ei, start_bb->succs)
if (find_path_1 (e->dest, end_bb, visited_bbs)) return 1;
}
return 0;
}
/* Return 1 if there is a path from start_bb to end_bb and 0 if there
is not. */
static int
find_path(basic_block start_bb, basic_block end_bb)
{
edge_iterator ei;
edge e;
struct pointer_set_t *visited_bbs;
int p = 0;
if (start_bb == end_bb) return 1;
visited_bbs = pointer_set_create ();
if (!pointer_set_insert (visited_bbs, start_bb))
{
FOR_EACH_EDGE (e, ei, start_bb->succs)
if (find_path_1 (e->dest, end_bb, visited_bbs))
{
p = 1;
break;
}
}
pointer_set_destroy (visited_bbs);
return p;
}
/* bbs_list[0] is the block with the switch statement,
bbs_list[n-1] is the block where the switch statement variable is assigned
a constant value,
The entries in between make a (reverse) path between the two.
We don't want to copy bb_list[n-1], we want to leave that alone and
copy bb_list[n-2]...bb_list[0], and change the edge from bb_list[n-1]
to bb_list[n-2] to point to the copy of bb_list[n-2]. Then we
should change the switch in bb_list[0] to a simple goto, but maybe we
can let a later optimization phase (constant propogati
Re: How do I modify SSA and copy basic blocks?
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 to calling copy_bbs, to create my new path and keep the various ssa and cfg information up to date, either by modifying it or by blowing it away and regenerating it, I am not worried about compilation speed at this point so if regenerating all the SSA/cfg data is easiest, I am happy to do that. Well, you have to copy the blocks, adjust the edges and rewrite the SSA graph. I'd use duplicate_block to help. You really want to look at tree-ssa-threadupdate.c. There's a nice big block comment which gives the high level view of what needs to happen when you copy a block for this kind of optimization. Feel free to ignore the implementation which has to be fairly efficient when there's a large number of edges to update. Jeff
std::count leaked outside namespace std?
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 to
say std::count. Isn't this a bug, or am I missing something?
Behaviour is reproducible with both GCC 4.7 and 4.8.
PS: I'm not subscribed to mailing list, please keep me in cc.
Thanks,
Satish
Re: std::count leaked outside namespace std?
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: `count` not declared in scope" because I meant to
say std::count. Isn't this a bug, or am I missing something?
You are: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup
Paolo.
Re: std::count leaked outside namespace std?
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. >
RE: std::count leaked outside namespace std?
> 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 to
> say std::count. Isn't this a bug, or am I missing something?
It is not a bug. std::count is being found by argument-dependent lookup [1].
Regards,
Nate
[1] http://en.wikipedia.org/wiki/Argument-dependent_name_lookup
