In this testcase, the problem is that when we make_auto for the auto
return type, we don't know yet that we're dealing with a function
template, so the auto return type ends up with the same template
parameter level as the implicit template parameters.
This patch fixes this by generating a new
On July 24, 2015 10:47:37 PM GMT+02:00, "H.J. Lu" wrote:
>On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva
>wrote:
>> On Jul 24, 2015, "H.J. Lu" wrote:
>>
>>> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva
> wrote:
On Jul 23, 2015, "H.J. Lu" wrote:
> https://gcc.gnu.org/bugzill
On 07/24/2015 05:15 PM, Trevor Saunders wrote:
Moreover, this warning works in exactly the same cases as
__attribute__((nonnull)) does for function arguments, and so far those
haven't been a source of false positives.
I'm sure I could write one ;-) And given that a FE based version of this
w
> On Jul 24, 2015, at 7:36 PM, tbsaunde+...@tbsaunde.org wrote:
>
> From: Trevor Saunders
>
> gcc/ChangeLog:
>
> 2015-07-25 Trevor Saunders
>
>* defaults.h (ASM_OUTPUT_ASCII): Remove default definition.
>* doc/tm.texi: Regenerate.
>* doc/tm.texi.in (ASM_OUTPUT_AS
From: Trevor Saunders
Hi,
$subject, this gets rid of 3 macros, and moves one more closer to being a hook.
each patch bootstrapped + regtested on x86_64-linux-gnu, and the series was run
through config-list.mk, ok?
thanks!
Trev
Trevor Saunders (4):
convert ASM_OUTPUT_ASCII to a hook
mak
From: Trevor Saunders
* config/arc/arc.h, config/bfin/bfin.h, config/frv/frv.h,
config/ia64/ia64-protos.h, config/ia64/ia64.c, config/ia64/ia64.h,
config/lm32/lm32.h, config/mep/mep.h, config/mmix/mmix.h,
config/rs6000/rs6000.c, config/rs6000/xcoff.h, config/spu/sp
From: Trevor Saunders
gcc/ChangeLog:
2015-07-24 Trevor Saunders
* config/i386/sol2.h: Adjust.
* defaults.h: Likewise.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Remove documentation of removed
TLS_COMMON_ASM_OP macro.
* target.def (tls_common
From: Trevor Saunders
gcc/ChangeLog:
2015-07-25 Trevor Saunders
* defaults.h (ASM_OUTPUT_ASCII): Remove default definition.
*doc/tm.texi: Regenerate.
* doc/tm.texi.in (ASM_OUTPUT_ASCII): Remove documentation of
removed macro.
*
From: Trevor Saunders
gcc/ChangeLog:
2015-07-24 Trevor Saunders
* config/rs6000/aix43.h (TARGET_DEFERRED_OUTPUT_DEFS): Remove.
* defaults.h (TARGET_DEFERRED_OUTPUT_DEFS): Likewise.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_DEFERRED_OUTPUT_DEFS): Remo
On Fri, Jul 24, 2015 at 09:09:39AM +0100, Kyrill Tkachov wrote:
> This transformation folds (X % C) == N into
> X & ((1 << (size - 1)) | (C - 1))) == N
> for constants C and N where N is positive and C is a power of 2.
For N = 0 you can transform it to
((unsigned)X % C) == N
and for 0 <
On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva wrote:
> On Jul 23, 2015, David Edelsohn wrote:
>
>> I request that this patch be reverted (again).
>
> Might I kindly ask you to please do so for me. I've just found out
> that, after yesterday's memory upgrade on my local build machine, the
> fi
On 07/24/2015 04:41 PM, Manuel López-Ibáñez wrote:
On 25 July 2015 at 00:17, Patrick Palka wrote:
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
Is there a PR for this particular test case? I am interested in
improving the uninit analysis for gcc 6 so this potentially seems up
my
On 07/24/2015 04:17 PM, Patrick Palka wrote:
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
On 24 July 2015 at 21:30, Jeff Law wrote:
On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate
On 07/24/2015 03:55 PM, Manuel López-Ibáñez wrote:
I think it is also a matter of the particular warning and on the
balance of true positives vs. false positives in typical code-bases.
In this case, returning NULL in any code-path from a returns_nonnull
function, even if the path is currently un
On 25 July 2015 at 01:15, Trevor Saunders wrote:
> I'd actually expect reasonable cases to be fairly common. For example
I added it to -Wall, I guess we'll see... not sure how many users of
returns_nonnull are out there.
In all your cases there is no reason to prefer NULL rather than, say,
(T*)
This patch from Lynn Boger adds the tunneling constants from if_tun.h
to libgo. This fixes https://golang.org/issue/11707. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
On 24/07/15 18:29, Uros Bizjak wrote:
This patch introduces ADJUST_INSN_LENGTH define to i386.h to increase
the length of the insn when bnd prefix is used.
2015-07-24 Uros Bizjak
PR target/64003
* config/i386/i386.h (ADJUST_INSN_LENGTH): New define.
* config/i386/i386.md (mayb
On Fri, Jul 24, 2015 at 11:55:23PM +0200, Manuel López-Ibáñez wrote:
> On 24 July 2015 at 21:30, Jeff Law wrote:
> > On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
> >>
> >> On 23 July 2015 at 19:43, Jeff Law wrote:
> >>>
> >>> Warning in the front-ends like this can generate false positives
On 07/20/2015 08:19 AM, James Greenhalgh wrote:
On Wed, May 20, 2015 at 05:36:25PM +0100, Jeff Law wrote:
These fix the remaining leaks in the threader that I'm aware of. We
failed to properly clean-up when we had to cancel certain jump threading
opportunities. So thankfully this wasn't a big
On 25 July 2015 at 00:17, Patrick Palka wrote:
> On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
> wrote:
> Is there a PR for this particular test case? I am interested in
> improving the uninit analysis for gcc 6 so this potentially seems up
> my alley.
We do not warn because of the infam
When trying to analyze why Graphite does not handle a loop nest, it is easy to
look in the dumps of -fdump-tree-graphite-all to guess what has to be changed to
catch the loop. This patch makes the dumps a bit more verbose and useful.
---
gcc/graphite-scop-detection.c | 72
On 07/24/2015 03:53 PM, Sebastian Pop wrote:
Jeff Law wrote:
On 07/21/2015 02:32 PM, Sebastian Pop wrote:
Could somebody with access to sourceware.org upload a tar.bz2 of the required
version of isl from http://isl.gforge.inria.fr/isl-0.15.tar.bz2?
Also, once that is done, I will commit the f
These checks are already present in is_va_list_char_pointer.
2015-07-25 Uros Bizjak
* config/i386/i386.c (ix86_va_start): Remove
unneeded !TARGET_64BIT check.
(ix86_gimplify_va_arg): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
> On 24 July 2015 at 21:30, Jeff Law wrote:
>> On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
>>>
>>> On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate false positives (such as
On 06/26/2015 12:33 AM, Alexander Basov wrote:
2015-06-25 21:47 GMT+03:00 Jeff Law :
On 06/03/2015 02:15 PM, Alexander Basov wrote:
Hello Jeff,
please find updated patch attached
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index b190f91..c6db8a9 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfge
On 24 July 2015 at 21:30, Jeff Law wrote:
> On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
>>
>> On 23 July 2015 at 19:43, Jeff Law wrote:
>>>
>>> Warning in the front-ends like this can generate false positives (such as
>>> a
>>> NULL return in an unreachable path and miss cases where the NU
Jeff Law wrote:
> On 07/21/2015 02:32 PM, Sebastian Pop wrote:
> >
> >Could somebody with access to sourceware.org upload a tar.bz2 of the required
> >version of isl from http://isl.gforge.inria.fr/isl-0.15.tar.bz2?
> >
> >Also, once that is done, I will commit the following patch updating the
> >d
On 07/22/2015 02:02 PM, Marek Polacek wrote:
On Wed, Jul 22, 2015 at 01:48:03PM -0600, Martin Sebor wrote:
On 07/22/2015 01:06 PM, Marek Polacek wrote:
On Wed, Jul 22, 2015 at 12:43:53PM -0600, Martin Sebor wrote:
On 07/14/2015 09:18 AM, Marek Polacek wrote:
Code such as "if (i == i)" is hard
On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva wrote:
> On Jul 24, 2015, "H.J. Lu" wrote:
>
>> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>>> On Jul 23, 2015, "H.J. Lu" wrote:
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>>>
>>> My test logs with the patch have:
>
Hi,
The attached patch adds additional test for the routine
directive for C/C++/Fortran.
Committed to gomp-4_0-branch.
Jim
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-3.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-3.c
new file mode 100644
index 000..73ca528
-
On Jul 24, 2015, "H.J. Lu" wrote:
> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>> On Jul 23, 2015, "H.J. Lu" wrote:
>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>>
>> My test logs with the patch have:
>>
>> PASS: c-c++-common/dfp/func-vararg-dfp.c execution test
>>
On Jul 24, 2015, David Edelsohn wrote:
> Did you commit the final, complete version of the patches?
Yes, I have double-checked that reverting the patch I posted on the
r225979 tree I used for testing reverts it to the base revision, except
for unrelated libgfortran configury changes that I used
Richard Biener wrote:
> On Wed, Jul 22, 2015 at 6:00 PM, Tom de Vries wrote:
> > Currently bootstrapping and reg-testing on x86_64.
> >
> > OK for trunk?
> >
> > OK 5 and 4.9 release branches?
>
> Ok if Sebastian is fine with it.
Ok to backport as well.
Thanks Tom for the patches.
On Wed, Jul 22, 2015 at 11:13:48PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 20, 2015 at 08:10:41PM +0200, Jakub Jelinek wrote:
> > And here is untested incremental libgomp side of the proposed
> > GOMP_MAP_FIRSTPRIVATE_POINTER.
>
> Actually, that seems unnecessary, for the array section maps we a
On Jul 23, 2015, David Edelsohn wrote:
> I request that this patch be reverted (again).
Might I kindly ask you to please do so for me. I've just found out
that, after yesterday's memory upgrade on my local build machine, the
filesystem that I normally use for GCC development got corrupted, and
On 07/24/15 15:51, Ilya Verbin wrote:
On Fri, Jul 24, 2015 at 15:26:38 -0400, Nathan Sidwell wrote:
mber into mkoffload:process () like:
865 fprintf (out, "static const void *target_data[] = {\n");
866 fprintf (out, " MAGIC, VERSION, ptx_code, (void*) %u, var_mappings, (void*)
%u, "
867
On Fri, Jul 24, 2015 at 15:26:38 -0400, Nathan Sidwell wrote:
> this version makes the following changes to the earlier version.
>
> *) Renames things to FOO_ver, rather than FOO_2
>
> *) No attempt to deal with cross-version plugins and libgomp.
>
> *) Adds GOMP_OFFLOAD_version function to plug
On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate false positives (such as a
NULL return in an unreachable path and miss cases where the NULL has to be
propagated into the return by later optimizations.
Jakub,
this version makes the following changes to the earlier version.
*) Renames things to FOO_ver, rather than FOO_2
*) No attempt to deal with cross-version plugins and libgomp.
*) Adds GOMP_OFFLOAD_version function to plugin. (I went with your approach).
Returns the GOMP_VERSION used to b
On Fri, Jul 24, 2015 at 3:10 PM, H.J. Lu wrote:
> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>> On Jul 23, 2015, "H.J. Lu" wrote:
>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>>
>> My test logs with the patch have:
>>
>> PASS: c-c++-common/dfp/func-vararg-dfp.c executi
On 07/24/2015 03:16 AM, Richard Biener wrote:
Is there any rationale given anywhere for the transformation into
conditional expressions? ie, is there any reason why we can't have a
GIMPLE_COND where the expression is a vector condition?
No rationale for equality compare which would have the se
On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
> On Jul 23, 2015, "H.J. Lu" wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>
> My test logs with the patch have:
>
> PASS: c-c++-common/dfp/func-vararg-dfp.c execution test
>
> so I think this one is not caused by the PR641
On 07/24/2015 02:06 AM, Bernhard Reutner-Fischer wrote:
Looking at the reduced testcase in that PR, I'm pretty sure its a bogus
reduction.
Yes, the original, smallish test case in comment #4 is different, AFAICS.
Agreed. I should have been a bit more explicit. The test in c#5 is not
a vali
... and group them together.
2015-07-24 Uros Bizjak
* config/i386/i386.c (ix86_call_abi_override): Call ix86_function_abi.
(ix86_function_abi): Cleanup.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
I've committed this to gomp4 branch. It's the openacc equivalent of the omp
cleanup I committed earlier to both trunk and gomp4.
nathan
2015-07-24 Nathan Sidwell
* gimplify.c (device_resident_p): New function, broken out of
omp_notice_variable.
(oacc_default_clause): New function. Reorga
This patch from Chris Manghane fixes the Go frontend to not crash
after parsing a malformed receiver or parameter. This fixes
https://golang.org/issue/11576 . Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
On Thu, Jun 4, 2015 at 9:54 AM, Sriraman Tallam wrote:
>> Patch attached with those changes.
>
> Is this patch alright to commit?
>
>
> * c-family/c-common.c (noplt): New attribute.
> (handle_noplt_attribute): New handler.
> * calls.c (prepare_call_address): Check for noplt attribute.
> * config/i
On Jul 23, 2015, "H.J. Lu" wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
My test logs with the patch have:
PASS: c-c++-common/dfp/func-vararg-dfp.c execution test
so I think this one is not caused by the PR64164 patch.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lx
On 07/24/2015 03:31 AM, Kyrill Tkachov wrote:
Wouldn't it be better to walk BB_A, gathering the set of all the
registers modified, then do a single walk through BB testing for uses of
those registers?
I think so, yes. I'll try that.
You might look at resource.c -- I haven't looked at it in a l
On 07/24/2015 03:44 AM, Ramana Radhakrishnan wrote:
In expr.c, with TER you can detect such patterns, in this case when
expanding the comparison, but perhaps we want a *.pd file that would have
rules that would be only GIMPLE and only enabled in a special pass right
before (or very close to) exp
The Go spec says that rune hex literals should start with \x. The Go
frontend was incorrectly accepting \X as well. This patch by Chris
Manghane fixes the problem. This is https://golang.org/issue/11575 .
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
On 07/16/2015 06:26 PM, Michael Darling wrote:
Ping. I don't have write access.
**Updated patch ATTACHED**, modified so the commits during the past
two months don't cause conflicts. Minor other updating (i.e. Likewise
rather than repeating in ChangeLogs.)
Binutils **updated patch also ATTACHE
On 17/07/15 20:00, pins...@gmail.com wrote:
On Jul 17, 2015, at 9:58 PM, Kyrill Tkachov wrote:
On 10/07/15 14:45, Kyrill Tkachov wrote:
On 10/07/15 10:00, pins...@gmail.com wrote:
On Jul 10, 2015, at 1:47 AM, Kyrill Tkachov wrote:
Hi Andrew,
On 10/07/15 09:40, pins...@gmail.com w
On Jul 23, 2015, Segher Boessenkool wrote:
> On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote:
>> Yeah. Thanks, I've tested it with this change, and I'm now checking
>> this in (full patch first; adjusted incremental patch at the end):
> Unfortunately it causes about a thousand t
Hi,
The attached patch fixes a couple of missing variable
initializations.
Committed to gomp-4_0-branch.
Jim
diff --git a/libgomp/target.c b/libgomp/target.c
index 16283ad..0470d3b 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -1130,7 +1130,7 @@ gomp_load_plugin_for_device (struct go
On Fri, Jul 24, 2015 at 10:53 AM, Alexandre Oliva wrote:
> On Jul 24, 2015, "H.J. Lu" wrote:
>
>> Static chain returned from get_rtl_for_parm_ssa_default_def may not
>> have Pmode. This patch converts static chain to Pmode if needed.
>> Tested on Linux/x86-64. OK for trunk?
>
> Yeah, this looks
On Jul 24, 2015, "H.J. Lu" wrote:
> Static chain returned from get_rtl_for_parm_ssa_default_def may not
> have Pmode. This patch converts static chain to Pmode if needed.
> Tested on Linux/x86-64. OK for trunk?
Yeah, this looks good to me, thanks. Even the static chain parm_decl
undergoes pro
This patch by Chris Manghane fixes the Go frontend so that when moving
expressions to ensure that they are evaluated in the correct order, it
does not bother to move a constant expression. This fixes
https://golang.org/issue/11039 . Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.
Hi all,
This patch uses std::swap in a few places in the midend, replacing the manual
approach, and removing
a few, now unused, local variables in the process.
Bootstrapped on x86_64.
Committed as obvious with r226179.
Thanks,
Kyrill
2015-07-24 Kyrylo Tkachov
* alias.c (nonoverlappin
On 07/24/15 12:30, Jakub Jelinek wrote:
So there is no version anywhere? I remember in the design ideas the plan
was that the data section containing the target info (that originally has
been meant to be passed as GOMP_target parameter, but later on has been
changed to the register/unregister a
On Fri, Jul 24, 2015 at 18:30:16 +0200, Jakub Jelinek wrote:
> On Fri, Jul 24, 2015 at 09:32:04AM -0400, Nathan Sidwell wrote:
> > On 07/21/15 11:21, Nathan Sidwell wrote:
> > >On 07/21/15 09:25, Nathan Sidwell wrote:
> > >>This trunk patch implements new register and unregister entry points to
>
On Fri, Jul 24, 2015 at 09:32:04AM -0400, Nathan Sidwell wrote:
> On 07/21/15 11:21, Nathan Sidwell wrote:
> >On 07/21/15 09:25, Nathan Sidwell wrote:
> >>This trunk patch implements new register and unregister entry points to
> >>allow
> >>specifying data version information. (I'll shortly be po
On 23/07/15 23:54 +0200, Torvald Riegel wrote:
On Thu, 2015-07-23 at 09:21 +0100, Jonathan Wakely wrote:
On 22/07/15 22:30 -0400, Patrick Palka wrote:
>Specifically, line 149 of atomix_futex.h has a bare "return;"
>statement, but the function is marked as returning non-void. This was
>caught wh
This patch introduces ADJUST_INSN_LENGTH define to i386.h to increase
the length of the insn when bnd prefix is used.
2015-07-24 Uros Bizjak
PR target/64003
* config/i386/i386.h (ADJUST_INSN_LENGTH): New define.
* config/i386/i386.md (maybe_prefix_bnd): New attribute.
(*jcc_1,
On 24/07/15 14:20, Marcus Shawcroft wrote:
> On 22 July 2015 at 18:22, Szabolcs Nagy wrote:
>
>> 2015-07-22 Szabolcs Nagy
>>
>> * config/aarch64/aarch64-elf-raw.h (LINK_SPEC): Handle -h, -static,
>> -shared, -symbolic, -rdynamic.
>
> OK, this should be back ported to 5 and 4.9
On 24/07/15 13:50, Marcus Shawcroft wrote:
> On 22 July 2015 at 18:13, Szabolcs Nagy wrote:
>> Same as
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01387.html
>> but for AArch64.
>>
>> -dynamic-linker is only passed to the linker if !static && !shared.
>>
>> -rdynamic handling is changed too t
Hello,
I committed the patch for PR64984 that I had posted on bugzilla.
It was approved by Paul:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986#c13
Mikael
On 07/24/15 08:43:05, Gary Funck wrote:
>
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
>
> Confirmed that GCC trunk bootstraps without issue and
> that this patch fixes the issue noted in the GUPC branch.
>
> 2015-07-24 Gary Funck
>
> PR middle-end/66984
> * fold
On 07/24/15 11:22, Jakub Jelinek wrote:
On Fri, Jul 24, 2015 at 11:10:59AM -0400, Nathan Sidwell wrote:
+case OMP_CLAUSE_DEFAULT_NONE:
+ {
+ const char *accn;
Can you rename this variable to something that makes sense?
kind, or construct, or name, or directive?
Hm, yeah, tha
Find a missing test case for
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00789.html left at the corner.
Merged with the latest trunk. New test case does not fail on
thumb1/thumb2/arm targets.
ChangeLog:
2015-07-24: Joey Ye
* gcc.target/arm/thumb2-pop-single.c: New test.
diff --git
On Fri, Jul 24, 2015 at 17:24:55 +0200, Jakub Jelinek wrote:
> On Fri, Jul 24, 2015 at 06:21:34PM +0300, Ilya Verbin wrote:
> > On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote:
> > > The second point is interesting. Offloaded functions require the "omp
> > > target" attribute or tha
On 07/24/2015 08:21 AM, Ilya Verbin wrote:
> On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote:
>> The second point is interesting. Offloaded functions require the "omp
>> target" attribute or that function won't reach the lto compiler. That's
>> fine because not all targets can handl
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
Confirmed that GCC trunk bootstraps without issue and
that this patch fixes the issue noted in the GUPC branch.
2015-07-24 Gary Funck
PR middle-end/66984
* fold-const.c (fold_binary_loc): Call fold_convert on arguments t
Hi,
movtf is unnecessary as a separate expander. Move this to be with
the standard scalar floating point expanders.
Achieved by adding a new iterator and then using the same.
Tested cross aarch64-none-elf and no regressions.
Ramana
* config/aarch64/aarch.md (mov:GPF): Use ALLTF.
On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote:
> The second point is interesting. Offloaded functions require the "omp
> target" attribute or that function won't reach the lto compiler. That's
> fine because not all targets can handle general code. The problem occurs
> when a user
On Fri, Jul 24, 2015 at 06:21:34PM +0300, Ilya Verbin wrote:
> On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote:
> > The second point is interesting. Offloaded functions require the "omp
> > target" attribute or that function won't reach the lto compiler. That's
> > fine because not
On Fri, Jul 24, 2015 at 11:10:59AM -0400, Nathan Sidwell wrote:
> 2015-07-24 Nathan Sidwell
>
> * gimplify.c (omp_default_clause): New function. Reorganize flow
> for clarity. Broken out of ...
> (omp_notice_variable): ... here.
Ok, except:
> +case OMP_CLAUSE_DEFAULT_NO
Jakub,
in working on openacc default clause handling, I found the logic in
omp_notice_variable a little hard to follow, due to the size of function and
depth of nesting.
I broke out the existing default handling to a separate function, and made the
control flow a bit clearer (IMHO).
ok for
Hi,
this patch adds a message to the parloops dump file when
transform_to_exit_first_loop_alt is successful. In the relevant
testcases, we scan for this message, instead of for code patterns,
making the tests more stable.
Committed as trivial.
Thanks,
- Tom
Add transform_to_exit_first_loop_
Jim ran into an ICE in a fortran program which contains an acc vector
loop with a call to a subroutine. There are two things going on in here.
First, a couple of functions in tree-nested.c weren't considering the
_GANG, _WORKER, _VECTOR, and _SEQ omp clause codes. Second, the target
lto compiler wo
Dominik Vogt wrote:
> gcc/ChangeLog
>
> * config.hosto_plugin_soname): Include driver-native.c only when
> building with s390* as host and target.
(There seems to be a typo in the log entry ...)
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Hi,
Static chain returned from get_rtl_for_parm_ssa_default_def may not
have Pmode. This patch converts static chain to Pmode if needed.
Tested on Linux/x86-64. OK for trunk?
Thanks.
H.J.
---
2015-07-24 H.J. Lu
PR bootstrap/66978
* function.c (expand_function_start): Conve
The attached patch cleans up cross compilation as discussed here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01929.html
on top of the fixes that have already been committed; see here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01545.html
This is only cleanup work, there is no compile problem
Hi,
this patch allows parallelization and vectorization of reduction
operators that are guaranteed to not overflow (such as min and max
operators), independent of the overflow behaviour of the type.
Bootstrapped and reg-tested on x86_64.
OK for trunk?
Thanks,
- Tom
Allow non-overflow ops in
On Fri, Jul 24, 2015 at 07:21:07AM -0700, Cesar Philippidis wrote:
> This patch the check for IS_TYPE_OF_DECL_P in this patch. Is this ok for
> trunk?
> 2015-07-24 Cesar Philippidis
>
> gcc/
> * tree-cfg.c (struct replace_decls_d): New struct.
> (replace_block_vars_by_duplica
With that problem fixed I still see one minor glitch. Maybe
someone knows how to fix the following:
* With a cross compiler that generates i686 binaries on s390x:
$ i686-elf-gcc -c ~/foo.c -march=native
/home/vogt/foo.c:1:0: error: bad value (native) for -march= switch
This is all right
On Fri, 2015-07-24 at 10:01 +0200, Jakub Jelinek wrote:
> #!/usr/bin/python
> import sys
> with open(sys.argv[1],"rb") as f:
> nextblock = f.read(12)
> while 1:
> block = nextblock
> nextblock = f.read(12)
> if block == "":
> break
> str = ""
>
On 07/23/2015 03:11 PM, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 03:01:25PM -0700, Cesar Philippidis wrote:
>> On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
>>> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
The attached patch does just that; it teaches
replace_bl
On 23 July 2015 at 19:43, Jeff Law wrote:
> Warning in the front-ends like this can generate false positives (such as a
> NULL return in an unreachable path and miss cases where the NULL has to be
> propagated into the return by later optimizations.
False positives (for the warning as proposed ri
On 07/21/15 11:21, Nathan Sidwell wrote:
On 07/21/15 09:25, Nathan Sidwell wrote:
This trunk patch implements new register and unregister entry points to allow
specifying data version information. (I'll shortly be posting patches changing
the PTX offload data format.)
We now have GOMP_offload_
On 22 July 2015 at 18:22, Szabolcs Nagy wrote:
> 2015-07-22 Szabolcs Nagy
>
> * config/aarch64/aarch64-elf-raw.h (LINK_SPEC): Handle -h, -static,
> -shared, -symbolic, -rdynamic.
OK, this should be back ported to 5 and 4.9 aswell.
Thanks
/Marcus
On 22 July 2015 at 18:13, Szabolcs Nagy wrote:
> Same as
> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01387.html
> but for AArch64.
>
> -dynamic-linker is only passed to the linker if !static && !shared.
>
> -rdynamic handling is changed too to be consistent with arm:
> only pass -export-dynami
The following patch implements the simplest approach of splitting
the huge functions in gimple-match.c (not yet generic-match.c).
In my dev tree it does:
build/genmatch --gimple /space/rguenther/tramp3d/trunk/gcc/match.pd \
> tmp-gimple-match.c
GIMPLE decision tree has 696 leafs, maximum dep
On Fri, Jul 24, 2015 at 2:22 AM, Richard Biener
wrote:
> On Fri, Jul 24, 2015 at 1:19 AM, H.J. Lu wrote:
>> On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn wrote:
>>> On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu wrote:
On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
> On Thu, Jul 23, 2015
This moves simplifying of comparisons against the highest or lowest
possible integer.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
This needs the GENERIC code-gen fix, otherwise we miscompile GCC.
Richard.
2015-07-24 Richard Biener
* fold-const.c (fold_binary_loc
Dear All,
In the words of Jean-Luc Picard, "I will make it so "
Paul
On 24 July 2015 at 10:08, Damian Rouson wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
>> wrote:
>>
>> Dear Mikael,
>>
>>
On Fri, Jul 24, 2015 at 7:23 PM, Richard Biener
wrote:
> On Fri, Jul 24, 2015 at 1:09 PM, Bin.Cheng wrote:
>> On Thu, Jul 23, 2015 at 10:06 PM, Richard Biener
>> wrote:
>>> On Fri, Jul 17, 2015 at 8:27 AM, Bin Cheng wrote:
Hi,
This patch is to fix PR66388. It's an old issue but recen
This fixes wrong-code when GENERIC code generation is faced with
collapsed captures from conditional converts. In this case it
gets confused when looking for omitted operands.
Fixed with the following. It does affect quite a number of
cases on trunk - I will have a look at the branch next to se
[ was: [RFC, PR66873] Use graphite for parloops ]
On 22/07/15 13:02, Richard Biener wrote:
+#define FIXED_POINT_TYPE_OVERFLOW_WRAPS_P(TYPE) \
+ (NON_SAT_FIXED_POINT_TYPE_P (TYPE))
somebody with knowledge about fixed-point types needs to review this.
In vect_is_simple_reduction_1 I noticed:
.
This calculates size estimates for the decision (sub-)trees and dumps
info to stderr. My dev tree says:
build/genmatch --gimple /space/rguenther/tramp3d/trunk/gcc/match.pd \
> tmp-gimple-match.c
GIMPLE decision tree has 696 leafs, maximum depth 10 and a total number of
2786 nodes
build/genm
1 - 100 of 150 matches
Mail list logo
