On Tue, Jan 27, 2015 at 09:19:20AM +0300, Yury Gribov wrote:
> As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 , ASan
> may currently report false positives for UBSan internal variables due to
> their incomplete type information. This patch fixes this.
>
> Bootstrapped and regte
On Tue, Jan 27, 2015 at 08:27:07AM +0100, Tobias Burnus wrote:
> 2015-01-27 Tobias Burnus
>
> PR fortran/63861
> gcc/fortran/
> * trans-openmp.c (gfc_has_alloc_comps, gfc_trans_omp_clauses):
> Fix handling for scalar coarrays.
> * trans-types.c (gfc_get_element_type): Ad
> Yes, they do, that is why it crashed during final.
OK. Why wouldn't it work to call reorder_insns instead of reorder_insns_nobb?
--
Eric Botcazou
The attached patch updates the -mhotpatch option and the hopatch
function attribute with (incompatible) new semantics. Please
refer to the commit in the patch for details.
--
2015-01-27 Dominik Vogt
* doc/extend.texi: s/390: Update documentation of hotpatch attribute.
* doc/i
On Tue, Jan 27, 2015 at 09:25:32AM +0100, Eric Botcazou wrote:
> > Yes, they do, that is why it crashed during final.
>
> OK. Why wouldn't it work to call reorder_insns instead of reorder_insns_nobb?
Because reorder_insns doesn't handle the case of moving a barrier into a
middle of basic block.
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> Hi!
>
> On various targets, %s in fprintf can't handle NULL arguments,
> and even when edge->call_stmt is non-NULL, it still might have
> UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename.
> In this particular case it is a fnsplit created
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> Hi!
>
> On x86_64-darwin, we ICE on one of the pr64307.c testcase, because
> expand_thunk doesn't load non-gimple_val arguments into registers
> for the first argument, only for all the other ones.
> Supposedly normally thunks were meant to have this ar
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we generate wrong code, because
> apparently divmod_internal_2 relies on 0 being the topmost
> element (at b_dividend[m]):
>algorithm. M is the number of significant elements of U however
>there needs to be at
> Because reorder_insns doesn't handle the case of moving a barrier into a
> middle of basic block.
Right, I should have read the audit trail. :-) The patch is OK then, but add
a ??? note at the end of the comment saying that the proper thing to do here
is probably not to run cleanup_barrier fo
Janus Weil writes:
> 2015-01-19 Janus Weil
>
> PR fortran/64230
> * gfortran.dg/class_allocate_18.f90: Extended.
FAIL: gfortran.dg/class_allocate_18.f90 -O0 (test for excess errors)
Excess errors:
/usr/ia64-suse-linux/bin/ld: cannot find -lubsan
Andreas.
--
Andreas Schwab, SUSE
This disables array-bound warnings from VRP2 as discussed.
Bootstrapped and tested on x86_64-unknown-linux-gnu - ok for trunk?
I'll search for duplicates and add a few testcases.
Thanks,
Richard.
2015-01-27 Richard Biener
PR tree-optimization/64277
* tree-vrp.c (vrp_finaliz
On Tue, Jan 27, 2015 at 10:24:47AM +0100, Andreas Schwab wrote:
> Janus Weil writes:
>
> > 2015-01-19 Janus Weil
> >
> > PR fortran/64230
> > * gfortran.dg/class_allocate_18.f90: Extended.
>
> FAIL: gfortran.dg/class_allocate_18.f90 -O0 (test for excess errors)
> Excess errors:
> /
On Tue, Jan 27, 2015 at 10:25:48AM +0100, Richard Biener wrote:
>
> This disables array-bound warnings from VRP2 as discussed.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu - ok for trunk?
So nothing in the testsuite needed to change? Nice.
Ok for trunk.
> I'll search for duplicates
As explained in PR64796, code for bswap64 effective target computes the answer
once and then cache. However the result depends on the flags passed to the
compiler and with --target_board it's possible to test several sets of flags.
Besides, this code assume only lp64 targets can do 64-bit bswap
Hi,
This patch was supposed to fix PR tree-optimization/64277. Tracker is now
fixed by warnings disabling but I think patch is still useful to avoid dead
code generated by complete unroll.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Thanks,
Ilya
--
gcc/
2015-01-27 Ilya Enkovich
On 19/01/15 15:46, Kyrill Tkachov wrote:
On 19/01/15 15:44, James Greenhalgh wrote:
On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote:
On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov wrote:
Hi all,
As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
discuss
On Tue, 27 Jan 2015, Jakub Jelinek wrote:
> On Tue, Jan 27, 2015 at 10:25:48AM +0100, Richard Biener wrote:
> >
> > This disables array-bound warnings from VRP2 as discussed.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu - ok for trunk?
>
> So nothing in the testsuite needed to ch
2015-01-27 12:47 GMT+03:00 Richard Biener :
> On Tue, 27 Jan 2015, Jakub Jelinek wrote:
>
>> On Tue, Jan 27, 2015 at 10:25:48AM +0100, Richard Biener wrote:
>> >
>> > This disables array-bound warnings from VRP2 as discussed.
>> >
>> > Bootstrapped and tested on x86_64-unknown-linux-gnu - ok for tr
On 27 Jan 12:40, Ilya Enkovich wrote:
> Hi,
>
> This patch was supposed to fix PR tree-optimization/64277. Tracker is now
> fixed by warnings disabling but I think patch is still useful to avoid dead
> code generated by complete unroll.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
On Tue, 27 Jan 2015, Ilya Enkovich wrote:
> 2015-01-27 12:47 GMT+03:00 Richard Biener :
> > On Tue, 27 Jan 2015, Jakub Jelinek wrote:
> >
> >> On Tue, Jan 27, 2015 at 10:25:48AM +0100, Richard Biener wrote:
> >> >
> >> > This disables array-bound warnings from VRP2 as discussed.
> >> >
> >> > Boot
2015-01-27 13:59 GMT+03:00 Richard Biener :
> On Tue, 27 Jan 2015, Ilya Enkovich wrote:
>
>> 2015-01-27 12:47 GMT+03:00 Richard Biener :
>> > On Tue, 27 Jan 2015, Jakub Jelinek wrote:
>> >
>> >> On Tue, Jan 27, 2015 at 10:25:48AM +0100, Richard Biener wrote:
>> >> >
>> >> > This disables array-boun
On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich wrote:
> On 27 Jan 12:40, Ilya Enkovich wrote:
>> Hi,
>>
>> This patch was supposed to fix PR tree-optimization/64277. Tracker is now
>> fixed by warnings disabling but I think patch is still useful to avoid dead
>> code generated by complete unro
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > > Ok for trunk? Or should I delay this to GCC 6?
> > >
> > > Does this work even without the other patch?
> >
> > Yes, I've actually developed 2/2 first. The other patch only ever
From: Trevor Saunders
Hi,
the compiler crashes on pr52429.c because this_target_ira_int gets initialized
with null x_init_costs and x_op_costs. While I don't really understand this
option handling mess r217659 made the analogous change to i386 when it broke
this. So it seems likely this is t
On Mon, 26 Jan 2015 14:44:19 +0100
Thomas Schwinge wrote:
> > On 17 Jan 02:16, Ilya Verbin wrote:
> > > Unfortunately, it broke offloading from shared libraries (I mean
> > > common libs with NEEDED entries, not dlopened).
>
> Sorry for that!
>
> > > Such things are not covered by the
> > > tes
Richard Sandiford writes:
> Matthew Fortune writes:
> >> 2015-01-23 Robert Suchanek
> >>
> >>* config/mips/mips.c (mips_hard_regno_mode_ok_p): Prohibit
> >> accumulators
> >>for all vector modes.
> >
> > This seems like a genuine bug and although it can only be triggered by
> > loongso
On 27 Jan 12:29, Richard Biener wrote:
> On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich
> wrote:
> > On 27 Jan 12:40, Ilya Enkovich wrote:
> >> Hi,
> >>
> >> This patch was supposed to fix PR tree-optimization/64277. Tracker is now
> >> fixed by warnings disabling but I think patch is still us
On 01/27/2015 05:23 AM, DJ Delorie wrote:
+/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */
+
+# if GCC_VERSION >= 4004
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstrict-overflow"
+#endif
+
#pragma diagnostic ignored was added in 4.4 but #pragma
On Mon, Jan 26, 2015 at 10:11:14AM +0100, Richard Biener wrote:
> On Sat, Jan 24, 2015 at 12:23 AM, Alan Modra wrote:
> > How does this look as a potential fix for PR64703? I haven't made
> > many forays into gimple code, so even though this patch passes
> > bootstrap and regression testing on po
Hi,
Some time ago removal of not instrumented version of funtion with
'always_inline' was delayed to enable their inlining. With this change we may
have situations when we inline into a not instrumented version of a function
which also has an instrumented version (happens when both of them hav
This isn't related to the last patch for this bug, except that the PR
is currently being used for all darwin FAILs.
We need to check a configure macro before using
pthread_rwlock_timedrdlock because Darwin doesn't define the
_POSIX_TIMEOUTS option.
Tested x86_64-linux, committed to trunk.
commit
The new exceptional EH allocator failed to align exception objects
properly (it ended up aligning to __alignof__((std::size_t))). The
following fixes that by aligning to what __attribute__((aligned))
would align to (this is what _Unwind_Exception is aligned to, a
member of __cxa_refcounted_except
On Mon, 26 Jan 2015 17:34:26 +0300
Ilya Verbin wrote:
> Here is my current patch, it works for OpenMP->MIC, but obviously
> will not work for PTX, since it requires symmetrical changes in the
> plugin. Could you please take a look, whether it is possible to
> support this new interface in PTX pl
Jeff Law writes:
> On 01/24/15 04:29, Richard Sandiford wrote:
>>
>> Yeah. I expect in practice most people who used "?" and "!" attached
>> them to a particular operand for a reason. From a quick scan through
>> 386.exp it looked like almost all uses would either want this behaviour
>> or would
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, January 27, 2015 7:19 AM
> To: Richard Sandiford
> Cc: Robert Suchanek; gcc-patches@gcc.gnu.org; Moore, Catherine
> Subject: RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators
>
> Ri
Hi!
I've grepped for BUILT_IN_.*_CHKP in the sources and we actually need
far fewer enum values than the 1204 that are being defined.
This patch requires builtins.def to say explicitly (by using
DEF_*BUILTIN_CHKP macro instead of corresponding DEF_*BUILTIN) which
ones need that, for all the other
On 19/01/15 10:58, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 10:52:14AM +, Ramana Radhakrishnan wrote:
What is aarch64 specific on the testcase?
The number of if-then-else's required to get the compiler to generate
branch sequences rather than the tbnz instruction.
That doesn't mean
On Tue, Jan 27, 2015 at 02:31:14PM +, Jiong Wang wrote:
> testcase changed to execution version, and moved to gcc.dg. the compile time
> only
> take several seconds. (previously I am using cc1 built by O0 which at most
> take 24s)
>
> ok to install?
Ok for the testcase.
The config/aarch64/
Hi,
this patch fixes the ada bootstrap under cygwin-64.
Boot-strapped under x86_64-pc-cygwin.
OK for trunk?
Thanks
Bernd.
2015-01-27 Bernd Edlinger
Fix build under cygwin/64.
* adaint.h: Add check for __CYGWIN__.
* mingw32.h
On 01/27/15 07:08, Richard Sandiford wrote:
Yeah, but in practice that's only ever going to be a partial transition.
Many port maintainers won't look at this, so we'll have to support both
versions indefinitely, even if the new behaviour turns out to be the
best for all cases.
Yes, most likely.
> this patch fixes the ada bootstrap under cygwin-64.
>
> Boot-strapped under x86_64-pc-cygwin.
> OK for trunk?
OK
Hi All,
Here is a simple patch that cures ICE - skip debug gimples.
Test is also included.
Bootstrap and regression testing did not show any new failures.
Is it OK for trunk?
ChangeLog:
2015-01-27 Yuri Rumyantsev
PR tree-optimization/64809
* cfgexpand.c (reorder_operands): Skip debug gimpl
Steve Kargl writes:
> On Sat, Jan 24, 2015 at 06:13:04PM +0100, Tobias Burnus wrote:
>>if (s1->as->type == AS_EXPLICIT)
>> -for (i = 0; i < s1->as->rank + s1->as->corank; i++)
>> +for (i = 0; i < s1->as->rank + std::max(0, s1->as->corank-1); i++)
>
> Doesn't this require '#include
On Tue, Jan 27, 2015 at 03:55:17PM +0100, Rainer Orth wrote:
> Steve Kargl writes:
>
> > On Sat, Jan 24, 2015 at 06:13:04PM +0100, Tobias Burnus wrote:
> >>if (s1->as->type == AS_EXPLICIT)
> >> - for (i = 0; i < s1->as->rank + s1->as->corank; i++)
> >> + for (i = 0; i < s1->as->rank + s
2015-01-27 17:27 GMT+03:00 Jakub Jelinek :
> Hi!
>
> I've grepped for BUILT_IN_.*_CHKP in the sources and we actually need
> far fewer enum values than the 1204 that are being defined.
>
> This patch requires builtins.def to say explicitly (by using
> DEF_*BUILTIN_CHKP macro instead of correspondin
On 27 January 2015 at 14:31, Jiong Wang wrote:
> 2015-01-19 Ramana Radhakrishnan
> Jiong Wang
>
> gcc/
> * config/aarch64/aarch64.md (tb1): Clobber CC reg instead
> of scratch reg.
> (cb1): Likewise.
> * config/aarch64/iterators.md (bcond): New define_code_attr.
OK
Hi!
This patch introduces a new effective target check and adds it to the pr64612.C
- if comdat groups aren't used, there is no guarantee that the D2 dtor will
be emitted always alongside of D1 dtor.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-27 Jakub Jelinek
On Fri, Jan 9, 2015 at 7:43 AM, Terry Guo wrote:
>
>
>> -Original Message-
>> From: Richard Earnshaw
>> Sent: Monday, December 08, 2014 7:31 PM
>> To: Terry Guo; gcc-patches@gcc.gnu.org
>> Cc: Ramana Radhakrishnan
>> Subject: Re: [Patch, ARM/Thumb1]Add a Thumb1 insn pattern to legalize the
Hi,
I've committed the attached patch which fixes a 4.8 vs 4.9/5.0
performance regression introduced with the aggressive use of FPRs as
spill slots.
Committed to mainline and 4.9 branch.
Bye,
-Andreas-
2015-01-27 Andreas Krebbel
* config/s390/s390.c (s390_register_move_cost): Incre
On 27/01/15 14:43 +0100, Richard Biener wrote:
The new exceptional EH allocator failed to align exception objects
properly (it ended up aligning to __alignof__((std::size_t))). The
following fixes that by aligning to what __attribute__((aligned))
would align to (this is what _Unwind_Exception i
Hi,
I've committed the attached patch which fixes a 4.8 vs 4.9/5.0
performance regression introduced with the aggressive use of FPRs as
spill slots.
Committed to mainline and 4.9 branch.
Bye,
-Andreas-
2015-01-27 Andreas Krebbel
* config/s390/s390.c (s390_memory_move_cost): Increas
Hi,
This patch fixes arm/atomic-op-consume.c test to expect safe "LDAEX"
instruction to be generated when __ATOMIC_CONSUME semantics is requested.
This patch was tested by running the modified test on arm-none-eabi and
arm-none-linux-gnueabi compilers.
Is this patch ok?
Alex
2015-01-27 Alex
Jakub Jelinek writes:
>> The problem is (as so often) that was included *before*
>> config.h. Moving it after the other includes allows interface.c to
>> compile without warnings.
>
> Why don't you use MAX macro instead of std::max as everywhere else
> in the gcc sources?
No idea, ask Tobias :
On Tue, Jan 27, 2015 at 4:06 PM, Alex Velenko wrote:
>
> Hi,
>
> This patch fixes arm/atomic-op-consume.c test to expect safe "LDAEX"
> instruction to be generated when __ATOMIC_CONSUME semantics is requested.
>
> This patch was tested by running the modified test on arm-none-eabi and
> arm-none-l
Hi,
This patch fixes aarch64/atomic-op-consume.c test to expect safe "LDAXR"
instruction to be generated when __ATOMIC_CONSUME semantics is requested.
This patch was tested by running the modified test on aarch64-none-elf
compiler.
Is this patch ok?
Alex
2015-01-27 Alex Velenko
gcc/testsu
On 01/22/2015 05:09 PM, Matthias Klose wrote:
> On 01/22/2015 12:56 AM, Andrew Pinski wrote:
>> On Wed, Jan 21, 2015 at 8:51 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 21, 2015 at 08:41:46AM -0800, pins...@gmail.com wrote:
> On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
>
> __objc_
Rainer Orth wrote:
> > Why don't you use MAX macro instead of std::max as everywhere else
> > in the gcc sources?
>
> No idea, ask Tobias :-)
No real reason - presumably, because I had MAX not in mind and thought
of the general move towards standard features.
> Anyway, the original patch would mo
Hi all,
I notice this test fails on aarch64-none-elf because the scan-assembler
scans for w registers when one of them can be the wzr reg since we
store a 0 into *a.
This patch updates the pattern that is scanned for.
Committed as obvious with r220176.
Thanks,
Kyrill
2015-01-27 Kyrylo Tkac
On 01/27/2015 09:08 AM, Richard Sandiford wrote:
>
> Yeah, but in practice that's only ever going to be a partial transition.
> Many port maintainers won't look at this, so we'll have to support both
> versions indefinitely, even if the new behaviour turns out to be the
> best for all cases.
>
> I
Hi,
this patch fixes ICE on type inconsistent programs where vtable pointer
is worked out to be arbitrary pointer to something else.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision
Hi,
the two testcases show somewhat crazy layout of C++ object that goes
in order base1,base2,virtual_base_of_base1
this confuses the walk in get_binfo_at_offset while looking for
virtual_base_of_base1 to look into base2 instead of base1.
It seems that in the case of virtual inheritance we simply
Currently the jit requires you to specify --enable-host-shared, or the
build eventually fails with linker errors (this is something of a FAQ
for people trying out the jit).
We seem to have two choices here:
(A) default to --enable-host-shared when jit is an enabled language
(B) have the toplevel
Vladimir Makarov writes:
> On 01/27/2015 09:08 AM, Richard Sandiford wrote:
>> Yeah, but in practice that's only ever going to be a partial transition.
>> Many port maintainers won't look at this, so we'll have to support both
>> versions indefinitely, even if the new behaviour turns out to be the
On Tue, Jan 27, 2015 at 2:56 AM, Sandra Loosemore
wrote:
> On 01/20/2015 12:02 PM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou
>> wrote:
Ping? Any thoughts?
>>>
>>>
>>> x86 for the family and x86-32/x86-64 for the 2 architectures?
>>>
>>
>> Works for me.
>
>
>
Richard Biener wrote:
> On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> > Then it probably should be ok. I'm really afraid of emitting more warnings
> > with such high false positive rate now.
>
> As the patch also mitigates some of the code bloat we get with
> the complete peeling (regression aga
Hi!
DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
accepted into DWARF5. This patch changes GCC to handle those similarly to
how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
As it will take some time for consumers to catch up, I'm enabling that
only if -g
> On Tue, Jan 27, 2015 at 10:24:47AM +0100, Andreas Schwab wrote:
>>
>> > 2015-01-19 Janus Weil
>> >
>> > PR fortran/64230
>> > * gfortran.dg/class_allocate_18.f90: Extended.
>>
>> FAIL: gfortran.dg/class_allocate_18.f90 -O0 (test for excess errors)
>> Excess errors:
>> /usr/ia64-suse
On Tue, Jan 27, 2015 at 07:20:10PM +0100, Janus Weil wrote:
> 2015-01-27 10:30 GMT+01:00 Jakub Jelinek :
> > Yeah, if you want to add ubsan tests, you need to add gfortran.dg/ubsan/
> > directory and hack up ubsan.exp in there
>
> Thanks for the remark, I was suspecting something like that. Howeve
Thomas,
Any plans to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635 soon? On x86_64
darwin, the OpenACC merge resulted a huge number of failures in the
libgomp test suite…
=== libgomp Summary ===
# of expected passes 10628
# of unexpected failures 724
# of unsupported tests 562
whic
2015-01-27 19:23 GMT+01:00 Jakub Jelinek :
> On Tue, Jan 27, 2015 at 07:20:10PM +0100, Janus Weil wrote:
>> 2015-01-27 10:30 GMT+01:00 Jakub Jelinek :
>> > Yeah, if you want to add ubsan tests, you need to add gfortran.dg/ubsan/
>> > directory and hack up ubsan.exp in there
>>
>> Thanks for the rem
On Tue, 2015-01-27 at 19:19 +0100, Jakub Jelinek wrote:
> Hi!
>
> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5. This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
>
> As it will
On Tue, Jan 27, 2015 at 01:52:12PM -0500, David Malcolm wrote:
> > @@ -398,6 +399,11 @@ gfc_post_options (const char **pfilename
> >
> >gfc_cpp_post_options ();
> >
> > + if (gfc_option.allow_std & GFC_STD_F2008)
> > +lang_hooks.name = "GNU Fortran2008";
> > + else if (gfc_option.allo
We were trying to instantiate is_ok with only the innermost set of
template arguments; we need to make sure that the outer args are
provided as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e2df55ffbe254dfc15801a204af16d012aeb4cb5
Author: Jason Merrill
Date: Mon Jan 26 10:55:42
Tobias Burnus wrote:
This one compiles just as well, of course.
From my side, that patch (using MAX) is fine. Thanks for
bearing the bootstrap failure and for the patch.
I have now committed it (i.e. Rainer's patch) as Rev. 220182.
I have also committed the fixed-up/combined patch to the 4.9
On 01/26/15 22:11, Segher Boessenkool wrote:
On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
The second change we need is an additional simplification.
If we have
(subreg:M1 (zero_extend:M2 (x))
Where M1 > M2 and both are scalar integer modes. It's advantageous to
strip the SUBREG a
Jakub Jelinek wrote:
DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
accepted into DWARF5. This patch changes GCC to handle those similarly to
how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
For completeness: gfortran currently produces "GNU Fortran" an
On Tue, Jan 27, 2015 at 12:27:38PM -0700, Jeff Law wrote:
> On 01/26/15 22:11, Segher Boessenkool wrote:
> >On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
> >>The second change we need is an additional simplification.
> >>
> >>If we have
> >>(subreg:M1 (zero_extend:M2 (x))
> >>
> >>Where
Dear All,
This patch enables the passing of an allocatable class object, scalar
or array, to a derived type of the declared type, either in an
assignment or as an actual argument. Much of the effort went into
sorting out the finalization call so that the 'left over' allocatable
components added by
On 01/23/2015 01:45 PM, Aldy Hernandez wrote:
It would expect [the flush] to be before free_lang_data and LTO streaming.
The reason this wouldn't make a difference is because, as it stands,
dwarf for the clones are not generated until final.c:
if (!DECL_IGNORED_P (current_function_decl))
On 01/27/15 13:36, Segher Boessenkool wrote:
I mean e.g. DI on a 32-bit target. My worry is that zero_extend:DI then
is more expensive -- if say, it is implemented as a split, combine itself
cannot get rid of the redundancy.
OK. Let me play with that a bit.
Okay, if there are actual real ca
Dear All,
The highly embarrassing bug in mold = allocations to class entities
has been fixed in revisions 220140 and 220191 for trunk and 4.9
respectively. The PR has been set as RESOLVED.
Cheers
Paul
On Tue, Jan 27, 2015 at 01:53:34PM -0700, Jeff Law wrote:
> >I do have a specific PR in mind, but I cannot currently find it. It was
> >about x86, dec mem and then using the flags... Must have sent 100 emails
> >in that thread... And cannot find it now!
> Are you referring to 61225?
That is the
Here, sometimes we can end up in maybe_add_lambda_conv_op with
current_function_decl set but not cfun. If we push_function_context in
that case, the later pop doesn't clear cfun, but leaves it with a value
that leads to a crash later on. So let's avoid calling
push_function_context in that ca
On 01/27/15 13:36, Segher Boessenkool wrote:
On Tue, Jan 27, 2015 at 12:27:38PM -0700, Jeff Law wrote:
On 01/26/15 22:11, Segher Boessenkool wrote:
On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
The second change we need is an additional simplification.
If we have
(subreg:M1 (zero_
On 01/27/2015 12:11 PM, Richard Sandiford wrote:
> Vladimir Makarov writes:
>> On 01/27/2015 09:08 AM, Richard Sandiford wrote:
>>> Yeah, but in practice that's only ever going to be a partial transition.
>>> Many port maintainers won't look at this, so we'll have to support both
>>> versions inde
On 01/27/15 14:21, Segher Boessenkool wrote:
On Tue, Jan 27, 2015 at 01:53:34PM -0700, Jeff Law wrote:
I do have a specific PR in mind, but I cannot currently find it. It was
about x86, dec mem and then using the flags... Must have sent 100 emails
in that thread... And cannot find it now!
Ar
On Tue, Jan 27, 2015 at 06:04:53PM +0300, Ilya Enkovich wrote:
> 2015-01-27 17:27 GMT+03:00 Jakub Jelinek :
> > I've grepped for BUILT_IN_.*_CHKP in the sources and we actually need
> > far fewer enum values than the 1204 that are being defined.
> >
> > This patch requires builtins.def to say expli
On Jan 27, 2015, at 7:10 AM, Jakub Jelinek wrote:
>
> This patch introduces a new effective target check and adds it to the
> pr64612.C
> - if comdat groups aren't used, there is no guarantee that the D2 dtor will
> be emitted always alongside of D1 dtor.
>
> Bootstrapped/regtested on x86_64-li
On Wed, Jan 21, 2015 at 02:01:44PM -0500, David Edelsohn wrote:
> I want to avoid duplicating the -mcpu parsing logic or the Rube
> Goldberg mechanism to re-generate the -mXXX assembler directive.
Oh well, I had fun writing the patch. I thought it reasonably
elegant, meeting the goals you state a
On Tue, Jan 27, 2015 at 7:27 PM, Alan Modra wrote:
> On Wed, Jan 21, 2015 at 02:01:44PM -0500, David Edelsohn wrote:
>> I want to avoid duplicating the -mcpu parsing logic or the Rube
>> Goldberg mechanism to re-generate the -mXXX assembler directive.
>
> Oh well, I had fun writing the patch. I t
> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Monday, January 26, 2015 7:34 PM
> To: Terry Guo
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan
> Subject: Re: [Patch][wwwdocs]Deprecate the ARM TPCS related options in
> gcc 5.0
>
> On
I'm withdrawing the combine_simplify_rtx hunk of this patch. While
working cleaning up my improvements for the remaining of testcases I
stumbled upon a simpler change which covers all the tests.
What's kind of funny is I'd been staring at the relevant code a goodly
part of the weekend without
On Oct 23, 2014, at 4:18 AM, Jeff Law wrote:
> On 10/22/14 17:01, Maxim Kuvyrkov wrote:
>> On Oct 23, 2014, at 9:02 AM, Jeff Law wrote:
>>
>>> On 10/20/14 21:35, Maxim Kuvyrkov wrote:
Hi,
This patch is a simple fix to allow decompose_address to handle
SCRATCH'es during 2nd
93 matches
Mail list logo
