On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
>
> Jason Merrill writes:
>> If PA malloc doesn't actually provide 16-byte alignment, this change
>> seems problematic; it will mean any type that wants 16-byte alignment
>> will silently get 8-byte alignment instead.
>
> Should such cases be cal
On 10/11/16 16:07, David Malcolm wrote:
This logic is running when the next diagnostic is about to be emitted.
But what if the user has selected -Wfatal-errors and there's a single
error and no further diagnostics? Could this change the observable
behavior? (I'm trying to think of a case here,
On 10/11/2016 04:23 PM, Denys Vlasenko wrote:
This is better than current behavior, but this is not what I want.
15-byte function does not need to be aligned to 16 bytes on a machine
with 128-byte L1I cachelines. It needs to be aligned to 128 bytes
if there are less than 15 bytes remaining; if
On Tue, 11 Oct 2016, Richard Biener wrote:
An example that regressed at -O (looking at the .optimized dump)
int f(int a, unsigned b){
a &= 1;
b &= 1;
return a&b;
}
Yeah, but it usually also shows a badly written pattern:
/* (X & Y) & (X & Z) -> (X & Y) & Z
(X | Y) | (X | Z) -> (X | Y
On 2016-10-11 4:11 PM, Jason Merrill wrote:
On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
Jason Merrill writes:
If PA malloc doesn't actually provide 16-byte alignment, this change
seems problematic; it will mean any type that wants 16-byte alignment
will silently get 8-byte alignment in
On Tue, Oct 11, 2016 at 04:54:56PM -0400, John David Anglin wrote:
> But the check isn't directly about malloc. It's between the alignment for
> max_align_t
> and the alignment that the type wants. Joseph indicated that max_align_t
> should have an
> alignment as large as the POSIX types (e.g., p
> Revised patch attached, tested on x86-64/Linux, OK for the mainline?
Also tested on Aarch64/Linux, where it cleans up the ACATS testsuite:
--- mail-report.log.0 2016-10-11 04:01:06.020972999 -0700
+++ mail-report.log 2016-10-11 14:27:42.110972999 -0700
@@ -2,12 +2,10 @@
LAST_UPDATED: Obt
On Tue, Oct 11, 2016 at 4:54 PM, John David Anglin wrote:
> On 2016-10-11 4:11 PM, Jason Merrill wrote:
>>
>> On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
>>>
>>> Jason Merrill writes:
If PA malloc doesn't actually provide 16-byte alignment, this change
seems problematic; it
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 239612)
+++ gcc/doc/extend.texi (working copy)
@@ -15019,6 +15019,139 @@ The @code{__builtin_dfp_dtstsfi_ov_dd} and
require that the type of the @code{value} argument b
On 10/03/2016 07:48 AM, Segher Boessenkool wrote:
I updated according to Jeff's latest comments (importantly, we cannot
move a *logue in front of a move in general), and added some testcases.
Bootstrapping is in progress on today's trunk, powerpc64-linux and
powerpc64le-linux.
Is this okay to c
On Tue, 11 Oct 2016, Bin Cheng wrote:
We missed folding (convert)(X op const) -> (convert)X op (convert)const for
unsigned narrowing because of reason reported at
https://gcc.gnu.org/ml/gcc/2016-07/msg00126.html
This patch fixes the issue by adding new match&simplify pattern, it also adds a
t
As Jon pointed out in the BZ, there's an if-else in
tree-ssa-threadupdate.c where the if and else blocks are equivalent.
Clearly that's all that useful.
The code in question used to be an if-elseif-else construct where the
elseif block did something different. The elseif block was removed w
Committed to 6-branch and trunk.
2016-10-11 Steven G. Kargl
PR fortran/77942
* simplify.c (gfc_simplify_cshift): Check for zero.
2016-10-11 Steven G. Kargl
PR fortran/77942
* gfortran.dg/pr77942.f90
Index: gcc/fortran/simplify.c
==
Hi,
A few days ago I sent a patch to libstdc++-v3[1], but the patch is still
not applied. Why?
Moreover, when I try to ping this thread my messages are returned to
sender. Why?
[1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00567.html
--
Regards, niXman
__
Hi!
The following patch introduces difference warning levels for
-Wimplicit-fallthrough warning, so projects can choose if they want to
honor only attributes (-Wimplicit-fallthrough=5), or what kind of comments.
=4 is very picky and accepts only very small amount of comments, =3 is what
we had bef
Hi!
The following testcase ICEs, because ranges[i].exp is x < y
with boolean type, but (*ops)[ranges[i].idx] is that result cast
to int and the code didn't take into account possible casts that
init_range_entry looks through.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
> Note that the ADDXC, ADDXCCC, SUBXC and SUBXCCC instructions do not
> support immediate operands. Hence the patch breaks vis3-enabling arches
> and niagara-7.
Egad. I totally overlooked this (yet the -mcpu=niagara7 -m64 testsuite is
rather explicit) and this is a bit of a shame, especially fo
On 10/11/2016 11:52 PM, Jakub Jelinek wrote:
The following patch introduces difference warning levels for
-Wimplicit-fallthrough warning, so projects can choose if they want to
honor only attributes (-Wimplicit-fallthrough=5), or what kind of comments.
=4 is very picky and accepts only very small
On 10/12/2016 12:34 AM, Bernd Schmidt wrote:
* c.opt (Wextra): Add as C/C++/ObjC/ObjC++ option.
(Wimplicit-fallthrough=): Enable for these languages by -Wextra.
This bit looks like it does a bit more magic than is immediately
obvious. Could you elaborate how this works?
Ok, so it loo
On Wed, Oct 12, 2016 at 12:34:45AM +0200, Bernd Schmidt wrote:
> On 10/11/2016 11:52 PM, Jakub Jelinek wrote:
> >The following patch introduces difference warning levels for
> >-Wimplicit-fallthrough warning, so projects can choose if they want to
> >honor only attributes (-Wimplicit-fallthrough=5)
On Wed, Oct 12, 2016 at 12:52:49AM +0200, Bernd Schmidt wrote:
> On 10/12/2016 12:34 AM, Bernd Schmidt wrote:
>
> >>* c.opt (Wextra): Add as C/C++/ObjC/ObjC++ option.
> >>(Wimplicit-fallthrough=): Enable for these languages by -Wextra.
> >
> >This bit looks like it does a bit more magic th
On 10/12/2016 01:12 AM, Jakub Jelinek wrote:
What I perhaps should try is removing the Common keyword from the
Wimplicit-fallthrough and Wimplicit-fallthrough= entries, e.g. similarly
to how Wnonnull-compare is defined just as Var(...) Warning in common.opt
(so that it can be used in the middle-e
Jason,
Are there any other changes you want me to make to the patch?
I leave this weekend for the WG14 meeting and would like to
get this change finalized and hopefully committed before then.
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html
Thanks
Martin
On 10/06/2016 02:29 PM, Marti
On October 11, 2016 11:59:23 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The following testcase ICEs, because ranges[i].exp is x < y
>with boolean type, but (*ops)[ranges[i].idx] is that result cast
>to int and the code didn't take into account possible casts that
>init_range_entry looks through.
Hi Richard,
On 12/10/16 00:14, Richard Biener wrote:
On Tue, Oct 11, 2016 at 2:57 AM, kugan
wrote:
Hi Richard,
Hi Richard,
On 10/10/16 20:13, Richard Biener wrote:
On Sat, Oct 8, 2016 at 9:38 PM, kugan
wrote:
Hi Richard,
Thanks for the review.
On 07/10/16 20:11, Richard Biener wrote:
Hi Richard,
On 07/10/16 21:03, Richard Biener wrote:
On Fri, Oct 7, 2016 at 2:53 AM, kugan wrote:
Hi Richard,
Thanks for the review.
On 09/08/16 18:58, Richard Biener wrote:
On Tue, Aug 9, 2016 at 12:58 AM, kugan
wrote:
Hi Jakub,
Thanks for the review.
On 08/08/16 16:40, Jakub Jelin
Hi,
This patch uses the get/set_ptr_nonnull so that ipa-vrp also propagates
nonnull ranges for pinter.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-10-12 Kugan Vivek
Hi,
This patch uses get_ptr_nonnull in tree-vrp.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-12 Kugan Vivekanandarajah
* gcc.dg/ipa/vrp4.c: Adjust
101 - 128 of 128 matches
Mail list logo
