On Tue, Oct 21, 2014 at 10:48 AM, Hale Wang wrote:
> Hi,
>
> This patch is used to tune the gcc for Cortex-M7.
>
> The performance of Dhrystone can be improved by 1%.
> The performance of Coremark can be improved by 2.3%.
>
> Patch also attached for convenience.
>
> Is it ok for trunk?
>
> Thanks
On Tue, Oct 21, 2014 at 10:18 AM, Terry Guo wrote:
> Hi There,
>
> This is the first patch to enable GCC generate UAL assembly code for Thumb1
> target. This new option enables user to specify which syntax is used in
> their inline assembly code. If the inline assembly code uses UAL format,
> the
On Tue, Oct 21, 2014 at 12:19 PM, Terry Guo wrote:
> Hi there,
>
> Attached patch intends to enable GCC generate UAL format code for Thumb1
> target. Tested with regression test and no regressions. Is it OK to trunk?
This is OK - Please don't commit it until we have sorted out patch
1/2 with the
On 11/03/2014 05:22 PM, Rainer Orth wrote:
> 2014-10-22 Rainer Orth
>
> libobjc:
> * thr.c (_XOPEN_SOURCE): Define as 600.
>
> libiberty:
> * sigsetmask.c (_POSIX_SOURCE): Remove.
>
> libgomp:
> * config/posix/lock.c (_XOPEN_SOURCE) Define as 600.
Ok.
r~
On Thu, Oct 23, 2014 at 11:30 AM, Renlin Li wrote:
>> Are you sure that the ACLE documents this with trailing underscores ?
>> The copy that I have doesn't.
>
>
> You are right, it's my incaution. I have double checked, the macro should be
> __ARM_FEATURE_IDIV.
>
> Could you please do a obvious fi
On Mon, Nov 3, 2014 at 10:00 PM, Uros Bizjak wrote:
> Following patch fixes PR 63538, where the data in the large data
> section was accessed through 32bit address. The patch unifies places
> where large data sections are determined and passes all declarations
> to ix86_in_large_data_p only.
>
>
.. thanks a lot Jon! (after all this parallel mode is still useful for
something ;)
Paolo.
On 25 September 2014 04:45, Michael Collison
wrote:
> On certain patterns in atomics.md the constraint 'n' is used in combination
> with the predicate atomic_op_operand. The constraint is too general and
> allows constants that are disallowed by the predicate. This causes an ICE In
> final_scan_in
On 25 September 2014 14:37, James Greenhalgh wrote:
>
> Hi,
>
> This patch fixes an annoying gotcha when adding new cores or piepline
> models in builds for AArch64. The "generic_sched" attribute also needs
> updating in addition to aarch64-tune.md.
>
> I see no good reason for this, we can genera
On 25 September 2014 17:32, Jiong Wang wrote:
>
> patch updated, please review.
>
>
> 2014-09-25 Jiong Wang
> 2014-09-25 Wilco Dijkstra
>
> gcc/
> PR target/63293
> * config/aarch64/aarch64.c (aarch64_expand_epiloue): Add barriers before
> stack adjustment.
OK /Marcus
On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo wrote:
> Hi,
>
> As discussed in the PR, this adds two new SH built-in functions
> __builtin_sh_get_fpscr __builtin_sh_set_fpscr. Tested on r216173 with
>
> make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m4/-ml,-m4/-mb}"
>
> and no new failur
Phew,
This one slipped through the cracks. Ping?
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01981.html
Thanks,
Kyrill
On 23/09/14 16:25, Kyrill Tkachov wrote:
On 23/09/14 16:07, Kyrill Tkachov wrote:
Hi all,
Some intrinsics had the wrong name (inconsistent with the NEON
intrinsics spec).
On 01/10/14 09:00, Kugan wrote:
On 01/10/14 01:00, Jiong Wang wrote:
On 27/09/14 22:20, Kugan wrote:
On 23/09/14 01:58, Jiong Wang wrote:
On 22/09/14 16:43, Kugan wrote:
AArch64 has the same issue ARM had where the LR register was not
used in
leaf functions. This was reported in
https://gcc
On Fri, Oct 24, 2014 at 1:01 PM, Alan Lawrence wrote:
> Similarly to last patch.
>
> Tested, in combination with previous patch:
> bootstrap on arm-none-linux-gnueabihf
> cross-tested check-gcc on arm-none-eabi.
>
> gcc/ChangeLog:
>
> config/arm/neon.md (reduc_smin_ *2): Rename to...
>
On 29 October 2014 10:34, Tejas Belagod wrote:
> On 10/10/14 15:48, David Sherwood wrote:
>> I have a fix (originally written by Tejas Belagod) for the following bug:
In which case you should add his name along side yours in the ChangeLog entry...
>> ChangeLog:
>>
>> gcc/:
>> 2014-10-
On 10 October 2014 16:19, Alan Hayward wrote:
> This patch is dependant on "[AArch64] [BE] [1/2] Make large opaque integer
> modes endianness-safe.”
>
> It fixes up movoi/ci/xi for Big Endian, so that we end up with the lsb of
> a big-endian integer to be in the low byte of the highest-numbered
>
On Tue, Nov 4, 2014 at 1:00 AM, Ian Taylor wrote:
> On Mon, Nov 3, 2014 at 9:02 AM, Dominik Vogt wrote:
>> On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
>>> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt
>>> wrote:
>>> > I'm not quite sure about the best approach. The attempt to
>
On 13 October 2014 11:01, David Sherwood wrote:
> Hi,
>
> This is the second patch of the work to fix:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>
> and removes the CANNOT_CHANGE_MODE_CLASS macro, which now permits subregs of
> vector registers to work correctly on aarch64_be.
>
> NOT
2014-11-04 Richard Biener
Merge from trunk r216941 through r217074.
Brings back next merge piece.
Hi!
On Fri, 31 Oct 2014 16:35:27 -0700, Cesar Philippidis
wrote:
> This patch also resolves an issue when reductions are preformed on the
> host, i.e. ACC_DEVICE_TYPE=host.
Additional cleanup has now been possible; r217078:
commit a10c5e14ec563fffa45d24366f95f8cba62af4fd
Author: tschwinge
Dat
On 31 October 2014 15:10, James Greenhalgh wrote:
> While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
> unused, so clean that up too.
That's not a clean-up. This pertains to PR 39350.
Which, incidentally, this hookization completely ignores, entrenching
the conflation of
move e
On 03/11/14 18:36, Mike Stump wrote:
On Oct 30, 2014, at 10:25 AM, Andrew Stubbs wrote:
Many of the tests in gcc.target/powerpc specify an explicit -mcpu option with
dg-options. This is a problem for multilib configurations that use -mcpu in
their definition
OK to commit?
Given the discu
Hi!
On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
> No matter whether it's C, C++, or Fortran source code, the libgomp
> testsuite always uses (for build-tree testing) gcc/xgcc, or (for
> installed testing) GCC_UNDER_TEST. It doesn't make use of
> GXX_UNDER_TEST, GFORTRAN_UNDER_TEST. To support t
See commit comment and ChangeLog for details.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
ChangeLog
2014-11-04 Dominik Vogt
* libgo/go/syscall/libcall_linux_s390.go: New file for s390 support.
* libgo/go/syscall/syscall_linux_s390.go: Ditto.
* libgo/go/syscall
This is the second set of patches to support s390[x] with Gccgo,
containing mostly architecture dependent parts that affect the
following directories:
gcc/testsuite/go.test (golang)
gcc/testsuite/go.test/go-test.exp (Gcc?)
libgo (Gcc?)
libgo/go
See commit comment and ChangeLog for details.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
ChangeLog
2014-11-04 Dominik Vogt
* libgo/go/sync/atomic/atomic_test.go: Use LoadInt32() to access sync
variables.
* libgo/go/math/all_test.go (tolerance): Fix bug in cal
See commit comment and ChangeLog for details.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
2014-11-04 Dominik Vogt
* go.test/go-test.exp: Add handling of "// +build".
>From 12f9861253b1c9b8758b5356daedad98bfc044c4 Mon Sep 17 00:00:00 2001
From: Dominik
See commit comment and ChangeLog for details.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
2014-11-04 Dominik Vogt
* go.test/test/ken/cplx2.go:
Fix s390 test failures.
2014-11-04 Dominik Vogt
* go.test/test/nilptr_s390.go: Port nilp
On 4 Nov 2014, at 11:50, Jan-Benedict Glaw wrote:
> On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo wrote:
>> Hi,
>>
>> As discussed in the PR, this adds two new SH built-in functions
>> __builtin_sh_get_fpscr __builtin_sh_set_fpscr. Tested on r216173 with
>>
>> make -k check RUNTESTFLAGS=
ping!
On Tue, Oct 28, 2014 at 11:19 AM, Kito Cheng wrote:
> Hi all:
>
> This patch update `Bit operations` section in libgcc.text, most bit
> operation function is take an unsigned integer instead of signed
> integer in libgcc/libgcc2.c [1], and it seem more make sense :)
>
> ChangeLog
> 2014-10-
On 11/03/2014 11:27 PM, Jeff Law wrote:
On 11/01/14 05:57, Bernd Schmidt wrote:
This is not against current trunk; it applies to gomp-4_0-branch where
it is one of the necessary parts to make offloading x86->nvptx work. The
issue is that the LTO file format depends on the machine_modes enum, it
On Tue, 2014-11-04 13:21:24 +0100, Oleg Endo wrote:
> On 4 Nov 2014, at 11:50, Jan-Benedict Glaw wrote:
> >
> > 2014-11-04 Jan-Benedict Glaw
> >
> >* config/sh/sh.c (emit_fpu_switch): Drop unused automatic variable.
[...]
> > This should fix it, ok for mainline?
>
> Yes, OK. Thanks for
On Mon, Nov 3, 2014 at 4:50 PM, Jakub Jelinek wrote:
> On Mon, Nov 03, 2014 at 04:46:43PM +0100, Richard Biener wrote:
>> On Mon, Nov 3, 2014 at 2:01 PM, Jakub Jelinek wrote:
>> > On Mon, Nov 03, 2014 at 06:26:12PM +0530, Prathamesh Kulkarni wrote:
>> >> --- gcc/match-comparison.pd (revision 21
Hi again,
On 11/04/2014 05:34 AM, Jonathan Wakely wrote:
On 04/11/14 03:41 +, Jonathan Wakely wrote:
On 03/11/14 22:07 +, Jonathan Wakely wrote:
On 3 November 2014 17:51, Paolo Carlini
wrote:
.. other than the above issue, I see a segmentation fault for:
performance/ext/pb_ds/mul
On 03/11/14 17:58, Joseph Myers wrote:
On Mon, 3 Nov 2014, Tejas Belagod wrote:
If I mention in a couple of sentences the level of ACLE support there is in
GCC currently, this section will need to be updated every time there is an
improvement in ACLE support - I guess we'll just have to remembe
.. and also:
performance/ext/pb_ds/priority_queue_text_pop_mem.cc
.../libstdc++-v3/scripts/check_performance: line 41: 16905 Segmentation
fault ./$EXE_NAME &>tmp.$FILE_NAME
Paolo.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11/04/2014 10:55 AM, schrieb Paolo Carlini:
> .. thanks a lot Jon! (after all this parallel mode is still useful
> for something ;)
>
> Paolo.
Sorry for the terse message. I'm under heavy workload at the moment.
But AFAIS now everything looks good
On Tue, Nov 04, 2014 at 12:07:56PM +, Joern Rennecke wrote:
> On 31 October 2014 15:10, James Greenhalgh wrote:
>
> > While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
> > unused, so clean that up too.
>
> That's not a clean-up. This pertains to PR 39350.
Well, it is a cle
On Mon, Nov 3, 2014 at 1:56 PM, Prathamesh Kulkarni
wrote:
> (had sent it earlier by private mail).
>
> The attached patch supports operator-list and it's use in for.
> For now, operator-list is rejected in expression.
Ok.
> This patch also allows user-defined operator to be used as operator-lis
The ptx port by its nature is lacking features that are expected on
"normal" machines, such as alloca and indirect jumps. We have a subset
of the C library which contains functions that can be implemented on the
target (excluding things like file I/O other than printf which is a ptx
builtin).
On the match-and-simplify branch we expose an issue in shorten_compare
which happily transforms (double) float-var != (double) dfp-float-var
to (float) float-var != (float) dfp-float-var which is wrong
and causes
FAIL: c-c++-common/dfp/convert-bfp-12.c -std=c++11 execution test
FAIL: c-c++-commo
On 4 November 2014 13:13, Paolo Carlini wrote:
> Hi again,
>
>
> On 11/04/2014 05:34 AM, Jonathan Wakely wrote:
>>
>> On 04/11/14 03:41 +, Jonathan Wakely wrote:
>>>
>>> On 03/11/14 22:07 +, Jonathan Wakely wrote:
On 3 November 2014 17:51, Paolo Carlini
wrote:
>
> .
On Tue, 4 Nov 2014, Richard Biener wrote:
>
> On the match-and-simplify branch we expose an issue in shorten_compare
> which happily transforms (double) float-var != (double) dfp-float-var
> to (float) float-var != (float) dfp-float-var which is wrong
> and causes
>
> FAIL: c-c++-common/dfp/conv
On 10/20/2014 04:19 PM, Bernd Schmidt wrote:
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
Looking back through all the mails it turns out this one wasn't approved
yet. Ping?
Bernd
Hi,
since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
because although the tested-for devirtualization does happen, it is
probably being done earlier and the string we are trying to match is
not emitted. But the important thing is that the tested
devirtualization takes place.
Pa
On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote:
> The ptx port by its nature is lacking features that are expected on
> "normal" machines, such as alloca and indirect jumps. We have a subset
> of the C library which contains functions that can be implemented on the
> target (exclu
On 11/04/2014 04:32 PM, Bernd Schmidt wrote:
> On 10/20/2014 04:19 PM, Bernd Schmidt wrote:
>> ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
>> defined. Add a sorry.
>
> Looking back through all the mails it turns out this one wasn't approved yet.
> Ping?
Ok.
r~
Hi,
On 11/04/2014 04:32 PM, Jonathan Wakely wrote:
Not a big deal of course, but unfortunately today I'm seeing *two* segfaults
for pb_ds:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
.../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation
fault ./$EXE_NAME &>tmp
On Tue, Nov 4, 2014 at 4:37 PM, Martin Jambor wrote:
> Hi,
>
> since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
> because although the tested-for devirtualization does happen, it is
> probably being done earlier and the string we are trying to match is
> not emitted. But the imp
Hi,
On 11/04/2014 04:37 PM, Martin Jambor wrote:
Hi,
since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
because although the tested-for devirtualization does happen, it is
probably being done earlier and the string we are trying to match is
not emitted. But the important thing
On 04/11/14 15:51, Paolo Carlini wrote:
Hi,
On 11/04/2014 04:37 PM, Martin Jambor wrote:
Hi,
since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
because although the tested-for devirtualization does happen, it is
probably being done earlier and the string we are trying to match
On Tue, Nov 04, 2014 at 04:47:18PM +0100, Richard Biener wrote:
> On Tue, Nov 4, 2014 at 4:37 PM, Martin Jambor wrote:
> > Hi,
> >
> > since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
> > because although the tested-for devirtualization does happen, it is
> > probably being done
On 11/04/2014 04:41 PM, Steve Kargl wrote:
It is unclear to me from reading the diff whether this patch
cause gfortran on ptx to knowingly violate the fortran standard.
If the answer is "yes, this patch causes gfortran on ptx to
violate the standard", then the patch is IMHO unacceptable.
I don'
> Comments on the approach, do the Fortran maintainers have a preference how
> this should look? The whole thing is good enough to substantially reduce the
> number of failures when trying to run the Fortran testsuites on nvptx
> (although many remain).
I’m afraid I don’t really see the point.
On Tue, 4 Nov 2014, Richard Biener wrote:
> c-family/
> * c-common.c (shorten_compare): Do not shorten mixed
> DFP and non-DFP compares.
OK. I think it's also wrong for get_narrower to strip conversions between
binary and decimal floating point at all, as all such conversions
On Tue, 4 Nov 2014, Joseph Myers wrote:
> On Tue, 4 Nov 2014, Richard Biener wrote:
>
> > c-family/
> > * c-common.c (shorten_compare): Do not shorten mixed
> > DFP and non-DFP compares.
>
> OK. I think it's also wrong for get_narrower to strip conversions between
> binary and deci
On 11/04/2014 04:59 PM, FX wrote:
Comments on the approach, do the Fortran maintainers have a
preference how this should look? The whole thing is good enough to
substantially reduce the number of failures when trying to run the
Fortran testsuites on nvptx (although many remain).
I’m afraid I do
On Tue, Nov 04, 2014 at 07:41:42AM -0800, Steve Kargl wrote:
> On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote:
> > The ptx port by its nature is lacking features that are expected on
> > "normal" machines, such as alloca and indirect jumps. We have a subset
> > of the C library whi
> The point is, if the target can implement just a subset of the Fortran (or
> C or C++) standards, then ideally if you use anything that is not supported
> would just cause always host fallback, the code will still work, but will
> not be offloaded. So even supporting a subset of the standard is
On Mon, 2014-11-03 at 14:27 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > This file declares the gcc::jit::recording internal API, so that
> > libgccjit.c can record the calls that are made to the public API, for
> > later playback by the dummy frontend.
> >
> > gcc/jit/
> >
On Tue, Nov 04, 2014 at 05:15:52PM +0100, FX wrote:
> > The point is, if the target can implement just a subset of the Fortran (or
> > C or C++) standards, then ideally if you use anything that is not supported
> > would just cause always host fallback, the code will still work, but will
> > not be
On Tue, Nov 4, 2014 at 4:57 PM, Martin Jambor wrote:
> On Tue, Nov 04, 2014 at 04:47:18PM +0100, Richard Biener wrote:
>> On Tue, Nov 4, 2014 at 4:37 PM, Martin Jambor wrote:
>> > Hi,
>> >
>> > since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
>> > because although the tested-for
On 4 November 2014 14:24, James Greenhalgh wrote:
> On Tue, Nov 04, 2014 at 12:07:56PM +, Joern Rennecke wrote:
>> On 31 October 2014 15:10, James Greenhalgh wrote:
>>
>> > While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
>> > unused, so clean that up too.
>>
>> That's not a
java/builtins.c needs to call can_compare_and_swap, which happens to be
provided via optabs.h.
As a result, we see the following in java/builtins.c:
/* FIXME: All these headers are necessary for sync_compare_and_swap.
Front ends should never have to look at that. */
#include "rtl.h"
#include
On Mon, 2014-11-03 at 15:03 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > Implementation of the gcc::jit::recording internal API, so that
> > libgccjit.c can record the calls that are made to the public API, for
> > later playback by the dummy frontend.
> >
> > gcc/jit/
> >
On 11/04/2014 04:46 PM, Paolo Carlini wrote:
Hi,
On 11/04/2014 04:32 PM, Jonathan Wakely wrote:
Not a big deal of course, but unfortunately today I'm seeing *two*
segfaults
for pb_ds:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
.../libstdc++-v3/scripts/check_performance: line 41:
On Mon, 2014-11-03 at 14:04 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > These files implement support for builtins, for the
> >gcc_jit_context_get_builtin_function
> > API entrypoint.
> >
> > Only a subset of builtins are currently supported, based on those
> > that I n
On 10/28/2014 03:56 PM, Bernd Schmidt wrote:
> +nvptx_ptx_type_from_mode (enum machine_mode mode, bool promote)
> +{
> + switch (mode)
> +{
> +case BLKmode:
> + return ".b8";
> +case BImode:
> + return ".pred";
> +case QImode:
> + if (promote)
> + return ".u32";
On 11/04/2014 05:48 PM, Richard Henderson wrote:
On 10/28/2014 03:56 PM, Bernd Schmidt wrote:
+nvptx_ptx_type_from_mode (enum machine_mode mode, bool promote)
+{
+ switch (mode)
+{
+case BLKmode:
+ return ".b8";
+case BImode:
+ return ".pred";
+case QImode:
+ if (
On 4 November 2014 16:34, Paolo Carlini wrote:
> Ah! The testsuite_allocator.h fix of yours is still unapplied, didn't know
> that, sorry ;)
My bad - I thought I'd committed it! Done now.
On Mon, 2014-11-03 at 13:32 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > This file implements the entrypoints of the library's public API.
> >
> > It performs error-checking at this boundary, before calling into the
> > jit-recording.h internal API.
> >
> > gcc/jit/
> >
On Tue, Nov 04, 2014 at 04:54:54PM +0100, Bernd Schmidt wrote:
> On 11/04/2014 04:41 PM, Steve Kargl wrote:
> > It is unclear to me from reading the diff whether this patch
> > cause gfortran on ptx to knowingly violate the fortran standard.
> > If the answer is "yes, this patch causes gfortran on
On 2014.11.03 at 08:47 -0600, Jason Merrill wrote:
> On 11/03/2014 05:27 AM, Markus Trippelsdorf wrote:
> > BTW both EDG and clang reject g++.dg/template/spec17.C:
> >
> > namespace io {
> >template int foo();
> > }
> > using namespace io;
> > template<> int foo();
> >
> > But I think it is a
> See https://gcc.gnu.org/wiki/Offloading and kyukhin/gomp4-offload and
> branches/gomp-4_0-branch branches. Both are in the process of being merged
> into trunk these days.
Thanks for the link, I’ll look into it.
I suppose then it makes sense to provide partial libgfortran support, assuming
som
On 11/04/14 09:11, Jakub Jelinek wrote:
On Tue, Nov 04, 2014 at 07:41:42AM -0800, Steve Kargl wrote:
On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote:
The ptx port by its nature is lacking features that are expected on
"normal" machines, such as alloca and indirect jumps. We have a
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
> + bool
> + default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
> + {
> + return can_compare_and_swap_p (mode, allow_libcall);
> + }
This is silly. I think the problem you point out can be better fixed by moving
the can_compare_
On Tue, Nov 04, 2014 at 10:20:53AM -0700, Jeff Law wrote:
> On 11/04/14 09:11, Jakub Jelinek wrote:
> > On Tue, Nov 04, 2014 at 07:41:42AM -0800, Steve Kargl wrote:
> >> On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote:
> >>> The ptx port by its nature is lacking features that are expe
The Go language was tweaked to permit logical operators to return an
untyped boolean value, which means that code like
type myBool bool
var b myBool = a < b || c < d
is now permitted (previously the || operator would return the named
type "bool" and an explicit conversion was required for t
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return can_compare_and_swap_p (mode, allow_libcall);
+ }
This is silly. I think the problem you point out can b
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
> On 11/04/2014 12:25 PM, Richard Henderson wrote:
>> On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
>>> + bool
>>> + default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
>>> + {
>>> + return can_compare_and_swap_p (mode, allow_libcal
On 11/04/14 08:54, Bernd Schmidt wrote:
Note that the intention is not to support Fortran (or any other
language) directly targetting ptx code. The only way it's supposed to be
used is as an accelerator for OpenACC offloading.
Right. To reiterate for everyone, offloading is the goal of the nvptx
Hello!
2014-11-04 Uros Bizjak
* g++.dg/ipa/devirt-44.C (dg-options): Remove -fdump-tree-optimized.
* g++.dg/ipa/devirt-45.C (dg-options): Ditto.
* g++.dg/tree-prof/morefunc.C (dg-final-use): Cleanup profile ipa dump.
* g++.dg/tree-prof/reorder.C (dg-final-use): Ditto.
* g++
On Tue, Nov 4, 2014 at 12:20 PM, Uros Bizjak wrote:
>>> Bitfields can really not be represented properly in Go (think about
>>> constructs like "struct { int : 1; int bf : 1; }"), I'd rather not
>>> try to represent them in a predictable way. The patched code may
>>> or may not give them a name,
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return can_compa
On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>
> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>> No matter whether it's C, C++, or Fortran source code, the libgomp
>> testsuite always uses (for build-tree testing) gcc/xgcc, or (for
>> installed testing) GCC_UNDER_TEST. It doesn't make use
On Mon, Nov 03, 2014 at 04:35:00PM +0100, Jakub Jelinek wrote:
> Well, in theory you could just script removing them one by one and just
> make sanopt.o after each step to see if the header is or is not needed,
> perhaps with some manual tweeks.
I pruned those headers some more.
> Perhaps in pre
On Nov 4 2014, Jeff Law wrote:
On 11/04/14 09:11, Jakub Jelinek wrote:
The point is, if the target can implement just a subset of the Fortran
(or C or C++) standards, then ideally if you use anything that is not
supported would just cause always host fallback, the code will still
work, but w
On Tue, Nov 4, 2014 at 10:46 AM, Uros Bizjak wrote:
>> Following patch fixes PR 63538, where the data in the large data
>> section was accessed through 32bit address. The patch unifies places
>> where large data sections are determined and passes all declarations
>> to ix86_in_large_data_p only.
On Tue, Nov 4, 2014 at 10:47 AM, Uros Bizjak wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Uros Bizjak wrote:
>
>>> Following patch fixes PR 63538, where the data in the large data
>>> section was accessed through 32bit address. The patch unifies places
>>> where large data sections are determined an
On Tue, Nov 4, 2014 at 1:35 PM, Bernd Schmidt wrote:
>> Not sure how to deal with this any further out than the immediate term
>> than using a hack like this. Though I'd prefer to avoid the #ifdef as it
>> seems to me this shouldn't be baked in at build/configure time.
>
>
> Yeah, I'm not expecti
On Tue, Nov 04, 2014 at 07:36:26PM +0100, Marek Polacek wrote:
> + FOR_EACH_VEC_ELT_REVERSE (v, i, g)
> + {
> + /* Remove statements for BBs that have been
> + already processed. */
> + sanopt_info *si = (sanopt
On November 4, 2014 7:30:18 PM CET, Andrew MacLeod wrote:
>On 11/04/2014 12:57 PM, Richard Henderson wrote:
>> On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
>>> On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
> + bool
> + default_can_comp
I forgot to remove two unused variables.
Applying to trunk as obvious.
2014-11-04 Marek Polacek
* sanopt.c (sanopt_optimize_walker): Remove unused variables.
diff --git gcc/sanopt.c gcc/sanopt.c
index f1d51d1..4483ff7 100644
--- gcc/sanopt.c
+++ gcc/sanopt.c
@@ -117,9 +117,6 @@ sanop
On 11/04/2014 02:53 PM, Richard Biener wrote:
On November 4, 2014 7:30:18 PM CET, Andrew MacLeod wrote:
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote
Ping?
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01808.html
On Sat, 18 Oct 2014, Marc Glisse wrote:
Hello,
this time, +-* for 128 bit integer vectors. I am using an unsigned type so
the compiler knows that we expect wrapping. I don't know why Intel's
description of mullo insists that the
On 11/03/14 16:07, Bernd Schmidt wrote:
On 11/03/2014 11:22 PM, Jeff Law wrote:
On 11/01/14 05:47, Bernd Schmidt wrote:
This is one of the patches required to make offloading via the LTO path
work when the machines involved differ.
x86 requires bigger alignments for some types than nvptx does,
On 11/04/2014 10:01 PM, Jeff Law wrote:
Communication between host and GPU is all done via some form of memcpy,
so I wouldn't expect this to be a problem.
They still need to agree on the layout of the structure.
That is guaranteed by the fact that structure layouts are fixed before
we write o
On 11/04/14 09:12, David Malcolm wrote:
So give the complexities in interfacing with the guts of GCC, would it
make sense to expose the validate method?
Most of the error-checking in the API happens in the API calls in
libgccjit.c, testing that the individual pieces are sane.
The validate meth
On 11/04/14 09:24, David Malcolm wrote:
So presumably no multi-way branches yet? Might be better to build the
API in such a way that it handles multi-way branches from the get-go
rather than retrofitting later. Your call.
This is an internal API. If the external API needs to support building
On 11/04/14 09:57, David Malcolm wrote:
+#define IS_ASCII_DIGIT(CHAR) \
+ ((CHAR) >= '0' && (CHAR) <='9')
+
+#define IS_ASCII_ALNUM(CHAR) \
+ (IS_ASCII_ALPHA (CHAR) || IS_ASCII_DIGIT (CHAR))
Can't we rely on the C library to give us equivalents?
I've been burned in the past by the C library
1 - 100 of 126 matches
Mail list logo
