On Wed, 12 Dec 2018 at 17:13, Jonathan Wakely wrote:
>
> 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
On Wed, Dec 12, 2018 at 11:36 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch uses a new mode iterator to avoid 2 almost same
> vptestm and 2 almost same vptestnm patterns, and adds patterns that zero
> extend those results to wider k registers, because that is what the
> instructions
On Wed, Dec 12, 2018 at 11:34 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds =*k, *km alternatives to the various
> zero_extend?i?i2 patterns, because kmov* instructions actually zero extend
> the destination to 64-bits. I've kept * for the alternatives because that
> is what is
Hi!
On Mon, Dec 10, 2018 at 09:56:46PM -0700, Jeff Law wrote:
> Note that split-path-5 has the same basic structure. A half-diamond
> with a single statement in the middle block that should be trivially
> if-convertable if profitable. So I adjusted that testcase.
The split-path-5.c testcase
Hi,
This patch skips generating histogram value for internal function call in
autofdo,
otherwise it would trigger ICE with following patch re-enabling indirect call
value
profile transformation. I think this patch is actually needed for GCC-6 on
which
indirect call value profile is not
Hi,
Due to ICE and mal-functional bugs, indirect call value profile transformation
is disabled on GCC-7/8/trunk. This patch restores the transformation. The
main issue is AutoFDO should store cgraph_node's profile_id of callee func in
the first histogram value's counter, rather than pointer to
Hi,
This patch calls update_max_bb_count even if autofdo counts are all zeros,
otherwise it would trigger ICE because of mismatch between basic blocks'
count (all autofdo::zero) and cfun->cfg->max_count (guessed::non_zero).
For functions with all autofdo::zero counts, we should improve by
On Wed, Dec 12, 2018 at 12:09:19PM +, Jozef Lawrynowicz wrote:
> 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)
> On Dec 12, 2018, at 5:12 PM, Uecker, Martin
> wrote:
>> ...
>> I've not seen such an alternative implementation (-fno-trampolines is
>> ignored on all targets I tried),
>
> It was implemented for Ada. But here is a patch to also
> activate it for C:
>
>
Hi!
On Wed, Dec 12, 2018 at 11:52:56AM +, Andrew Stubbs wrote:
>
> @@ -9032,9 +9040,16 @@ proc check_effective_target_cet { } {
> } "-O2" ]
> }
>
> +
> # Return 1 if target supports floating point "infinite"
> proc check_effective_target_inf { } {
Stray newline?
Segher
On Wed, Dec 12, 2018 at 07:30:08PM +1030, Alan Modra wrote:
> 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
> > +++
On 12/12/18 2:52 PM, Segher Boessenkool wrote:
>> +/* This is a fairly new feature bit, so handle it not being defined. */
>> +#ifndef PPC_FEATURE2_HTM_NO_SUSPEND
>> +# define PPC_FEATURE2_HTM_NO_SUSPEND 0
>> +#endif
>
> Doing it this way can be pretty surprising for users not aware you defined
On Wed, Dec 12, 2018 at 06:23:08PM -0500, David Malcolm wrote:
> On Wed, 2018-12-12 at 11:40 -0600, Segher Boessenkool wrote:
> > > Is there test coverage for these errors and notes?
> >
> > Yes, in this same patch. The error, that is; I have no idea how to
> > test
> > the note, and that
On Wed, Dec 12, 2018 at 8:10 AM Cherry Zhang wrote:
>
> 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
On Wed, 2018-12-12 at 11:40 -0600, Segher Boessenkool wrote:
> 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
POSIX requires snprintf to fail with EOVERFLOW when the specified
bound exceeds INT_MAX. This requirement conflicts with the C
requirements on valid calls to the function and isn't universally
implemented (e.g., Glibc doesn't seem to follow it, and GCC has
historically not paid heed to it
Hi!
The following patch makes array or derived type module parameters from other
TUs predetermined shared, so that they aren't rejected with default(none) or
copied with default(firstprivate). I went through all the spots in the
Fortran FE that set TREE_READONLY, most of them are on PARM_DECLs
This patch by Lynn Boger increases the time to wait for signals to be
delivered in the TestAtomicStop test in the os/signal package. When
running gccgo tests on ppc64 or ppc64le, there are intermittent
failures in this test because the wait time is too small.
Bootstrapped and ran os/signal test on
Hi!
We support either the AVX2 gather loads (128-bit or 256-bit, using masks in
vector registers), both conditional and unconditional, but AVX512F gather
loads only unconditional. The problem was that tree-vect-stmts.c didn't
have code to deal with the integral masktype argument the builtins
Hi!
As mentioned in the PR, we can use kxor? %kN, %kN, %kN or
kxnor? %kN, %kN, %kN to set %kN to 0 or -1, instead of
setting a GPR to that and moving to the mask register.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-12-12 Jakub Jelinek
PR target/88465
Hi!
The following patch uses a new mode iterator to avoid 2 almost same
vptestm and 2 almost same vptestnm patterns, and adds patterns that zero
extend those results to wider k registers, because that is what the
instructions actually do.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok
Hi!
The following patch adds =*k, *km alternatives to the various
zero_extend?i?i2 patterns, because kmov* instructions actually zero extend
the destination to 64-bits. I've kept * for the alternatives because that
is what is used e.g. in *mov[sd]i_internal patterns (probably to make it
less
Hi!
The following patch fixes __builtin_is_constant_evaluated and
__builtin_constant_p handling during static_assert evaluation.
finish_static_assert calls fold_non_dependent_expr and complains if the
result is not a constant expression, instead of requiring a constant
expression, which causes
Hi Wilco,
Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
> Hi Martin,
>
> > Does a non-executable stack actually improve security?
>
> Absolutely, it's like closing your front door rather than just leave it open
> for anyone.
The question is whether it is like closing the
Hi Martin,
> Does a non-executable stack actually improve security?
Absolutely, it's like closing your front door rather than just leave it open
for anyone.
> For the alternative implementation using (custom) function
> descriptors (-fno-trampolines) the static chain becomes
> part of the ABI
Hi all,
I have this patch since a longer time in my tree. No obvious fallout
visible.
I'm going to commit this patch in the next days if no one objects.
TIA,
Andreas
2018-12-12 Andreas Tobler
* config.gcc: Enable TARGET_DEFAULT_ASYNC_UNWIND_TABLES on
aarch64*-*-freebsd*.
On 12/11/18 5:55 PM, David Malcolm wrote:
PR c++/88375 reports that errors relating to invalid conversions in
initializations are reported at unhelpfully vague locations, as in
e.g.:
enum struct a : int {
one, two
};
struct foo {
int e1, e2;
a e3;
} arr[] = {
{ 1, 2, a::one },
{
Hello,
we hit a bug today while cross-compiling a C++ program with mingw32:
if random_shuffle or random_sample_n are called with a sequence of
elements whose length is higher than RAND_MAX, the functions don't
behave as expected because they ignore elements beyond RAND_MAX. This
does not happen
The attached patch committed in r267065 corrects a few minor
typos in the description of attribute copy in the manual.
Martin
gcc/ChangeLog:
* doc/extend.texi (attribute copy): Fix typos.
Index: gcc/doc/extend.texi
===
---
On 12/11/18 9:41 PM, Sandra Loosemore wrote:
On 12/5/18 10:14 AM, Martin Sebor wrote:
On 12/4/18 8:49 PM, Sandra Loosemore wrote:
What is the "it" referenced in the user's questions you quoted? The
const/pure attributes? Those are function attributes. The text you
are adding is in the
On Wed, Dec 12, 2018 at 01:47:02PM -0600, Peter Bergner wrote:
> 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
On 12/12/18 9:56 AM, Paolo Carlini wrote:
Hi,
it seems we can easily improve the location of this - not so uncommon in
novice code - error to point to the 'static' keyword.
OK.
Jason
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
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
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
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()
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):
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
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!
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
>
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
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
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
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)
>> >
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
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
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)
> > > > +
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
> > >
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
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
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
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
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: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
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
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
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
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
> 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 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
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.
>
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, 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
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
* 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/
>
* 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
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.
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
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 */
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
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!
>>
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
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
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
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
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
[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.
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
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
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
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
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
> > 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 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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
>
[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
1 - 100 of 132 matches
Mail list logo
