[ was: Re: [committed 1a/4] (Partial) OpenMP 5.0 support for GCC 9 (gcc
middle-end) ]
On 08-11-18 18:24, Jakub Jelinek wrote:
> * omp-builtins.def (BUILT_IN_GOMP_TASKWAIT_DEPEND,
> BUILT_IN_GOMP_LOOP_NONMONOTONIC_RUNTIME_START,
> BUILT_IN_GOMP_LOOP_MAYBE_NONMONOTONIC_RUNTIME_STAR
[ was: Re: [committed 2/4] (Partial) OpenMP 5.0 support for GCC 9
(runtime library changes) ]
On 08-11-18 18:18, Jakub Jelinek wrote:
> Hi!
>
> This is the libgomp/ except libgomp/testsuite/ part of the gomp-5_0-branch
> merge to trunk I've just committed.
>
> 2018-11-08 Jakub Jelinek
>
>
On Tue, Dec 11, 2018 at 06:02:12PM -0500, Jason Merrill wrote:
> On 12/11/18 4:38 PM, Jakub Jelinek wrote:
> > On Tue, Dec 11, 2018 at 03:35:39PM -0500, Marek Polacek wrote:
> > > > tree
> > > > -maybe_constant_value (tree t, tree decl)
> > > > +maybe_constant_value (tree t, tree decl, bool prete
On Wed, Dec 12, 2018 at 08:43:41AM +0100, Rasmus Villemoes wrote:
> diff --git a/libgcc/config/rs6000/tramp.S b/libgcc/config/rs6000/tramp.S
> index 637f4510146..a9f0f3826dc 100644
> --- a/libgcc/config/rs6000/tramp.S
> +++ b/libgcc/config/rs6000/tramp.S
> @@ -114,11 +114,10 @@ FUNC_START(__trampol
On Wed, Dec 12, 2018 at 09:25:06AM +0100, Tom de Vries wrote:
> [openmp] Fix openmp 5.0 builtin function types
>
> Fix some openmp 5.0 builtin functions to match the type used in the
> implementation of those functions.
>
> This fixes some libgomp testsuite failures for x86_64 with nvptx accelera
On Wed, Dec 12, 2018 at 09:29:36AM +0100, Tom de Vries wrote:
> > This is the libgomp/ except libgomp/testsuite/ part of the gomp-5_0-branch
> > merge to trunk I've just committed.
> >
> > 2018-11-08 Jakub Jelinek
> >
> > * affinity.c (gomp_display_affinity_place): New function.
> > *
On Tue, 11 Dec 2018 at 16:52, Richard Sandiford
wrote:
>
> Dimitar Dimitrov writes:
> > On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
> >> Dimitar Dimitrov writes:
> >> > I have tested this fix on x86_64 host, and found no regression in the C
> >> > and C++ testsuites.
Hi Uros and other reviewers,
I'd like to split the work into 2 parts:
1) Basic processor enabling.
2) Processor type dynamic check.
Let's use a separate patch to implement the part 2.
The part 1 is implemented by attached patch.
Is it ok for trunk?
Wei
gcc/
* common/config/i386/i386-commo
On Wed, 12 Dec 2018 at 10:42, Christophe Lyon
wrote:
>
> On Tue, 11 Dec 2018 at 16:52, Richard Sandiford
> wrote:
> >
> > Dimitar Dimitrov writes:
> > > On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
> > >> Dimitar Dimitrov writes:
> > >> > I have tested this fix on x8
On 12-12-18 10:27, Jakub Jelinek wrote:
> On Wed, Dec 12, 2018 at 09:25:06AM +0100, Tom de Vries wrote:
>> [openmp] Fix openmp 5.0 builtin function types
>>
>> Fix some openmp 5.0 builtin functions to match the type used in the
>> implementation of those functions.
>>
>> This fixes some libgomp tes
Hi Christophe,
That PR was about a bug occuring when sp was clobbered so if it cannot
be clobbered anymore the whole commit (r242693) can be removed. Let me
check the original code that lead to the PR why it's clobbering sp
though.
Best regards,
Thomas
On Wed, 12 Dec 2018 at 09:43, Christophe Ly
On Wed, Dec 12, 2018 at 11:22:22AM +0100, Tom de Vries wrote:
> .extern .func GOMP_parallel_loop_nonmonotonic_runtime (.param .u64
> %in_ar0, .param .u64 %in_ar1, .param .u32 %in_ar2, .param .u64 %in_ar3,
> .param .u64 %in_ar4, .param .u64 %in_ar5, .param .u64 %in_ar6, .param
> .u32 %in_ar7);
>
>
On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote:
>
> On 12/11/18 1:44 AM, Richard Biener wrote:
> > On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool
> > wrote:
> >>
> >> On Mon, Dec 10, 2018 at 06:25:31PM +, Andrew Jenner wrote:
> >>> Sorry for the slow response on this, I was on vacation la
On 12-12-18 10:36, Jakub Jelinek wrote:
> On Wed, Dec 12, 2018 at 09:29:36AM +0100, Tom de Vries wrote:
>>> This is the libgomp/ except libgomp/testsuite/ part of the gomp-5_0-branch
>>> merge to trunk I've just committed.
>>>
>>> 2018-11-08 Jakub Jelinek
>>>
>>> * affinity.c (gomp_display_a
The following improves x264 vectorization by avoiding peeling for gaps
noticing that when the upper half of a vector is unused we can
load the lower part only (and fill the upper half with zeros - this
is what x86 does automatically, GIMPLE doesn't allow us to leave
the upper half undefined as RT
So my understanding is that the original code (CMSIS library) used to
clobber sp because the asm statement was actually changing the sp.
That in turn led GCC to try to save and restore sp which is not what
CMSIS was expecting to happen. Changing sp without clobber as done now
is probably the right
This breaks ia64:
In file included from ../../../libgomp/config/linux/wait.h:46,
from ../../../libgomp/config/linux/mutex.c:30:
../../../libgomp/config/linux/ia64/futex.h: In function 'gomp_mutex_lock_slow':
../../../libgomp/config/linux/ia64/futex.h:43:3: error: Stack Pointer reg
On 30/08/2018 13:24, Richard Sandiford wrote:
> Joey Ye writes:
>> Hi Bin & Richard,
>>
>> It is not as simple as keeping the assertion, which still fails even
>> with the change in reorg.c. The testing result is as following:
>>
>> I. With Bin's patch version 2 (removing the assertion in aarch64.
Hi Ian,
Sorry to bother you, but I have another libiberty demangler resource
exhaustion prevention patch to present. This one is for:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87241
Jonathan Wakely reported that __cxa_demanlge() was returning a -2
result, but I did not see this. Ins
Before delving into the code to make changes to handle the case when
passing a variable into transfer instead of a literal I revised the the
test cases. The results indicate to me that this patch as originally
intended is erroneous.
When a character literal is assigned to character variable e.
Steve Ellcey writes:
> On Fri, 2018-12-07 at 17:34 +, Richard Sandiford wrote:
>> > + (match_operand:TX 2 "register_operand" "w"))
>> > + (set (mem:TX (plus:P (match_dup 0)
>> > + (match_operand:P 5 "const_int_operand" "n")))
>> > + (match_operand:TX 3 "r
Hi Ian,
*sigh* 5 minutes after sending the patch for this PR, I realised that
I had made a mistake. I should have conditionalized the limit on the
number of supported qualifiers, so that the check is only made if we
have resource limits enabled. Like this:
Cheers
Nick
Index: libib
This adds the speculation barrier on SPARC-V9 in the form of membar #Sync.
2018-12-12 Eric Botcazou
PR target/86806
* config/sparc/sparc.md (unspecv): Add UNSPECV_SPECULATION_BARRIER.
(speculation_barrier): New instruction for V9.
--
Eric BotcazouIndex: config/sparc/
This is the third rework of the patchset previously posted on September
5th and November 16th. As before, the series contains the
non-OpenACC/OpenMP portions of a port to AMD GCN3 and GCN5 GPU
processors. It's sufficient to build single-threaded programs, with
vectorization in the usual way. C an
[This is new patch not included in the previously posted patch sets.]
This patch fixes an ICE building libgfortran/random.c.
The problem was an adddi3 instruction that had an eliminable frame pointer.
GCN adddi3 includes a match_scratch, which LRA substitutes with a REG, and
checks if it can be
[Already approved by Janne Blomqvist and Jeff Law. Included here for
completeness.]
This patch contains the GCN port of libgfortran. We use the minimal
configuration created for NVPTX. That's all that's required, besides the
target-independent bug fixes posted already.
2018-12-12 Andrew Stub
[Already approved by Jeff Law. Included here for completeness.]
This patch contains the GCN port of libgcc.
2018-12-12 Andrew Stubbs
Kwok Cheung Yeung
Julian Brown
Tom de Vries
libgcc/
* config.host: Recognize amdgcn*-*-amdhsa.
On Wed, Dec 12, 2018 at 11:37:23AM +, Mark Eggleston wrote:
> Before delving into the code to make changes to handle the case when passing
> a variable into transfer instead of a literal I revised the the test cases.
> The results indicate to me that this patch as originally intended is
> erron
[Already approved by Jeff Law. Included here for completeness.]
The GCN/HSA loader ignores the load address and uses a random location, so we
build all GCN binaries as PIE, by default.
This patch makes the necessary testsuite adjustments to make this work
correctly.
2018-12-12 Andrew Stubbs
[Already approved by Jeff Law. Included here for completeness, now with
config.sub removed.]
This patch contains the configuration adjustments needed to enable the GCN
back-end.
Since the previous v2 posting, the config.sub patch has be committed to
the upstream GNU config repository. However,
[Already approved by Jeff Law. Included here for completeness.]
The GCN toolchain must use the LLVM assembler and linker because there's no
binutils port. The LLVM tools do not have the same diagnostic style as
binutils, so the "blank line(s) in output" tests are inappropriate (and very
noisy).
[v2 was approved by Mike Stump. This version adds the documentation,
but is otherwise unchanged.]
There are a number of tests that fail because they assume that exceptions are
available, but GCN does not support them, yet.
This patch adds "dg-require-effective-target exceptions" in all the affe
This collection of miscellaneous patches configures the testsuite to run on AMD
GCN in a standalone (i.e. not offloading) configuration. It assumes you have
your Dejagnu set up to run binaries via the gcn-run tool.
Since the previous v2 posting, the sqrt_insn additional option mechanism
has been
On Thu, Dec 6, 2018 at 2:19 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> >> > The pass contains an awful lot of heuristics :/ Like last year
> >> > with the interchange pass I would suggest to rip most of it out
> >> > and first lay infrastructure with the cases you can positively
>
On 12/12/2018 11:52, Jakub Jelinek wrote:
What about:
integer(kind=2) :: a
a = -1
print *, transfer (1_2, 1_8), transfer (a, 1_8)
end
?
I assume you meant transfer (-1_2, 1_8), the result from gfortran is
65535 for both transfers.
I'm about to build the compiler with
memset (bu
Hi Andrew,
> [Already approved by Jeff Law. Included here for completeness.]
>
> The GCN toolchain must use the LLVM assembler and linker because there's no
> binutils port. The LLVM tools do not have the same diagnostic style as
> binutils, so the "blank line(s) in output" tests are inappropriat
Compilation of gcc.dg/pr85180.c and gcc.dg/pr87985.c times out after 5 minutes
for msp430 with -mlarge.
nonzero_bits1 (from rtlanal.c), recurses many times for each reg
because reg_nonzero_bits_for_combine (combine.c) never considers using
last_set_nonzero_bits for the given reg when the reg is P
On Wed, Dec 12, 2018 at 12:06:12PM +, Mark Eggleston wrote:
>
> On 12/12/2018 11:52, Jakub Jelinek wrote:
> > What about:
> >integer(kind=2) :: a
> >a = -1
> >print *, transfer (1_2, 1_8), transfer (a, 1_8)
> > end
> > ?
>
> I assume you meant transfer (-1_2, 1_8), the result from
Hello,
This test currently fails unexpectedly if GCC is configured with
--disable-gcov, because it requires -fprofile-arcs. This patch
fixes the issue by requiring profiling support in order to run
this test.
Tested with two compilers, one built with --disable-gcov, resulting
in the test reportin
Steve Ellcey writes:
> This is the modified version of the second of my Aarch64 SIMD ABI patches.
> While implementing this functionality I found I wanted
> targetm.simd_clone.adjust to be called when creating SIMD clone definitions
> and also when creating SIMD clone declarations. The current
>
On Wed, Dec 12, 2018 at 12:34:46PM +, Richard Sandiford wrote:
> > I considered comparing node->decl and cfun->decl to differentiate
> > between definitions and declarations instead of using a new argument
> > but having an argument seemed cleaner and clearer.
>
> Yeah, agreed.
I actually dis
On Wed, Dec 12, 2018 at 1:23 PM Joel Brobecker wrote:
>
> Hello,
>
> This test currently fails unexpectedly if GCC is configured with
> --disable-gcov, because it requires -fprofile-arcs. This patch
> fixes the issue by requiring profiling support in order to run
> this test.
>
> Tested with two c
Hi!
On Wed, 12 Dec 2018 10:36:17 +0100, Jakub Jelinek wrote:
> On Wed, Dec 12, 2018 at 09:29:36AM +0100, Tom de Vries wrote:
> > > This is the libgomp/ except libgomp/testsuite/ part of the gomp-5_0-branch
> > > merge to trunk I've just committed.
> > [libgomp, nvptx] Disable OMP_{DISPLAY_AFFINI
On 12-12-18 11:48, Tom de Vries wrote:
> On 12-12-18 10:36, Jakub Jelinek wrote:
>> On Wed, Dec 12, 2018 at 09:29:36AM +0100, Tom de Vries wrote:
This is the libgomp/ except libgomp/testsuite/ part of the gomp-5_0-branch
merge to trunk I've just committed.
2018-11-08 Jakub Jeli
On Wed, Dec 12, 2018 at 02:02:20PM +0100, Tom de Vries wrote:
> This RFC patch implements that approach for getpid and gethostname (I
> wonder though whether it's not possible to turn the corresponding
> configure tests into link tests, which could also fix this for nvptx).
>
> Another problem we'
On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
wrote:
>
> So my understanding is that the original code (CMSIS library) used to
> clobber sp because the asm statement was actually changing the sp.
> That in turn led GCC to try to save and restore sp which is not what
> CMSIS was expecting to happ
On Wed, Dec 12, 2018 at 09:17:01AM +0200, Ville Voutilainen wrote:
> On Tue, 11 Dec 2018 at 20:58, Marek Polacek wrote:
> >
> > On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> > > On 13 September 2018 at 20:41, Jason Merrill wrote:
> > > >> Okay. Do you think we should have a
On Tue, Dec 11, 2018 at 11:04 PM Tom de Vries wrote:
>
> [ Fixed ENOPATCH ]
>
> On 12-12-18 08:03, Tom de Vries wrote:
> > On 11-12-18 18:59, Ian Lance Taylor wrote:
> >> On Wed, Nov 28, 2018 at 4:50 AM Tom de Vries wrote:
> >>>
> >>> Add test-case that forces alloc.c functions to fail, and check
On Wed, Dec 12, 2018 at 3:40 AM Nick Clifton wrote:
>
> *sigh* 5 minutes after sending the patch for this PR, I realised that
>I had made a mistake. I should have conditionalized the limit on the
>number of supported qualifiers, so that the check is only made if we
>have resource li
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/lto/20100430-1_0.c: Add dg-require-profiling requirement.
> >
> > OK to push?
>
> OK.
Thank you Richard. Patch pushed to trunk (r267055).
--
Joel
On Sat, Dec 8, 2018 at 1:33 PM Ville Voutilainen
wrote:
> On Sat, 8 Dec 2018 at 20:05, Ville Voutilainen
> wrote:
>
> > > New compiler releases will usually include new warnings that require
> > > some code modification to accommodate. Why is this one particularly
> > > problematic?
> >
> > I do
Hi,
it seems we can easily improve the location of this - not so uncommon in
novice code - error to point to the 'static' keyword.
Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2018-12-12 Paolo Carlini
* decl.c (grokdeclarator): Fix location of error message abou
On 12/12/2018 12:06, Mark Eggleston wrote:
I'm about to build the compiler with
memset (buffer, 0x20, buffer_size);
instead of
memset (buffer, (flag_dec_pad_with_spaces ? 0x20 : 0x0), buffer_size);
and will check again, if necessary a padding variable can be used
instead initially set to
On Wed, 12 Dec 2018 at 14:19, Christophe Lyon
wrote:
>
> On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
> wrote:
> >
> > So my understanding is that the original code (CMSIS library) used to
> > clobber sp because the asm statement was actually changing the sp.
> > That in turn led GCC to try to
On Wed, 12 Dec 2018 at 16:52, Jason Merrill wrote:
> > For what it's worth, I find it unfortunate that this deprecation and its
> > resulting warnings end up
> > making the decision on whether a "rule of 5" must be followed; correct code
> > needs to be adjusted
> > to cope with a fairly stylis
[resending from the right address]
Hi Christophe,
Why not simply: "Clobber of unsupported" with an
accompanying change of the documentation to state the extra bit you
wanted to put in that error message? Perhaps even add a reference to
the section of the documentation in the error message.
Bes
Hello,
Ping for one of the changes last proposed here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
Submitted separately as an attempt to facilitate the review
process.
Got access to a linux box, so in addition to the Ada testing
we do on cross aarch64-vxworks7, bootstrapped and r
Ping for one of the changes last proposed here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
Submitted separately as an attempt to facilitate the review
process.
This one proposes the possibility for target (OS) configurations
to provide a SUBTARGET_OVERRIDE_OPTIONS macro as other C
Hi Olivier,
On 12/12/18 15:35, Olivier Hainque wrote:
Hello,
Ping for one of the changes last proposed here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
Submitted separately as an attempt to facilitate the review
process.
Got access to a linux box, so in addition to the Ada test
Hello,
Ping for part of the changes last proposed here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
Submitted separately as an attempt to facilitate the review
process.
This piece is the change of static chain from r18 to r11.
Regression testing with languages=all on an aarch64-l
Hello,
Ping for part of the changes last proposed here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
Submitted separately as an attempt to facilitate the review
process.
This piece is the change allowing target OS configurations
to state R18 as fixed, possible after the change of
Hi Kyrill,
> On 12 Dec 2018, at 16:43, Kyrill Tkachov wrote:
>
> This looks obvious to me tbh, I'd go ahead and commit it.
Great :-)
I have just sent separate updates on the other, less obvious
parts (SUBTARGET_OVERRIDE_OPTIONS, static chain change to r11,
and FIXED_R18).
Thanks!
>>*
Thank you, Matthias!
>From the log, essentially all the tests aborted. The only place the new
code can cause abort on all programs that I can think of is in the runtime
startup code, probestackmaps, which calls value_size, which aborts due to
an unhandled case. I haven't been able to try out on an
Hi Oliver,
+#define FIXED_R18 0
{ \
0, 0, 0, 0, 0, 0, 0, 0, /* R0 - R7 */ \
0, 0, 0, 0, 0, 0, 0, 0, /* R8 - R15 */ \
- 0, 0, 0, 0, 0, 0, 0, 0, /* R16 - R23 */ \
+ 0, 0, FIXED_R18, 0, 0, 0, 0, 0, /* R16 - R23 */
Ensure we don't try to instantiate __is_constructible_from,
because there are two partial specializations that are equally good
matches.
PR libstdc++/80762
* include/bits/fs_path.h (path::_Path): Use remove_cv_t and is_void.
* include/experimental/bits/fs_path.h (path::_Pa
Although filesystem::path::iterator is only a bidirectional iterator,
the underlying sequence has random access iterators (specifically, raw
pointers). This means std::distance and std::advance can be implemented
more efficiently than the generic versions which apply ++ and --
repeatedly.
* Claudiu Zissulescu [2018-12-11 12:23:34 +0200]:
> Forgot a class name, fix it.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.h (REG_CLASS_NAMES): Add SIBCALL_REGS.
Looks good,
Thanks,
Andrew
>
>
> ---
> gcc/config/arc/arc.h | 1 +
> 1 file changed, 1 insertion(+
* Claudiu Zissulescu [2018-12-11 12:23:35 +0200]:
> The blink is restored wrongly when using millicode and regular load
> instructions.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.c (arc_restore_callee_milli) Don't clobber off
> variable.
>
> testsuite/
> -
On Wed, 12 Dec 2018 at 14:19:27 EET Christophe Lyon wrote:
> On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
>
> wrote:
> > So my understanding is that the original code (CMSIS library) used to
> > clobber sp because the asm statement was actually changing the sp.
> > That in turn led GCC to try
On Wed, 12 Dec 2018 at 11:03:24 EET Christophe Lyon wrote:
> And just noticed it causes a failure to build GDB for x86_64:
> gdb-8.1-release/gdb/nat/linux-ptrace.c: In function 'void
> linux_ptrace_init_warnings()':
> gdb-8.1-release/gdb/nat/linux-ptrace.c:149:23: error: Stack Pointer
> register cl
Hi Wilco,
Thanks for your feedback on this !
> On 12 Dec 2018, at 17:11, Wilco Dijkstra wrote:
>
> Hi Oliver,
>
> +#define FIXED_R18 0
>
>{\
> 0, 0, 0, 0, 0, 0, 0, 0,/* R0 - R7 */\
> 0, 0, 0, 0, 0, 0, 0, 0,/* R8 - R15 */\
>
On Wed, Dec 12, 2018 at 10:48 AM Wei Xiao wrote:
>
> Hi Uros and other reviewers,
>
> I'd like to split the work into 2 parts:
> 1) Basic processor enabling.
> 2) Processor type dynamic check.
>
> Let's use a separate patch to implement the part 2.
> The part 1 is implemented by attached patch.
>
On Wed, Dec 12, 2018 at 09:42:05AM -0600, Olivier Hainque wrote:
> Ping for one of the changes last proposed here:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
>
> Submitted separately as an attempt to facilitate the review
> process.
>
> This one proposes the possibility for ta
> On 12 Dec 2018, at 17:57, James Greenhalgh wrote:
>> This one proposes the possibility for target (OS) configurations
>> to provide a SUBTARGET_OVERRIDE_OPTIONS macro as other CPU ports
>> do, needed by our aarch64-vxworks7 port to come.
>
> OK.
Great :-) Thanks for your review James !
On 12/12/2018 15:47, Olivier Hainque wrote:
> Hello,
>
> Ping for part of the changes last proposed here:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
>
> Submitted separately as an attempt to facilitate the review
> process.
>
> This piece is the change of static chain from r1
This new implementation has a smaller footprint than the previous
implementation, due to replacing std::vector<_Cmpt> with a custom pimpl
type that only needs a single pointer. The _M_type enumeration is also
combined with the pimpl type, by using a tagged pointer, reducing
sizeof(path) further st
On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote:
> On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote:
> > One way to deal with these problems is to create a fake simulator that
> > always returns success. That's what my tester does for the embedded
> > targets. That allows us to do r
On Tue, Dec 11, 2018 at 10:35:00AM -0500, David Malcolm wrote:
> On Mon, 2018-12-10 at 22:47 +, Segher Boessenkool wrote:
>
> [...]
>
> > diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> > index 121a91c..652e53c 100644
> > --- a/gcc/c/c-parser.c
> > +++ b/gcc/c/c-parser.c
> > @@ -6360,41 +6
On Tue, Dec 11, 2018 at 10:48:15AM -0500, David Malcolm wrote:
> For bonus points, these could offer fix-it hints, so that an IDE can
> offer to delete the duplicate qualifier token.
Yes it could. But have you ever seen this error, in a real program?
(It was an error before, just without a nice m
Hi Richard,
Thanks for your feedback on this !
> On 12 Dec 2018, at 18:21, Richard Earnshaw (lists)
> wrote:
>
> libffi is a separate project; so a patch for that needs to be sent to
> the libffi maintainers.
Oh, I hadn't realized that.
> However, that introduces an issue that that
> code
On Tue, Dec 11, 2018 at 10:31:02AM -0700, Martin Sebor wrote:
> >+{
> >+ error_at (loc, "duplicate asm qualifier %qE", token->value);
>
> We have been making an effort to quote keywords, identifiers,
> option names, and other such things in diagnostics. In
> the message above and
On 12/12/18 10:50 AM, Segher Boessenkool wrote:
On Tue, Dec 11, 2018 at 10:31:02AM -0700, Martin Sebor wrote:
+ {
+ error_at (loc, "duplicate asm qualifier %qE", token->value);
We have been making an effort to quote keywords, identifiers,
option names, and other such thin
On 2018-12-06 3:13 p.m., Michael Ploujnikov wrote:
> Thanks to Martin we now have a test that exercises (cp) cloning
> machinery during the WPA stage of LTO.
>
> Also, during debugging I found that print_all_lattices would trigger
> an assert if I tried to call it inside decide_whether_version_nod
Hi Jeff,
thank you. I fixed all the minor issues, but see below.
Am Montag, den 03.12.2018, 14:56 -0700 schrieb Jeff Law:
> On 11/4/18 1:48 PM, Uecker, Martin wrote:
> > Hi Joseph,
> >
> > here is a new version of this patch which adds a warning
> > for targets which do not support -fno-trampo
On Wed, 2018-12-12 at 13:41 +0100, Jakub Jelinek wrote:
> External Email
>
> ---
> ---
> On Wed, Dec 12, 2018 at 12:34:46PM +, Richard Sandiford wrote:
> > > I considered comparing node->decl and cfun->decl to differentiate
> > >
On Wed, 2018-12-12 at 11:39 +, Richard Sandiford wrote:
>
> Steve Ellcey writes:
> > On Fri, 2018-12-07 at 17:34 +, Richard Sandiford wrote:
> > > > + (match_operand:TX 2 "register_operand" "w"))
> > > > + (set (mem:TX (plus:P (match_dup 0)
> > > > + (match_o
On Wed, Dec 12, 2018 at 11:02:29AM -0700, Martin Sebor wrote:
> On 12/12/18 10:50 AM, Segher Boessenkool wrote:
> >On Tue, Dec 11, 2018 at 10:31:02AM -0700, Martin Sebor wrote:
> >>>+ {
> >>>+error_at (loc, "duplicate asm qualifier %qE", token->value);
> >>
> >>We have been making an e
Richard Biener writes:
> On Thu, Dec 6, 2018 at 2:19 PM Richard Sandiford
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and aarch64_be-elf.
>> Also repeated the performance testing (but haven't yet tried an
>> LTO variant; will do that over the weekend).
>
> Any results?
Sorry, I should've rem
Steve Ellcey writes:
> On Wed, 2018-12-12 at 11:39 +, Richard Sandiford wrote:
>>
>> Steve Ellcey writes:
>> > On Fri, 2018-12-07 at 17:34 +, Richard Sandiford wrote:
>> > > > + (match_operand:TX 2 "register_operand" "w"))
>> > > > + (set (mem:TX (plus:P (match_dup 0)
>> > >
Hi,
>> On 12 Dec 2018, at 18:21, Richard Earnshaw (lists)
>> wrote:
>
>> However, that introduces an issue that that
>> code is potentially used across multiple versions of gcc, with
>> potentially different choices of the static chain register. Hmm, this
>> might need some more careful though
The testcase uses REs like {(?n)\m_*bar[.$_]constprop[.$_]0:} to find
what functions are defined. But, this also matches lines like
.L.bar.constprop.0:
(which are used on powerpc64-linux).
The "(?n)" doesn't do anything here either. We should use "^" here
instead of just "\m".
Committing to trun
Libitm on POWER hardware looks for the "htm" bit in AT_HWCAP2 to determine
whether it can use HTM when executing code within __transaction_atomic
code blocks. However, on newer hardware and kernels, the "htm" bit is no
longer set and instead the "htm-no-suspend" bit is set, so we currently
don't u
Ping.
Peter
On 12/4/18 10:12 AM, Peter Bergner wrote:
> Hi Segher,
>
> We talked about replacing rs6000'c regno_or_subregno() with the generic
> reg_or_subregno() function from jump.c. I agree the geberic version is
> better because it has an assert that ensures we have a REG. There were
> al
On 12/7/18 11:38 AM, Peter Bergner wrote:
> On 12/4/18 4:53 PM, Segher Boessenkool wrote:
>>> Since I backported the earlier fix to GCC8, I'd like to backport this
>>> there too.
>>
>> Okay for there too.
>
> Great, I'll backport the changes and commit after regression testing.
> Thanks!
Backport
Am Mittwoch, den 12.12.2018, 18:53 + schrieb Wilco Dijkstra:
> Hi,
>
> > > On 12 Dec 2018,@18:21, Richard Earnshaw (lists)
>
> wrote:
>
> > > However, that introduces an issue that that
> > > code is potentially used across multiple versions of gcc, with
> > > potentially different choices
The new insn here (temporarily) illegally shares RTL. This fixes it.
Tested with an ARC cross, and regstrapped on powerpc64-linux {-m32,-m64}.
Is this okay for trunk?
Segher
2018-12-12 Segher Boessenkool
PR rtl-optimization/88001
* function.c (match_asm_constraints_1): Don
On Wed, Dec 12, 2018 at 6:29 AM Nick Clifton wrote:
>
> Sorry to bother you, but I have another libiberty demangler resource
> exhaustion prevention patch to present. This one is for:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87241
>
> Jonathan Wakely reported that __cxa_demanlge() w
Hi all,
this patch fixes bootstrap for my powerpc*-unknown-freebsd* targets.
The definition of GNU_USER_DYNAMIC_LINKER was recently moved to linux.h.
But the GNU_USER_DYNAMIC_LINKER is still used in rs6000/sysv4.h.
So I add an empty definition with guard to cure the bootstrap issue.
Ok for trun
On 12/7/18 3:13 PM, David Malcolm wrote:
On Tue, 2018-12-04 at 18:31 -0500, Jason Merrill wrote:
On 12/3/18 5:10 PM, Jeff Law wrote:
On 11/19/18 9:51 AM, David Malcolm wrote:
[...]
@@ -1058,6 +1058,9 @@ grokbitfield (const cp_declarator
*declarator,
return NULL_TREE;
}
+ if
On 12/4/18 5:35 PM, David Malcolm wrote:
The v1 patch:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html
has bitrotten somewhat, so here's v2 of the patch, updated relative
to r266740.
Blurb from v1 patch follows:
The C frontend is able (where expression locations are available) to pr
1 - 100 of 132 matches
Mail list logo
