Hi,
this patch has been in our tree for a while and helps in Ada where you can do
block assignments to structures at will. I've attached a C testcase. The
unpatch compiler generates for it on PowerPC at -O2:
foo:
lis 10,s@ha
li 8,27
la 9,s@l(10)
stb 8,s@l(10)
Hi,
These warnings are invisible when building but they may help to detect
if an option is duplicated somewhere else with different purpose , so
it would be better to make this an error,
Only 2 options in Ada trigger this warning, and their help text has no
effect, since it gest overridden by the
Tobias Burnus wrote:
I think the ChangeLog is okay - as is the whole patch.
I wouldn't mind if someone else (Paul? Janus?) could also glance at
the patch; however, if there are no comments, I intent to commit the
patch soon.
Committed as Rev. 187436. Thanks for the patch and congratulation t
On Sun, 13 May 2012, Manuel L?pez-Ib??ez wrote:
> Hi,
>
> These warnings are invisible when building but they may help to detect
> if an option is duplicated somewhere else with different purpose , so
> it would be better to make this an error,
>
> Only 2 options in Ada trigger this warning, and
A few more straightforward uses. Bootstrapped and regression tested.
A strange thing is that -Wextra enables -Wtype-limits only in
C-family, however, it remains with value -1 in the rest of languages,
that is, enabled by default. I am surprised it does not trigger often
for Fortran and Ada.
OK?
Tobias Burnus wrote:
Note that the patch assumes that the function's result variable's
length specification expression is completely known to the caller. I
think that's always the case in gfortran - or is it not?
Thinking about it, I came to the conclusion has explicitly been designed
such th
On 05/11/2012 09:07 AM, Janne Blomqvist wrote:
PING #2!
On Wed, May 2, 2012 at 10:22 PM, Janne Blomqvist
wrote:
PING
On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist
wrote:
Hi,
currently when -frange-check is enabled, we check for overflow when
doing a formatted read of an integer value
Hello!
2012-05-13 Uros Bizjak
* config/i386/sse.md (_andnot3): Handle
TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL.
(3): Ditto.
(*andnot3): Ditto.
(*andnottf3): Ditto.
(*3): Ditto.
(tf3): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}, committed
Hi,
This patch changes the minimum number of iterations of outer loops for the
runtime check which tests whether it is worthwhile to parallelize the loop
or not.
The current minimum number of iterations for all loops is MIN_PER_THREAD *
number of threads, when MIN_PER_THREAD is arbitrarily set
Hi,
I had a look to this rather old PR, which doesn't seem particularly
high-priority, to be honest. It's about the error message we produce for
things like:
int main()
{
int* p = new foo;
}
where, besides the obvious error message about foo, we also print:
39681.C:3:16: error: expected ‘,’
On Sun, 13 May 2012, Manuel L?pez-Ib??ez wrote:
> 2012-05-13 Manuel L?pez-Ib??ez
>
> c-family/
> * c.opt (Wclobbered,Wempty-body,Wignored-qualifiers,
> Wmissing-field-initializers,Wmissing-parameter-type,
> Wold-style-declaration,Woverride-init): Use EnabledBy.
> * c-op
On Sun, May 13, 2012 at 5:16 PM, Uros Bizjak wrote:
> 2012-05-13 Uros Bizjak
>
> * config/i386/sse.md (_andnot3): Handle
> TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL.
> (3): Ditto.
> (*andnot3): Ditto.
> (*andnottf3): Ditto.
> (*3): Ditto.
> (tf3): D
> I get a bootstrap failure on x86 (verify_flow_info failed) with it.
It's actually pre-existing: it's PRE value-numbering a call that can make an
abnormal goto, hence the CFG mess in the end. The call is ECF_PURE but also
ECF_LOOPING_CONST_OR_PURE, so gimple_has_side_effects returns true and,
Hello!
With all recent mode handling cleanups to move patterns and SSE
bitops, it is now possible to enable TFmode moves via XMM registers
for 32bit SSE targets. The compiler emits packed single operations in
this case, so following testcase:
--cut here--
__float128 test_abs (__float128 a)
{
re
On Sun, May 13, 2012 at 7:50 PM, Eric Botcazou wrote:
>> I get a bootstrap failure on x86 (verify_flow_info failed) with it.
>
> It's actually pre-existing: it's PRE value-numbering a call that can make an
> abnormal goto, hence the CFG mess in the end. The call is ECF_PURE but also
> ECF_LOOPING
> I'd say simply test gimple_has_side_effects instead.
We could go one step farther then and do the replacement in
if (gimple_has_volatile_ops (stmt)
|| stmt_could_throw_p (stmt))
continue;
I think that's equivalent. Revised patch attached.
* stor-l
Hi Joseph, I think this implementation matches what we were
discussing. Bootstrapped and regression tested.
OK?
2012-05-13 Manuel López-Ibáñez
c-family/
* c.opt (Wc++0X-compat,Wdelete-non-virtual-dtor,Wjump-misses-init,
Wreorder): Use LangEnabledBy.
* c-opts.c (c_commo
Hi,
this fixes the remaining bit of 44516 - the wrong location, thus caret
position - in the obvious way, that is by passing from
cp_parser_assignment_expression the right one to build_x_modify_expr via
an additional location_t parameter. The latter can simply forward it to
build_new_op.
Te
On 05/13/2012 07:25 PM, Paolo Carlini wrote:
You're adding a lot of uses of input_location; I think we can do better.
if (TREE_CODE (incr) == MODIFY_EXPR)
- incr = build_x_modify_expr (RECUR (TREE_OPERAND (incr, 0)), NOP_EXPR,
+ incr = build_x_modify_expr (input_location,
Hi,
On 05/14/2012 03:50 AM, Jason Merrill wrote:
On 05/13/2012 07:25 PM, Paolo Carlini wrote:
You're adding a lot of uses of input_location; I think we can do better.
if (TREE_CODE (incr) == MODIFY_EXPR)
-incr = build_x_modify_expr (RECUR (TREE_OPERAND (incr, 0)),
NOP_EXPR,
+
On Fri, Apr 27, 2012 at 5:02 AM, Martin Jambor wrote:
> Hi,
>
> On Tue, Apr 24, 2012 at 12:31:38PM +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Mon, Apr 23, 2012 at 03:30:19PM +0200, Richard Guenther wrote:
>> > On Mon, 23 Apr 2012, Martin Jambor wrote:
>> >
>> > > Hi,
>> > >
>> > > On Mon, Apr 23,
On 05/13/2012 11:24 PM, Paolo Carlini wrote:
tree r = build_x_modify_expr
- (RECUR (TREE_OPERAND (t, 0)),
+ (input_location,
And EXPR_LOC_OR_HERE (t).
Here I think EXPR_LOC_OR_HERE (TREE_OPERAND (t, 1)) is better.
Why? TREE_OPERAND (t,1) is a dummy tree that we only use for i
On May 10, 2012, Jason Merrill wrote:
> OK.
Thanks, installed a few days ago.
Is it ok for the 4.7 branch too? I didn't realize the bug could occur
there as well, but PR c++/53209 suggests it does. Regstrapping now.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must
23 matches
Mail list logo
