On Sat, Mar 15, 2014 at 7:05 PM, Mikael Pettersson wrote:
> This backports the fixes for wrong-code bugs PR57425 and PR57569,
> both marked as 4.8 regressions, from mainline to 4.8 branch.
>
> Tested since June last year on x86_64, powerpc64, sparc64, armv5tel,
> and m68k without regressions. Acc
> Honza suggested that if the destructor for an abstract class can't
> ever be called through the vtable, the front end could avoid
> referring to it from the vtable. This patch replaces such a
> destructor with __cxa_pure_virtual in the vtable.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
This temporarily adds -fpermissive to the gimple-match.c compile
to allow bootstrapping.
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
Richard.
2014-03-17 Richard Biener
* Makefile.in (gimple-match.o-warn): Temporarily add -fpermissive
to allow boots
Hi,
this patch corrects a regression seen in
gcc.c-torture/compile/20010327-1.c for LLP64 targets.
ChangeLog
2013-03-17 Kai Tietz
* gcc.c-torture/compile/20010327-1.c: Adjust testcase for LLP64 targets.
Ok for apply?
Regards,
Kai
Index: gcc.c-torture/compile/20010327-1.c
=
Tested on {x86_64,m68k}-suse-linux and installed as obvious.
Andreas.
PR testsuite/58851
* gfortran.dg/unlimited_polymorphic_13.f90: Properly compute
storage size.
---
gcc/testsuite/gfortran.dg/unlimited_polymorphic_13.f90 | 14 ++
1 file changed, 10 insertion
Hi,
noticed this issue, which looks simple to fix. The ICE happens in
cxx_eval_constant_expression, because it cannot handle a CAST_EXPR (or
any othe *_CAST, for that matter). In fact check_narrowing calls
maybe_constant_value, and, because we are in a template, the latter
faces the unfolded
Hi,
The patch enhances ifcvt to handle conditional compare instruction
(ccmp) to make it work with cmov. For ccmp, ALLOW_CC_MODE is set to
TRUE when calling canonicalize_condition. And the backend does not
need to generate additional "compare (CC, 0)" for it.
Bootstrap and no check regression on
Hi Kai,
> Index: gcc.c-torture/compile/20010327-1.c
> ===
> --- gcc.c-torture/compile/20010327-1.c(Revision 208594)
> +++ gcc.c-torture/compile/20010327-1.c(Arbeitskopie)
> @@ -1,4 +1,5 @@
> /* { dg-require-effective-target p
On Mon, Mar 17, 2014 at 10:50:35AM +0100, Rainer Orth wrote:
> Hi Kai,
>
> > Index: gcc.c-torture/compile/20010327-1.c
> > ===
> > --- gcc.c-torture/compile/20010327-1.c(Revision 208594)
> > +++ gcc.c-torture/compile/20010327-1.c
2014-03-17 10:53 GMT+01:00 Jakub Jelinek :
> On Mon, Mar 17, 2014 at 10:50:35AM +0100, Rainer Orth wrote:
>> Hi Kai,
>>
>> > Index: gcc.c-torture/compile/20010327-1.c
>> > ===
>> > --- gcc.c-torture/compile/20010327-1.c(Revision 20
On 16/03/14 12:30, Renlin Li wrote:
> Hi all,
>
> Thank you for your suggestions, Richard. I have updated the patch
> accordingly.
>
> This is an optimization patch which will combine "ubfiz" and "orr"
> insns with a single "bfi" when certain conditions meet.
>
> tmp = (x & m) | ( (y & n) <<
On 16 March 2014 16:09, Ed Smith-Rowland wrote:
> OK, thinking further on it I actually agree with not mentioning DRs on a
> partially baked standard. We advertise that support for new standards is
> experimental.
I don't think it does any harm to add comments during the C++1y/C++1z
process to no
Sorry, I repost last patch with small correction in dg-do directive.
The ! in there needs additional framing, and I missed the target
keyword.
Regards,
Kai
Index: 20010327-1.c
===
--- 20010327-1.c(Revision 208594)
+++ 20010327-1
This patch ensures that we properly expand gomp SIMD builtins even with
-fno-tree-loop-optimize. The problem was that we didn't run the
loop vectorization at all. -fno-tree-loop-vectorize already contains
similar hack.
Regtested/bootstrapped on x86_64-linux, ok for trunk (or for 5.0?)?
2014-03
On Mon, Mar 17, 2014 at 12:01:41PM +0100, Kai Tietz wrote:
> Sorry, I repost last patch with small correction in dg-do directive.
> The ! in there needs additional framing, and I missed the target
> keyword.
>
> Regards,
> Kai
>
> Index: 20010327-1.c
> ===
On Mon, Mar 17, 2014 at 12:01:54PM +0100, Marek Polacek wrote:
> This patch ensures that we properly expand gomp SIMD builtins even with
> -fno-tree-loop-optimize. The problem was that we didn't run the
> loop vectorization at all. -fno-tree-loop-vectorize already contains
> similar hack.
>
> R
On 16 Mar 07:12, Ulrich Drepper wrote:
> [This patch is so far really meant for commenting. I haven't tested it
> at all yet.]
>
> Intel's intrinsic specification includes one set which currently is not
> defined in gcc's headers: the _mm*_undefined_* intrinsics.
What specification are talking ab
On 17/03/14 02:51, Terry Guo wrote:
> Hi,
>
> I am working on another patch and found this per-function variable isn't
> correctly reset for Thumb1 target. Currently no ICE will be triggered
> because we don't call function arm_split_constants for Thumb1 target. This
> patch intends to define this
Hello,
Patch in the bottom allows to use ymmXX and zmmXX
register names in inline asm statements as well as
in `register` variables definitions.
New tests pass.
Bootstrap pass.
Is it ok for trunk?
Do we need to backport it to 4.8?
gcc/
* config/i386/i386.h (ADDITIONAL_REGISTER_NAMES): Ad
Ping.
2014-03-12 21:56 GMT+04:00 Ilya Verbin :
> Hi Thomas,
>
> Here is a new version of this patch (it was discussed in other thread:
> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00573.html ) with ChangeLog.
> Bootstrap and make check passed.
> Ok to commit?
-- Ilya
This nearly brings us to the goal of having just one page covering
this and simplifies language in about.html a bit on the way.
Applied.
Gerald
Index: about.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/about.html,v
retrieving revision
On Mon, Mar 17, 2014 at 12:50 AM, Jerry DeLisle wrote:
> Hi all.
>
> The problem here was that when reading a value from STDIN and the user just
> entered an empty entry (LF),
> we would end up getting nested into a second read (via next_char) and the user
> would have to press CTRL-D twice to get
On 03/17/2014 05:38 AM, Paolo Carlini wrote:
noticed this issue, which looks simple to fix. The ICE happens in
cxx_eval_constant_expression, because it cannot handle a CAST_EXPR (or
any othe *_CAST, for that matter). In fact check_narrowing calls
maybe_constant_value, and, because we are in a tem
On Fri, 14 Mar 2014, Cong Hou wrote:
> On Fri, Mar 14, 2014 at 12:58 AM, Richard Biener wrote:
> > On Fri, 14 Mar 2014, Jakub Jelinek wrote:
> >
> >> On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
> >> > > Consider this fact and if there are alias checks, we can safely remove
> >
On Mon, Mar 17, 2014 at 02:44:29PM +0100, Richard Biener wrote:
> You mean exactly in the case where the profitability check ensures
> that n % vf == 0? Thus effectively if n == maximum trip count?
> That's quite a special case, no?
Indeed it is. But I guess that is pretty much the only case whe
On Mon, Mar 17, 2014 at 12:16:08PM +0100, Jakub Jelinek wrote:
> No. IMHO this needs to be:
> || optimize_debug
> + || !flag_no_tree_loop_optimize
> || (!flag_tree_loop_vectorize
> && (global_options_set.x_flag_tree_loop_vectorize
I presume you mean !flag_tree_loop_o
On Mon, Mar 17, 2014 at 02:49:41PM +0100, Marek Polacek wrote:
> 2014-03-17 Marek Polacek
>
> PR middle-end/60534
> * omp-low.c (omp_max_vf): Treat -fno-tree-loop-optimize the same
> as -fno-tree-loop-vectorize.
> (expand_omp_simd): Likewise.
> testsuite/
> * gcc.d
On 03/17/2014 04:39 AM, Jan Hubicka wrote:
Thank you! would preffer different marker than cxa_pure_virtual in the vtable,
most probably simply NULL.
The reason is that __cxa_pure_virtual will appear as a possible target in the
list and it will prevent devirtualization to happen when we end up w
OK.
Jason
On 03/16/2014 04:44 PM, Adam Butcher wrote:
+ if (parser->num_classes_being_defined == 0)
+ while (scope->kind == sk_class)
+ {
+ parent_scope = scope;
+ scope = scope->level_chain;
+ }
+ else
+ while (scope->
Hi!
On Sat, 8 Mar 2014 18:50:15 +0400, Ilya Verbin wrote:
> --- a/libgomp/libgomp.map
> +++ b/libgomp/libgomp.map
> @@ -208,6 +208,7 @@ GOMP_3.0 {
>
> GOMP_4.0 {
>global:
> + GOMP_offload_register;
> GOMP_barrier_cancel;
> GOMP_cancel;
> GOMP_cancellation_point;
Now
On Mon, Mar 17, 2014 at 4:53 AM, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom allows to use ymmXX and zmmXX
> register names in inline asm statements as well as
> in `register` variables definitions.
>
> New tests pass.
> Bootstrap pass.
>
> Is it ok for trunk?
> Do we need to backport it t
On Mon, Mar 17, 2014 at 6:44 AM, Richard Biener wrote:
> On Fri, 14 Mar 2014, Cong Hou wrote:
>
>> On Fri, Mar 14, 2014 at 12:58 AM, Richard Biener wrote:
>> > On Fri, 14 Mar 2014, Jakub Jelinek wrote:
>> >
>> >> On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
>> >> > > Consider t
On Mon, Mar 17, 2014 at 04:00:11PM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Sat, 8 Mar 2014 18:50:15 +0400, Ilya Verbin wrote:
> > --- a/libgomp/libgomp.map
> > +++ b/libgomp/libgomp.map
> > @@ -208,6 +208,7 @@ GOMP_3.0 {
> >
> > GOMP_4.0 {
> >global:
> > + GOMP_offload_register;
> >
On 12 February 2014 10:54, Alex Velenko wrote:
> Hi,
>
> This patch implements vqneg_s64, vqnegd_s64, vqabs_s64 and
> vqabsd_s64 AArch64 intrinsics. Regression tests added.
> Run full regression with no regressions.
>
> Is patch OK?
>
> Thanks,
> Alex
>
> gcc/
>
> 2014-02-12 Alex Velenko
>
>
On Mon, Mar 17, 2014 at 4:12 PM, H.J. Lu wrote:
>> Patch in the bottom allows to use ymmXX and zmmXX
>> register names in inline asm statements as well as
>> in `register` variables definitions.
>>
>> New tests pass.
>> Bootstrap pass.
>>
>> Is it ok for trunk?
>> Do we need to backport it to 4.8
On Fri, Mar 07, 2014 at 09:21:48PM +0100, Thomas Schwinge wrote:
> Maybe it's just too late on a Friday evening, but I don't understand this
> change, part of r204863. GF_OMP_FOR_KIND_FOR has the value zero;
> shouldn't this comparison have remained unchanged? Is the following
> (untested) patch
On 16/03/14 11:25, Renlin Li wrote:
> Hi all,
>
> This is a simple patch to update the AArch64 frame layout comment in
> the source code.
> frame_pointer should point above the local_variables section as we
> define FRAME_GROWS_DOWNWARD = 1.
>
> Is this Okay for stage-4?
>
OK.
R.
On Mon, Mar 17, 2014 at 9:52 AM, Uros Bizjak wrote:
> On Mon, Mar 17, 2014 at 4:12 PM, H.J. Lu wrote:
>
>>> Patch in the bottom allows to use ymmXX and zmmXX
>>> register names in inline asm statements as well as
>>> in `register` variables definitions.
>>>
>>> New tests pass.
>>> Bootstrap pass.
On Mon, Mar 17, 2014 at 10:11 AM, H.J. Lu wrote:
> On Mon, Mar 17, 2014 at 9:52 AM, Uros Bizjak wrote:
>> On Mon, Mar 17, 2014 at 4:12 PM, H.J. Lu wrote:
>>
Patch in the bottom allows to use ymmXX and zmmXX
register names in inline asm statements as well as
in `register` variables
On 17 Mar 17:52, Uros Bizjak wrote:
> On Mon, Mar 17, 2014 at 4:12 PM, H.J. Lu wrote:
>
> >> Is it ok for trunk?
> >> Do we need to backport it to 4.8?
> It does, but the situation is the same as with %eax vs. %rax names.
> So, I think the patch is OK for mainline, and similar patch involving
> o
On 17 Mar 10:16, H.J. Lu wrote:
> BTW, in glibc, there are
>
> asm volatile ("vmovdqa64 %0, %%zmm0" : : "x" (zmm) : "xmm0" );
Maybe. But I belive that this is much more clear to have instead:
asm volatile ("vmovdqa64 %0, %%zmm0" : : "x" (zmm) : "zmm0" );
--
Thanks, K
> On 03/17/2014 04:39 AM, Jan Hubicka wrote:
> >Thank you! would preffer different marker than cxa_pure_virtual in the
> >vtable,
> >most probably simply NULL.
> >
> >The reason is that __cxa_pure_virtual will appear as a possible target in the
> >list and it will prevent devirtualization to happ
On Mon, Mar 17, 2014 at 10:37 AM, Kirill Yukhin wrote:
> On 17 Mar 10:16, H.J. Lu wrote:
>> BTW, in glibc, there are
>>
>> asm volatile ("vmovdqa64 %0, %%zmm0" : : "x" (zmm) : "xmm0" );
> Maybe. But I belive that this is much more clear to have instead:
>asm volatile ("vmovdqa64 %0, %%zmm0
On Mon, Mar 17, 2014 at 11:26:58AM -0700, H.J. Lu wrote:
> On Mon, Mar 17, 2014 at 10:37 AM, Kirill Yukhin
> wrote:
> > On 17 Mar 10:16, H.J. Lu wrote:
> >> BTW, in glibc, there are
> >>
> >> asm volatile ("vmovdqa64 %0, %%zmm0" : : "x" (zmm) : "xmm0" );
> > Maybe. But I belive that this is much
Hi!
Apparently rest_of_decl_compilation only calls varpool_finalize_decl
if not in_lto_p, so this patch calls it explicitly after that call to
make sure with -flto we register the newly created vars with varpool as
well.
Additionally, the patch gives name to a few further builtin types, so that
t
On 03/17/2014 11:47 AM, Jakub Jelinek wrote:
> 2014-03-17 Jakub Jelinek
>
> PR target/60516
> * config/i386/i386.c (ix86_expand_epilogue): Adjust REG_CFA_ADJUST_CFA
> note creation for the 2010-08-31 changes.
>
> * gcc.target/i386/pr60516.c: New test.
Ok.
r~
Hi!
Since r163679 the pop pattern is no longer a PARALLEL, but uses POST_INC.
That commit fixed another spot where REG_CFA_ADJUST_CFA note has been
created from the pop insn pattern, but missed this spot which is rarely used
(requires popping > 64KB arguments by callee).
Bootstrapped/regtested on
On 2014-03-13, 7:37 AM, Andreas Krebbel wrote:
On 13/03/14 12:25, Richard Biener wrote:
On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
operand 0. All operands must hav
Hello,
this patch fixes some regressions introduced by default-option
-fms-extensions for mingw-targets.
ChangeLog
2014-03-17 Kai Tietz
* anon-struct-1.c: Add -fno-ms-extensions option for mingw targets.
* anon-struct-11.c: Likewise.
* anon-struct-2.c: Likewise.
* c11-anon-st
Hi Kai,
> this patch fixes some regressions introduced by default-option
> -fms-extensions for mingw-targets.
you should state in your submissions *which* regressions were
introduced/*which* problem you are fixing. While this may be obvious to
you, it's often not so to reviewers.
> ChangeLog
>
2014-03-17 21:50 GMT+01:00 Rainer Orth :
> Hi Kai,
>
>> this patch fixes some regressions introduced by default-option
>> -fms-extensions for mingw-targets.
>
> you should state in your submissions *which* regressions were
> introduced/*which* problem you are fixing. While this may be obvious to
>
Kai Tietz writes:
> 2014-03-17 21:50 GMT+01:00 Rainer Orth :
>> Hi Kai,
>>
>>> this patch fixes some regressions introduced by default-option
>>> -fms-extensions for mingw-targets.
>>
>> you should state in your submissions *which* regressions were
>> introduced/*which* problem you are fixing. W
On Mon, Mar 17, 2014 at 7:39 AM, Ilya Tocar wrote:
> Do you know of any cases where xor is
> generated (except for destination in gather/scatter)
I don't have any code exhibiting this handy right now. I'll keep an eye out.
> but it also clobbers
> flags. Maybe just define it to setzero for no
So, to support things like this:
(define_constants
(C1_TEMP_REGNUM PROLOGUE_SCRATCH_1)
(C1_TEMP2_REGNUM PROLOGUE_SCRATCH_2)
I need the rtl reader to do less checking. We we turn off int validation, this
then works, and we get:
#define C1_TEMP_REGNUM PROLOGUE_SC
On Sat, 2014-03-08 at 11:15 +0100, Basile Starynkevitch wrote:
> I am pinging again this documentation patch
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
> (pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on
> febµ.17th 2014)
and also pinged at
http://gcc.gnu.org/ml/
56 matches
Mail list logo
