Jason Merrill writes:
| On 06/01/2013 10:57 AM, Gabriel Dos Reis wrote:
| > Well, we don't want to check cxx0x one place and cxx11 others.
|
| But we still do.
Fixed with this.
-- Gaby
2013-06-22 Gabriel Dos Reis
* c-common.c (c_common_nodes_and_builtins): Use cxx11 in lieu of cxx
Oleg Endo wrote:
> the attached patch fixes volatile mem loads on SH so that they won't
> result in redundant sign extensions and also utilize the available
> addressing modes.
>
> Tested on rev 200116 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-
Andrew Sutton writes:
| > | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
| > | parameters are either TYPE_DECLs or PARM_DECLs. I think auto
| > | declarations, get VAR_DECLs, but I haven't looked closely at that
| > | design. I'd have to look to see if there are any free
Andrew Sutton writes:
| > | Previous discussion seemed to indicate that saving constraints with
| > | template decls was preferable.
| >
| > Yes; exactly.
| >
| > | The committed version in the branch carries those constraints in
| > | template_info for the temploid.
| >
| > Yes; I think that is
> | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
> | parameters are either TYPE_DECLs or PARM_DECLs. I think auto
> | declarations, get VAR_DECLs, but I haven't looked closely at that
> | design. I'd have to look to see if there are any free tree slots all
> | of those decl
| But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
| parameters are either TYPE_DECLs or PARM_DECLs. I think auto
| declarations, get VAR_DECLs, but I haven't looked closely at that
| design. I'd have to look to see if there are any free tree slots all
| of those decl nodes to
> | Previous discussion seemed to indicate that saving constraints with
> | template decls was preferable.
>
> Yes; exactly.
>
> | The committed version in the branch carries those constraints in
> | template_info for the temploid.
>
> Yes; I think that is good.
So we should associate constraints
On Thu, Jun 20, 2013 at 1:41 PM, Jason Merrill wrote:
> It has always seemed odd that we didn't build a TEMPLATE_DECL for a partial
> specialization, and with the ongoing concepts work it has become more
> important to have one so that we can attach any requirements to it. Note
> that there is st
On Mon, Jun 3, 2013 at 6:15 PM, Jason Merrill wrote:
> On 06/01/2013 10:57 AM, Gabriel Dos Reis wrote:
>>
>> Well, we don't want to check cxx0x one place and cxx11 others.
>
>
> But we still do.
Testing a patch.
-- Gaby
Eric Botcazou wrote:
My autoconf foo does not seem to be strong enough for libgfortran,
but I assume checking for both types and then using #ifdef HAVE_FP_EXCEPT_T
...#elif HAVE_FP_EXCEPT...#endif ought to work?
Yes, I think that we just need to patch the LIBGFOR_CHECK_FPSETMASK check in
acinclu
Andrew --
At revision 200343.
With the merge of Cilk changes to trunk, it was necessary to synchronize
so that c++-concepts branch doesn't get too out of sync. There were a
few conflicts in cp/Make-lang.in and cp/cp-tree.h that I think I
resolved properly. Let me know if anything else was los
* We have to avoid increasing memory consumption for regular C++ codes
that do not use concepts lite. This is an important criteria. We
have only one front-end that is invoked in C++03, C++11, C++14, and
C++17 modes. Almost all existing codes are C++03, C++11, and even
C++14 only and do
Hi,
tested x86_64-linux, committed mainline and 4_8-branch.
Thanks,
Paolo.
///
2013-06-22 Paolo Carlini
PR libstdc++/57674
* include/bits/random.h (binomial_distribution<>::_M_waiting):
Add double parameter.
* include/bits/random.tcc (bino
Only 3 minor (self-inflicted) conflicts, but the attached patchlet is needed
after the latest LTO changes.
Bootstrapped/regtested on x86_64-suse-linux, applied on the branch.
2013-06-22 Eric Botcazou
* lto-streamer-out.c (hash_tree): Deal with TYPE_REVERSE_STORAGE_ORDER.
lto/
> | Agreed. But without some source-level annotations in the tree, I don't
> | think I can generate the diagnostics that programmer's might otherwise
> | expect. I'd have to emit the internal representation.
>
> Do you have examples where we don't do or we can't do the obvious thing
> in terms of d
> Except that now FreeBSD 10.x is broken. :-(
Death to the guy whose thought that adding/removing _t was a good idea...
> In file included from
> /scratch2/tmp/gerald/gcc-HEAD/libgfortran/runtime/fpu.c:29:0:
> ./fpu-target.h: In function 'get_fpu_except_flags':
> ./fpu-target.h:88:3: error: u
On Fri, 21 Jun 2013, Eric Botcazou wrote:
> The patch silently changes libgfortran/config/fpu-sysv.h as well,
> breaking Solaris in the process:
>
> In file included from /nile.build/botcazou/gcc-
> head/src/libgfortran/runtime/fpu.c:29:0:
> ./fpu-target.h: In function 'get_fpu_except_flags':
> .
Andrew Sutton writes:
| > Internally, we want to always store the canonical form of a decl, not the
| > source-level form -- the current g++ AST isn't prepared for that (I wish
| > it was, but it isn't.) This allows for simple comparison and other
| > semantics processing.
|
| Agreed. But witho
With coarrays, allocation/deallocation of coarrays requires a
synchronization with all other images. Thus, the standard restricts
changing the allocation status to: ALLOCATE and DEALLOCATE statements
plus end-of-scope deallocation.
In particular, with intrinsic assignment the allocation status
> Internally, we want to always store the canonical form of a decl, not the
> source-level form -- the current g++ AST isn't prepared for that (I wish
> it was, but it isn't.) This allows for simple comparison and other
> semantics processing.
Agreed. But without some source-level annotations in
On Sat, Jun 22, 2013 at 12:11 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | I the long term, I think we'll end up having constraints attached to
> | declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
> | Although now that I'm looking, it seems that lang_decl_parm does
Andrew Sutton writes:
| I the long term, I think we'll end up having constraints attached to
| declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
| Although now that I'm looking, it seems that lang_decl_parm does not
| inherit lang_min. Hmm...
|
| Mostly, though, I'm not sure wh
I the long term, I think we'll end up having constraints attached to
declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
Although now that I'm looking, it seems that lang_decl_parm does not
inherit lang_min. Hmm...
Mostly, though, I'm not sure where I could put it where both
TEMPLA
On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton
wrote:
> I changed the implementation to associate constraints with template
> decls (actually lang_decl_min) rather than template_info.
Hmm, why move it to lang_decl_min? Now, every C++ declaration will
have a constraint, instead of just temploids
Andi Kleen writes:
> ...
> /* Free lock with lock elision */
> -__atomic_clear(&lockvar, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
> +__atomic_store(&lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
Sorry I realized it should be actually __atomic_store_n, not __atomic_store.
I will fix that as
Hmm, seems like I should have sent this yesterday even though I hadn't
made it through the whole patch. But I suppose it doesn't hurt to fix
it after checkin.
On 06/20/2013 07:39 PM, Iyer, Balaji V wrote:
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
old mode 100644
new mode 10
Andrew Sutton writes:
| Like this?
|
| // Parse a requires clause.
| //
| //requires-clause:
| // 'requires' logical-or-expression
| //
| // The required logical-or-expression must be a constant expression.
| static tree
| cp_parser_requires_clause (cp_parser *parser)
| {
| // Parse t
I changed the implementation to associate constraints with template
decls (actually lang_decl_min) rather than template_info.
The handling of constrained non-template member functions changes a
little. When a class template is instantiated the instantiated
requirements are associated directly with
Like this?
// Parse a requires clause.
//
//requires-clause:
// 'requires' logical-or-expression
//
// The required logical-or-expression must be a constant expression.
static tree
cp_parser_requires_clause (cp_parser *parser)
{
// Parse the constant expression.
tree expr =
cp_par
Andrew Sutton writes:
| > | + // Concept extensions
| > | + case RID_REQUIRES:
| > | +return cp_parser_requires_expression (parser);
| > | +
| >
| > I think you meant here "nested requirements", not "extensions" as in
| > "GNU extensions" or "vendor lock-ins". We should continue with "nest
> | + // Concept extensions
> | + case RID_REQUIRES:
> | +return cp_parser_requires_expression (parser);
> | +
>
> I think you meant here "nested requirements", not "extensions" as in
> "GNU extensions" or "vendor lock-ins". We should continue with "nested
> requirements" then.
This denotes
On Wed, 2013-06-19 at 22:42 +0800, Bin.Cheng wrote:
> On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo wrote:
> >
> > No, I haven't disabled ivopt.
> >
>
> But -fno-ivopts is specified in PR50749.
> With current implementation, auto-inc-dec iterates instructions
> backward, tries to find memory access
On Thu, 2013-06-20 at 15:21 -0400, Jason Merrill wrote:
> Since we poison "malloc" and friends in system.h, any C++ code that
> includes a standard library header such as , which in turn
> includes , will get poisoning errors due to lines like
>
> > #undef malloc
> > using ::malloc;
>
> The s
Hi,
the attached patch fixes volatile mem loads on SH so that they won't
result in redundant sign extensions and also utilize the available
addressing modes.
Tested on rev 200116 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
34 matches
Mail list logo
