The attached patch documents the fact that using the -finit-* options will
silence -Wuninitialized warnings. I don't think that's unreasonable (and Steve
classified it as a "it hurts when I do this" problem), so I intend to close the
PR after committing.
Tested with "make info man html pdf". OK
On Tue, Nov 08, 2011 at 09:05:16AM +0200, Ira Rosen wrote:
> > + /* Arguments are ready. Create the new vector stmt. */
> > + FOR_EACH_VEC_ELT (tree, vec_oprnds0, i, vec_oprnd0)
>
> Was this line left by mistake?
Oops, yes. It didn't make a difference at runtime, so pas
On 7 November 2011 20:35, Jakub Jelinek wrote:
> Hi!
Hi,
>
> Here is an updated patch, which handles both modifier == NONE
> and modifier == NARROW for SLP, after all it wasn't that hard.
> Additionally it checks that the fndecls and various call flags
> match, and adds some testcases.
>
> Boots
Hi!
Working virtually out of Pago Pago.
Is there a reason why we don't prefer 32-byte integer vector modes
even for AVX? If a vectorized loop needs some operation that is only
supported by AVX2 we would retry whenever seeing such stmt, so
what I think this costs us mainly some small amount of ti
On 2/11/2011, at 10:18 AM, Richard Guenther wrote:
>
Thus, I don't think we want to
merge this in its current form or in this stage1.
>>>
>>> What is the benefit of pushing this to a later release? If anything,
>>> merging the support for iterative optimizations now will allow us to
>
On Tue, Nov 08, 2011 at 12:30:36AM +, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Alan Modra wrote:
>
> > OK, so you made the stack ties conflict with all memory. I wondered
> > about that too, but didn't find a testcase where it mattered. It
>
> The test I had was one of those from the va
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 19:08:26 +0100
> So, what DO we do if there is no basic level of atomic
> support...
I just realized I may be feeding you an inconsistent
configuration, see the atomicity stuff in
libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
now o
On 11/07/2011 10:42 PM, Torvald Riegel wrote:
+ noex = tsubst_copy_and_build (noex, args, complain, in_decl,
+ /*function_p=*/false,
+ /*integral_const_expr_p=*/true);
+ noex = buil
OK.
Jason
OK.
Jason
The patch seems to work fine, except that MUST_NOT_THROW_EXPR isn't
working as expected. When used inside an expression, it isn't correctly
transformed to Gimple. Second, we loose terminate calls for some reason
(see noexcept-5.C). Those two things cause the failures with those test
cases.
The noe
On 11/07/11 19:36, Torvald Riegel wrote:
patch2 fixes parsing of transaction expressions, so that two txn
expressions that are part of a single expression do not get treated as
nested txns anymore, but become two separate ones (see test case).
Approved off-line by Richard Henderson, but I'll run
patch2 fixes parsing of transaction expressions, so that two txn
expressions that are part of a single expression do not get treated as
nested txns anymore, but become two separate ones (see test case).
Approved off-line by Richard Henderson, but I'll run tests again
tomorrow just to be sure.
patc
Hi,
This patch turns on FMA4 for the AMD BDVER2 processor.
Okay for trunk if no regressions?
--
Quentin
Index: ChangeLog
===
--- ChangeLog (revision 181147)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-11-07 Quentin Nei
> There still seem to be problems printing the scope:
>
> namespace N
> {
> template using U = T*;
> };
>
> void f(N::U) { blah; }
>
>
> wa.C: In function ‘void N::f(U)’:
> wa.C:6:21: error: ‘blah’ was not declared in this scope
>
> Note how the N:: is attached to the function r
On 11/08/2011 02:43 AM, Gabriel Dos Reis wrote:
On Mon, Nov 7, 2011 at 6:52 PM, Paolo Carlini wrote:
Hi,
Marc noticed we had a few redundant const qualifiers.
Yes and no. They were left redundant NOT out of careless
or lazyness.
At the time, it was lobbied hard that for transitional purposes
On Mon, Nov 7, 2011 at 6:52 PM, Paolo Carlini wrote:
> Hi,
>
> Marc noticed we had a few redundant const qualifiers.
Yes and no. They were left redundant NOT out of careless
or lazyness.
At the time, it was lobbied hard that for transitional purposes,
#defning constexpr to nothing should still l
Hi,
committed to mainline.
Paolo.
///
2011-11-07 Paolo Carlini
PR libstdc++/51018
* include/profile/impl/profiler_node.h (__stack_hash::
operator()(__stack_t)): Just use std::size_t everywhere.
Index: include/profile/impl/profiler_node.h
=
The std::pointer_traits and std::allocator_traits implementations are
complete now, update the release notes.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.46
diff -u -r1.46 chan
This removes a TODO where I'd been waiting to use an alias-declaration
to make the code a bit simpler.
Also uses std::decay in the packaged_task constraint I added recently.
* include/std/future (__future_base::_Ptr): Use alias-declaration.
(__is_same_pkgdtask): Rename to __constr
On 11/08/2011 01:51 AM, Paolo Carlini wrote:
Do we need to check the code of postfix_expression at all?
Ah! You implied that, in your previous message, but seemed too nice to
me ;) Let me regtest without...
And this indeed passes testing. A rather old testcase got a slightly
more accurate error
Here our code trying to give a helpful diagnostic for a call to an
undeclared name in a template assumed that doing the lookup in
instantiated context would find a function; in this testcase it finds an
int&, and gets all confused.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2bf99c2e
Hi,
Marc noticed we had a few redundant const qualifiers.
Tested x86_64-linux, committed.
Paolo.
//
2011-11-07 Paolo Carlini
* include/std/complex (complex<>::real(), complex<>::imag()):
Remove redundant const qualifiers.
Index: include/std/complex
=
On 11/08/2011 01:49 AM, Jason Merrill wrote:
On 11/07/2011 07:31 PM, Paolo Carlini wrote:
+ if (TREE_CODE (parser->scope) == NAMESPACE_DECL
+ && (TREE_CODE (postfix_expression) == ARROW_EXPR
+ || TREE_CODE (postfix_expression) == CALL_EXPR))
Do we need to check the code
On 11/07/2011 07:31 PM, Paolo Carlini wrote:
+ if (TREE_CODE (parser->scope) == NAMESPACE_DECL
+ && (TREE_CODE (postfix_expression) == ARROW_EXPR
+ || TREE_CODE (postfix_expression) == CALL_EXPR))
Do we need to check the code of postfix_expression
On 11/07/2011 06:15 PM, Paolo Carlini wrote:
Thanks. This also implies that we don't ICE anymore on c++/50864, we
just accept it, as uninstiantiated template. I guess being able to
reject it early at parsing time would still be a good idea, in general.
Agreed.
Jason
The new alias-declaration support in trunk allows the
std::pointer_traits and std::allocator_traits implementations to be
finished, by replacing the __rebind::__type workarounds with the
required alias-declarations.
* include/bits/ptr_traits.h (__rebind): Replace with...
(rebind):
Hi,
this is what I figured out for the parser: I'm dealing also with '.', as
you recommended, and I tidied a bit the code wrt my first draft try,
consistently with the way we are handling another error condition a few
lines earlier.
Re-tested x86_64-linux.
Thanks,
Paolo.
//
On Tue, 8 Nov 2011, Alan Modra wrote:
> OK, so you made the stack ties conflict with all memory. I wondered
> about that too, but didn't find a testcase where it mattered. It
The test I had was one of those from the various PRs for this issue.
int find_num(int i)
{
const int arr[5] = {0, 1,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 15:53, Richard Guenther wrote:
> On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek
> wrote:
>> Hi!
>>
>> This patch attempts to optimize VEC_BASE if we know that offsetof
>> of base is 0 (unless the compiler is doing something strange, it
>>
This fixes the problem on the Epiphany, but I haven't tested if it also fixes
it on
the SH - AAUI you'd have to back out a workaround first to properly test it.
Bootstrapped powerpc64-unknown-linux-gnu.
pr40154-fix
Description: Binary data
On Mon, 7 Nov 2011, Richard Guenther wrote:
> Just looking for a more general solution (but I note that Ada lacks
> some conversion to the new cl_decoded_options facility anyways ...)
Full conversion may be hard because of things done in Ada code not C/C++,
but it is indeed the case that it woul
On Mon, 7 Nov 2011, Iain Sandoe wrote:
> > How is the default selected (that's not obvious to me). flag_next_runtime
> > doesn't use options mechanisms it seems, that's bad. Both
> > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> > be at least also enabled for LTO, other
On Mon, 7 Nov 2011, Richard Guenther wrote:
> Joseph, do you have any advise on how to address frontend specific
> options in a more general way? I'm trying to re-construct a
> command-line that when processed frontend agnostic would produce
> the same end-result in global_options as if going thr
On Mon, Nov 07, 2011 at 04:10:38PM +, Joseph S. Myers wrote:
> FWIW, when I encountered such a problem in 4.4-based tools I found I
> needed the following change to stack_tie patterns to fix it (applied to
> and rediffed against trunk, but not tested there), in addition to a
> DEFAULT_ABI ==
> Fixed like so ...
>
> * include/std/mutex (call_once): Store closure in __once_functor
> as bound function wrapper might not be copyable.
>
> The fix would be simpler but the lambda can't capture the parameter
> pack directly because of PR c++/41933. Unfortunately the non-TLS
> st
On Mon, Nov 7, 2011 at 4:39 PM, Jason Merrill wrote:
> On 11/07/2011 05:38 PM, Gabriel Dos Reis wrote:
>>>
>>> struct C
>>> {
>>> int i;
>>> C() = default;
>>> };
>>
>> so the defaulted constructor does not initialize C::i?
>
> No, it doesn't. value-initialization of a C will initialize it, but
On Mon, 7 Nov 2011, Richard Henderson wrote:
> We should make sure that the bootstrap succeeds though,
> disabling the library when porting work hasn't been done.
For disabling libraries, I've suggested that toplevel configure should
source a file from the subdirectory that says whether a target
On 11/7/2011 5:17 PM, Richard Henderson wrote:
> I haven't seen a re-post since Joseph's review?
> If I've missed it, please give me urls into the gcc-patches archive.
contrib:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01881.html
gcc:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01880.html
htt
A slight revision of the previous version. Updated for mainline,
and tested on x86_64 and arm.
This time I also saw some more references to the sync_c_a_s optab
in the java front end. Now updated to use can_compare_and_swap_p.
Follow-on patches will invoke init_sync_libfuncs for arm, pa, mips,
On 11/07/2011 11:49 PM, Jason Merrill wrote:
Dodji's work on template parameter lists of different lengths exposed
a problem whereby we weren't handling partial instantiation of a
COMPONENT_REF where the member is a SCOPE_REF. Fixed by not messing
with it when the object is still dependent.
On 7 November 2011 22:38, Gabriel Dos Reis wrote:
>> Unfortunately this doesn't work very well in C++11 mode, as defaulted
>> constructors don't cause warnings when they should do e.g.
>>
>> struct C
>> {
>> int i;
>> C() = default;
>> };
>>
>> This doesn't produce the same warning as C() {} even
On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to optimize VEC_BASE if we know
> that offsetof of base is 0 (unless the compiler is doing something
> strange, it is true).
> It doesn't have a clear code size effect, some .text sections
> grew, supposedly becaus
Dodji's work on template parameter lists of different lengths exposed a
problem whereby we weren't handling partial instantiation of a
COMPONENT_REF where the member is a SCOPE_REF. Fixed by not messing
with it when the object is still dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
Tested on x86_64-linux.
r
gcc/Changelog:
2011-11-07 Roberto Agostino Vitillo
PR debug/50983
* dwarf2out.c (set_cur_line_info_table): Restore the last is_stmt value
in the current line table.
Index: gcc/gcc/dwarf2out.c
===
My change to accept C99 array-designators in C++ broke use of lambdas in
an initializer-list, since both start with [. Fixed by parsing the
array-designator tentatively.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fc9080728a450c22b6f70c133e9d12835733195f
Author: Jason Merrill
Date:
On Mon, Nov 7, 2011 at 8:36 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 09:14, Richard Guenther wrote:
>
>>>
>>> Well, not that I noticed that I missed here any freedom. In
>>> what cases you mean I would need here freedom to create new
>>> ssa-statements
ok for google/main.
David
On Mon, Nov 7, 2011 at 2:40 PM, Rong Xu wrote:
> Fix the build warning introduced in r180971.
>
> This is for google branch only.
>
> Tested with build.
>
> 2011-11-07 Rong Xu
>
> * gcc/dwarf2out.c (dwarf2out_decl): fix mixed declarations and code.
>
> Index:
Fix the build warning introduced in r180971.
This is for google branch only.
Tested with build.
2011-11-07 Rong Xu
* gcc/dwarf2out.c (dwarf2out_decl): fix mixed declarations and code.
Index: gcc/dwarf2out.c
===
--- gcc
On 11/07/2011 05:38 PM, Gabriel Dos Reis wrote:
struct C
{
int i;
C() = default;
};
so the defaulted constructor does not initialize C::i?
No, it doesn't. value-initialization of a C will initialize it, but not
default-initialization.
Jason
On Mon, Nov 7, 2011 at 3:43 PM, Jonathan Wakely wrote:
> This is a new version of my -Wmeminit patch, first posted to PR c++/2972.
>
> Jason suggested combining the Wmeminit warning with the adjacent
> Weffc++ one which I agree with. The advice in the Effective C++ book
> actually says not to lea
On Mon, Nov 7, 2011 at 8:47 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 07:38, Richard Guenther wrote:
>>
>>
>> The cond_chain stuff should be as we have discussed quite some
>> time ago on IRC - modeled after tree-affine.c - a "vector" of
>> predicates of
On Mon, Nov 7, 2011 at 8:01 PM, Richard Henderson wrote:
> On 11/05/2011 03:09 PM, Richard Guenther wrote:
>> On Sat, Nov 5, 2011 at 10:05 PM, Aldy Hernandez wrote:
>>> [rth, see below]
>>>
> local_define_builtin ("__builtin_eh_pointer", ftype,
> BUILT_IN_EH_POINTER,
>
On 7 November 2011 21:51, Jonathan Wakely wrote:
>
> Aha, this is a problem with all platforms where _GLIBCXX_HAVE_TLS is
> not defined, std::call_once uses std:function which assumes a copyable
> target object.
>
> I'm working on it ..
>
Fixed like so ...
* include/std/mutex (call_once):
On Mon, Nov 7, 2011 at 8:03 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 08:49, Richard Guenther wrote:
>
>>
>> OTOH I'm not sure we want to change a possible trap (And thus
>> program abort) to a fallthru ...
> I think this is the big question we need to a
On 11/07/2011 08:59 AM, Walter Lee wrote:
> Seeking more feedback or status update.
>
> Thanks,
>
> Walter Lee
>
> On 10/30/2011 12:07 PM, Walter Lee wrote:
>> Ping? I believe I have addressed all the reviewer's (namely Joseph Myers')
>> comments to date.
I haven't seen a re-post since Joseph'
On Mon, Nov 07, 2011 at 11:09:52PM +0100, FX wrote:
> Hi all,
>
> Attached patch fixes the documentation of ATAN2 regarding signed zeros (aka
> PR49336) and the documentation of option -fsign-zero regarding I/O behaviour
> (aka PR49188). While I was at it, I also removed some lonely contractions
Hi all,
Attached patch fixes the documentation of ATAN2 regarding signed zeros (aka
PR49336) and the documentation of option -fsign-zero regarding I/O behaviour
(aka PR49188). While I was at it, I also removed some lonely contractions
(it's, 'll, can't, don't, etc.)
Tested with "make man info
On Mon, Nov 7, 2011 at 5:41 PM, Xinliang David Li wrote:
> Here is the stack trace when the watch point is hit (the watch point
> is on address &cleanups->base.prefix.num
>
> David
>
> #0 memset () at ../sysdeps/x86_64/memset.S:336
> #1 0x00d1528d in poison_pages () at
> /usr/local/googl
On Mon, Nov 7, 2011 at 1:30 PM, Sharad Singhai wrote:
> Honza,
> Sorry, I forgot about this. Could you please put this on your TODO list?
>
> David,
> While a proper fix is pending for the trunk, we need this interim fix
> internally. Okay for google/main?
ok.
thanks,
David
>
> Thanks,
> Sharad
On Mon, Nov 7, 2011 at 4:57 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 3 Nov 2011, Richard Guenther wrote:
>
>> Otherwise the patch looks ok, but given the Ada issue let's wait until
>> that is sorted out in some way. That also gives others the chance to
>> comment on the patch.
>
> So, this is wh
Add merging of namespaces.
Add testcase for namespace merging. test fails because lookup fails
for reasons apparently associated with identifiers.
Add tracing of both front and back of trees so as to better identify
the tree structure.
Add tracing of record markers.
Various formatting fixes.
T
On 11/07/2011 10:45 PM, Jason Merrill wrote:
On 10/26/2011 04:35 PM, Paolo Carlini wrote:
We have that parser->scope is a RECORD_TYPE and postfix_expression is an
INDIRECT_REF.
Ah, OK. I guess we swallow up the namespace while parsing the full
nested-name-specifier and it isn't a problem. So
On 7 November 2011 21:05, Jonathan Wakely wrote:
> On 7 November 2011 20:58, Eric Botcazou wrote:
>>> Tested x86_64-linux and committed to trunk.
>>>
>>> * testsuite/30_threads/async/49668.cc: Add missing dg-require.
>>> * testsuite/30_threads/packaged_task/49668.cc: Likewise.
>>
>>
On 11/07/2011 04:43 PM, Jonathan Wakely wrote:
Unfortunately this doesn't work very well in C++11 mode, as defaulted
constructors don't cause warnings when they should do e.g.
Maybe check this in defaulted_late_check?
Jason
Hi!
I'd like to ping the restrict_based_on_field attribute patch:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html
We currently don't do cast restricts and even if we do them again,
as this attribute doesn't make the type __restrict it wouldn't
affect those, it only affects parameters, if
On 10/26/2011 04:35 PM, Paolo Carlini wrote:
We have that parser->scope is a RECORD_TYPE and postfix_expression is an
INDIRECT_REF.
Ah, OK. I guess we swallow up the namespace while parsing the full
nested-name-specifier and it isn't a problem. So I think handling this
here should be OK. B
This is a new version of my -Wmeminit patch, first posted to PR c++/2972.
Jason suggested combining the Wmeminit warning with the adjacent
Weffc++ one which I agree with. The advice in the Effective C++ book
actually says not to leave members uninitialized, rather than saying
*all* members must h
I had to revert a minor change in the last patch. It didn't show any
problems in an incremental bootstrap, but once from scratch showed a
compile failure due to a duplicate definition.
I'll have to fix the lack of an atomic_thread_fence or
atomic_signal_fence a different way apparently.
Sor
Subject says it all. It's a one liner.
Bootstrapped on x86_64-redhat-linux. Testing is ongoing.
Ed
patch
Description: Binary data
CL
Description: Binary data
This patch adds some support for context switching to the -fsplit-stack
support routines in libgcc. I intend to use this in the Go library to
support multiplexing multiple goroutines onto a single pthread. They
work similarly to getcontext/setcontext/makecontext.
This patch also adds control ove
Honza,
Sorry, I forgot about this. Could you please put this on your TODO list?
David,
While a proper fix is pending for the trunk, we need this interim fix
internally. Okay for google/main?
Thanks,
Sharad
On Sun, Oct 2, 2011 at 3:08 AM, Jan Hubicka wrote:
>>
>> I believe Richi opent PR back wh
The following patch contains a major rewriting inheritance code to
permit inheritance from non-reload insns. That is important for targets
(like x86-64) permitting memory in general insns and as a result
considerably decreasing code size. Now LRA can do the following
transformations:
p
Hi!
This patch attempts to optimize VEC_BASE if we know
that offsetof of base is 0 (unless the compiler is doing something
strange, it is true).
It doesn't have a clear code size effect, some .text sections
grew, supposedly because of more inlining, some .text sections shrunk.
Bootstrapped/regtes
Hi.
> From: Hans-Peter.
> Date: 5 Nov 2011 г., 5:24:20:
>> +(define_constraint "S"
>> + "PIC-constructs for symbols."
>> + (and (match_test "flag_pic")
>> + (match_code "const")
>> + (match_test "cris_valid_pic_const (op, false)")))
> Can you really have other than two operands to
Hi!
I think it is at least more readable and perhaps for some CPUs could
be faster (for SandyBridge it is the same speed) if we emit a more
specialized insn over a more generic one.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
In the attachment is my first attempt to do t
On 11/07/2011 09:39 PM, Jason Merrill wrote:
On 10/28/2011 08:10 PM, Paolo Carlini wrote:
I reverted it. Had inadvertently tested with checking disabled, the
problem with checking enabled happens earlier than that.
Was there a problem with the patch? It still looks correct even if it
doesn't
Hi!
As I've mentioned during the weekend, currently all functions that use
32-byte vectors end up with frame pointer and stack realignment
(except when they have some 32-byte aligned argument, but that
means 9+ arguments, so quite unlikely). The stack realignment is
there just in case, if reloade
On 7 November 2011 20:58, Eric Botcazou wrote:
>> Tested x86_64-linux and committed to trunk.
>>
>> * testsuite/30_threads/async/49668.cc: Add missing dg-require.
>> * testsuite/30_threads/packaged_task/49668.cc: Likewise.
>
> We have a related failure on SPARC/Solaris for some time
> 2011-11-06 Joseph Myers
>
> * g++.dg/cpp0x/alignof3.C, gcc.dg/c1x-align-1.c,
> gcc.dg/c1x-align-2.c, gcc.dg/c1x-align-3.c, gcc.dg/c1x-align-4.c,
> gcc.dg/c90-align-1.c, gcc.dg/c99-align-1.c: New tests.
> * gcc.dg/gnu89-const-expr-1.c, gcc.dg/gnu90-const-expr-1.c,
>
Hello!
Attached patch fixes omission from "(int) rint ()" conversion to
__builtin_irint (). We can vectorize this function when out_mode is
SImode, no matter how the builtin is called. Throw in also
BUILT_IN_LLRINT, just for completion ...
2011-11-07 Uros Bizjak
* config/i386/i386.c (
On Mon, Nov 07, 2011 at 09:55:48PM +0100, Eric Botcazou wrote:
> > The test uses the largest available floating-point number - be it 8, 10
> > or 16 - and tests for that. The checks should be thus OK for any system.
>
> It fails with a link failure on SPARC Solaris 8 and 9:
>
> FAIL: gfortran.dg/
> Tested x86_64-linux and committed to trunk.
>
> * testsuite/30_threads/async/49668.cc: Add missing dg-require.
> * testsuite/30_threads/packaged_task/49668.cc: Likewise.
We have a related failure on SPARC/Solaris for some time:
FAIL: 30_threads/call_once/49668.cc (test for exces
As part of the fallout from PR 50982, this patch adds some new fixes
to GCC fixincludes that corrects a syntax error in an array
initializer for PTHREAD_ONCE_INIT. The incorrect header file still is
present in AIX 7.1; I have reported the bug to AIX as well.
* inclhack.def (aix_once_init_
> 2011-11-06 Sergey Ostanevich sergos@gmail.com
>
> PR rtl-optimization/47698
> * ifconv.c (noce_operand_ok): prevent CMOV generation
> for volatile mem
There is no such file as ifconv.c though. The first letter must be capitalized
and there must be a period at the end. A
> The test uses the largest available floating-point number - be it 8, 10
> or 16 - and tests for that. The checks should be thus OK for any system.
It fails with a link failure on SPARC Solaris 8 and 9:
FAIL: gfortran.dg/quad_2.f90 -O0 (test for excess errors)
Excess errors:
Undefined
On 10/28/2011 08:10 PM, Paolo Carlini wrote:
I reverted it. Had inadvertently tested with checking disabled, the
problem with checking enabled happens earlier than that.
Was there a problem with the patch? It still looks correct even if it
doesn't fix this testcase, so there's no need to reve
On 11/07/11 09:43, Aldy Hernandez wrote:
Do not push new_version->lowered setting into the core routine but keep
it at the callers.
Well, why didn't you say so? :). That can't be hard :).
I'm testing this.
How does it look?
rth approved this off-list. I have just committed.
Richi, if yo
2011/11/7 Jeff Law :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 09:14, Richard Guenther wrote:
>
>>>
>>> Well, not that I noticed that I missed here any freedom. In
>>> what cases you mean I would need here freedom to create new
>>> ssa-statements?
>>
>> You lookup SSA_NAME_
When I added this option I failed to add it to the options summary.
* doc/invoke.texi (C++ Language Options): Add missing
-Wdelete-non-virtual-dtor option.
OK to commit?
Index: doc/invoke.texi
===
--- doc/invoke.texi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 07:38, Richard Guenther wrote:
>
>
> The cond_chain stuff should be as we have discussed quite some
> time ago on IRC - modeled after tree-affine.c - a "vector" of
> predicates of the form [~] A op B, combined using logical AND or
> OR (t
On 11/07/2011 11:33 AM, Torvald Riegel wrote:
> Fix instantiation of transaction expressions.
>
> * cp/pt.c (tsubst_expr) [TRANSACTION_EXPR]: If body is not a
> statement, create an expression instead.
> * cp/cp-tree.h (TRANSACTION_EXPR_IS_STMT, build_transaction_expr): N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 09:14, Richard Guenther wrote:
>>
>> Well, not that I noticed that I missed here any freedom. In
>> what cases you mean I would need here freedom to create new
>> ssa-statements?
>
> You lookup SSA_NAME_DEF_STMTs of SSA names - you cann
On Mon, 2011-11-07 at 14:04 -0500, Jason Merrill wrote:
> On 11/07/2011 11:31 AM, Richard Henderson wrote:
> > On 11/07/2011 06:12 AM, Torvald Riegel wrote:
> >> stmt = begin_transaction_stmt (input_location, NULL, flags);
> >> tmp = RECUR (TRANSACTION_EXPR_BODY (t));
> >> +
I hope this cleanup both addresses the above questions and tidies things
up as indicated. Please ask if you've got more questions.
BTW, please add a merged changelog entry to ChangeLog.tm-merge. No need
for a ChangeLog.tm, unless we don't merge, in case we're back to
ChangeLog.tm for a com
On 11/07/2011 11:13 AM, Andrew MacLeod wrote:
> libstdc++-v3
> * include/bits/atomic_base.h (atomic_thread_fence): Call builtin.
> (atomic_signal_fence): Call builtin.
> (atomic_flag::test_and_set): Call __atomic_exchange when it is lockfree,
> otherwise fall back to c
Originally I had __atomic_exchange falling back to
__sync_lock_test_and_set, and __atomic_store falling back to
__sync_lock_release whenever the _atomic variation wasn't specified.
On some limited targets, functionality of these two operations can be
restrictedt. rth had already removed the s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 03:21, Richard Guenther wrote:
>
> Oh, and points-to plus DSE/DCE might confuse your pass as stores
> that points-to can prove go "nowhere" are removed.
I think this is OK in the sense that we may miss a case where we could
have detected
On Mon, Nov 7, 2011 at 7:38 PM, Jakub Jelinek wrote:
> BUILT_IN_LRINT has been vectorized just using 16-byte
> vectors, the following patch cures it (of course, for -m64
> it unfortunately can't be vectorized, as long there is DImode
> rather than SImode).
Hm...
Looking at convert.c (around lin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 03:07, Jakub Jelinek wrote:
> On Mon, Nov 07, 2011 at 02:55:02AM -0700, Jeff Law wrote:
>> [ Working virtually from Hawaii tonight... :-) ]
>
> ;)
>
>> You might legitimately wonder how often this triggers. A GCC
>> 4.6.0 checking-enab
1 - 100 of 264 matches
Mail list logo
