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}"
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
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
> | + // 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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':
> .
> 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
> | 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
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/
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
* 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
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
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
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
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
> | 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
| 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
> | 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
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
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
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,-
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
34 matches
Mail list logo
