@Honza: PING^1
Martin
On 1/24/19 9:10 AM, Martin Liška wrote:
> On 1/23/19 7:28 PM, Segher Boessenkool wrote:
>> Hi Martin,
>>
>> On Wed, Jan 23, 2019 at 10:29:40AM +0100, Martin Liška wrote:
>>> diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
>>> index 172bdf585d0..5dd316efb63 100644
>>> --- a/gcc/cfgr
On Sat, 2 Feb 2019 at 00:13, Mike Stump wrote:
>
> On Jan 23, 2019, at 5:16 AM, Christophe Lyon
> wrote:
> > What do people think about this?
>
> Seems reasonable.
Thanks, committed as r268511.
Christophe
> On 4 Feb 2019, at 08:55, Christophe Lyon wrote:
>
> On Sat, 2 Feb 2019 at 00:13, Mike Stump wrote:
>>
>> On Jan 23, 2019, at 5:16 AM, Christophe Lyon
>> wrote:
>>> What do people think about this?
>>
>> Seems reasonable.
>
> Thanks, committed as r268511.
There are a few improvements we
On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
>
> On x86-64, since __m64 is returned and passed in XMM registers, we can
> implement MMX intrinsics with SSE instructions. To support it, we disable
> MMX by default in 64-bit mode so that MMX registers won't be available
> with x86-64. Most of MMX
Hi Harald,
After nearly 12 years, I have been found out!
OK for trunk. Since it has been such a long time, I suggest that you
limit your backporting efforts to 8-branch and, at the most, 7-branch.
Will you attempt to tackle the other issues in the PR?
Thanks
Paul
On Sun, 3 Feb 2019 at 21:04,
On Fri, Feb 01, 2019 at 09:06:16AM +0100, Richard Biener wrote:
> Tested by Steve, committed.
This actually fixed it for aarch64 which uses // as ASM_COMMENT_START, but
not e.g. for arm which uses @ as ASM_COMMENT_START.
grep -h define[[:blank:]]ASM_COMMENT_START *.h config/*/* | sed
's/START[[:b
On Mon, 4 Feb 2019, Jakub Jelinek wrote:
> On Fri, Feb 01, 2019 at 09:06:16AM +0100, Richard Biener wrote:
> > Tested by Steve, committed.
>
> This actually fixed it for aarch64 which uses // as ASM_COMMENT_START, but
> not e.g. for arm which uses @ as ASM_COMMENT_START.
> grep -h define[[:blank:
Hi.
Starting from r266926 'switch (e->value.op.op)' is reached when
one using -fdec. That's wrong as -fdec causes to create a e->value.function.
I hope the proper fix is to skip the mentioned patch and allow simplification
at the end of the function?
Patch can bootstrap on x86_64-linux-gnu and su
PING^1
On 1/24/19 4:25 PM, Martin Liška wrote:
> On 1/24/19 4:05 PM, Jakub Jelinek wrote:
>> On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args
On Mon, Feb 4, 2019 at 9:10 AM Martin Liška wrote:
>
> @Honza: PING^1
> >>> + else
> >>> + {
> >>> + if (PREV_INSN (insn))
> >>> + SET_NEXT_INSN (PREV_INSN (insn)) = NEXT_INSN (insn);
> >>> + if (NEXT_INSN (insn))
> >>> + SET_PREV_INSN (NEXT_INSN (insn)
On Thu, Jan 24, 2019 at 04:25:13PM +0100, Martin Liška wrote:
> @@ -11361,6 +11365,13 @@ gfc_match_gcc_builtin (void)
>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
> clause = SIMD_INBRANCH;
>
> + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES)
Not sure if it is clean enoug
It looks like I forgot to count the extra load of r2 for ABI_AIX
indirect calls when calculating the buffer size needed by
rs6000_indirect_call_template. This patch fixes the miscalculation.
Tested by building a powerpc64le-linux compiler. OK to apply?
* config/rs6000/rs6000.c (rs6000_in
Hi all,
Richard raised a concern about the RTL we use to represent the AdvSIMD SABD
(vector signed absolute difference) instruction.
We currently represent it as ABS (MINUS op1 op2).
This isn't exactly what SABD does. ABS treats its input as a signed value
and returns the absolute of that.
For
Hi.
The patch improves error message instead of segfaulting.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/fortran/ChangeLog:
2019-01-25 Martin Liska
PR fortran/88912
* scanner.c (load_file): Report error fo
On Mon, Feb 04, 2019 at 11:25:19AM +0100, Martin Liška wrote:
> The patch improves error message instead of segfaulting.
Note, fortran patches should be CCed to fortran mailing list.
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> M
On Sat, Feb 2, 2019 at 9:20 PM Segher Boessenkool
wrote:
>
> On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
> > On 2/1/19 7:01 AM, Marek Polacek wrote:
> > > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> > >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse
On Fri, Feb 1, 2019 at 8:28 PM Jeff Law wrote:
>
> On 2/1/19 7:01 AM, Marek Polacek wrote:
> > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> >> Hi Marc,
> >>
> >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> >>> -Wmaybe-uninitialized generates false positi
On Mon, Feb 04, 2019 at 12:04:04PM +0100, Richard Biener wrote:
> On Mon, Feb 4, 2019 at 10:10 AM Uros Bizjak wrote:
> >
> > On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> > >
> > > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > > implement MMX intrinsics with SSE in
On Mon, Feb 4, 2019 at 10:10 AM Uros Bizjak wrote:
>
> On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> >
> > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > implement MMX intrinsics with SSE instructions. To support it, we disable
> > MMX by default in 64-bit mode so t
On Mon, Feb 04, 2019 at 08:46:31PM +1030, Alan Modra wrote:
> It looks like I forgot to count the extra load of r2 for ABI_AIX
> indirect calls when calculating the buffer size needed by
> rs6000_indirect_call_template. This patch fixes the miscalculation.
> Tested by building a powerpc64le-linux
The patch for PR target/83368 changed the PIC register from a hard register to
a pseudo and broke the -mflat mode in the process. The attached patch fixes
it and does also a bit of housekeeping in the GOT support.
Tested on SPARC/Solaris 11, applied on the mainline and 8 branch.
2019-02-04 E
* Richard Henderson:
> Therefore, I've created small out-of-line helpers that are directly
> linked into every library or executable that requires them. There
> will be two direct branches, both of which will be well-predicted.
This work inspired me to put together something that provides a simi
On Sun, Feb 03, 2019 at 08:07:22AM -0800, H.J. Lu wrote:
> + /* If the misalignment of __P > 8, subtract __P by 8 bytes.
> + Otherwise, subtract __P by the misalignment. */
> + if (offset > 8)
> + offset = 8;
> + __P = (char *) (((__SIZE_TYPE__) __P) - offset);
> +
> +
On Mon, Feb 4, 2019 at 12:04 PM Richard Biener
wrote:
>
> On Mon, Feb 4, 2019 at 10:10 AM Uros Bizjak wrote:
> >
> > On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> > >
> > > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > > implement MMX intrinsics with SSE instructi
On Thu, Jan 31, 2019 at 09:08:52PM -0800, Thomas Rodgers wrote:
> Update C++17 parallel algorithms to LLVM/MIT licensed upstream sources
Just ChangeLog formatting nits below:
>
> * include/Makefile.am:update from upstream
> remove ${pstl_srcdir}/iterators.h
> add
On Mon, Feb 4, 2019 at 12:08 PM Jakub Jelinek wrote:
>
> On Mon, Feb 04, 2019 at 12:04:04PM +0100, Richard Biener wrote:
> > On Mon, Feb 4, 2019 at 10:10 AM Uros Bizjak wrote:
> > >
> > > On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> > > >
> > > > On x86-64, since __m64 is returned and passed
On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
>
> Emulate MMX punpcklXX/punpckhXX with SSE punpcklXX. For MMX punpckhXX,
> move bits 64:127 to bits 0:63 in SSE register. Only SSE register source
> operand is allowed.
>
> PR target/89021
> * config/i386/i386-protos.h (ix86_split_
On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
>
> In 64-bit mode when MMX is disabled, we can use SSE2 emulate MMX
> intrinsics.
>
> PR target/89021
> * libitm.h (_ITM_TYPE_M64): Also enabled with SSE2 in 64-bit mode.
> ---
> libitm/libitm.h | 2 +-
> 1 file changed, 1 insertion(
On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
>
> In 64-bit mode, we can use SSE2 to support 64-bit vectors.
>
> PR target/89021
> * config/i386/i386.h (VALID_SSE_REG_MODE): Allow 64-bit vector
> modes for TARGET_MMX_WITH_SSE.
> (VALID_SSE2_REG_MODE): Likewise.
> -
On Fri, 25 Jan 2019, Jonathan Wakely wrote:
> This patch was committed to trunk (r265940), but HJ's review comments
> were never addressed (and look correct to me):
> https://clicktime.symantec.com/3QJw9yc7Scra74WXzR3yBDR6H2?u=https%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-patches%2F2016-07%2Fmsg00146.html
On 2/4/19 11:29 AM, Jakub Jelinek wrote:
> On Mon, Feb 04, 2019 at 11:25:19AM +0100, Martin Liška wrote:
>> The patch improves error message instead of segfaulting.
>
> Note, fortran patches should be CCed to fortran mailing list.
Will do, thanks.
>
>> Patch can bootstrap on x86_64-linux-gnu an
On 1/25/19 7:39 PM, Jan Hubicka wrote:
>> Hi.
>>
>> This is one very similar patch.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>
>> From adf577edd5a1d2b6ed78c1cc18feaff23fbfdd1c Mon Sep 17 00:00:00 2001
>> From: ma
On 04/02/19 12:13 +0100, Florian Weimer wrote:
* Richard Henderson:
Therefore, I've created small out-of-line helpers that are directly
linked into every library or executable that requires them. There
will be two direct branches, both of which will be well-predicted.
This work inspired me t
On 1/25/19 7:59 PM, Jan Hubicka wrote:
>> Hi.
>>
>> The patch puts back ::get_create for a node that can be seen first time.
>> It's due to -O0 optimize attribute. It was unable to write properly
>> LTO test-case for it.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
On Mon, Feb 4, 2019 at 3:19 AM Jakub Jelinek wrote:
>
> On Sun, Feb 03, 2019 at 08:07:22AM -0800, H.J. Lu wrote:
> > + /* If the misalignment of __P > 8, subtract __P by 8 bytes.
> > + Otherwise, subtract __P by the misalignment. */
> > + if (offset > 8)
> > + offset = 8;
> > +
On 2/4/19 10:56 AM, Martin Liška wrote:
> Hi.
>
> Starting from r266926 'switch (e->value.op.op)' is reached when
> one using -fdec. That's wrong as -fdec causes to create a e->value.function.
> I hope the proper fix is to skip the mentioned patch and allow simplification
> at the end of the funct
Hi.
In r268092 there was added a code that guard the loop
in resolve_ref. Unfortunately, one needs to prevent execution
of 'prev = &(*prev)->next' that happens before the loop guard check.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Marti
On Mon, Feb 4, 2019 at 12:23 PM Uros Bizjak wrote:
>
> On Mon, Feb 4, 2019 at 12:04 PM Richard Biener
> wrote:
> >
> > On Mon, Feb 4, 2019 at 10:10 AM Uros Bizjak wrote:
> > >
> > > On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> > > >
> > > > On x86-64, since __m64 is returned and passed in X
When I introduced tree-form bitmaps I forgot to think about GC.
The following drops the chain_prev annotation to make the marker
work for trees. I've also maked the obstack member GTY skip
(and prevent bitmap_obstack from gengtype processing) because
the obstack isn't used for GC allocated bitma
Hi Johannes,
>> I suspect the two testsuite regressions (compared to a build with
>> dlpi_tls_modid present) I mentioned are exactly of the kind you mention:
>>
>> e.g. the gdc.test/runnable/testaa.d failures are like this
>>
>> core.exception.rangeer...@gdc.test/runnable/testaa.d(410): Range viol
Hi Martin,
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
Ok. Thanks for the very quick fix!
Regards
Thomas
Hi,
This patch adds support to vectorize sum of absolute differences (SAD_EXPR)
using SVE. It also uses the new functionality to ensure that the resulting loop
is masked. Therefore, it depends on
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00016.html
Given this input code:
int
sum_abs (uint8_
On Mon, Feb 04, 2019 at 04:45:24AM -0800, H.J. Lu wrote:
> On Mon, Feb 4, 2019 at 3:19 AM Jakub Jelinek wrote:
> >
> > On Sun, Feb 03, 2019 at 08:07:22AM -0800, H.J. Lu wrote:
> > > + /* If the misalignment of __P > 8, subtract __P by 8 bytes.
> > > + Otherwise, subtract __P by the misal
On Mon, Feb 4, 2019 at 4:01 AM Uros Bizjak wrote:
>
> On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> >
> > Emulate MMX punpcklXX/punpckhXX with SSE punpcklXX. For MMX punpckhXX,
> > move bits 64:127 to bits 0:63 in SSE register. Only SSE register source
> > operand is allowed.
> >
> >
On Mon, Feb 04, 2019 at 05:36:12AM -0800, H.J. Lu wrote:
> + /* Shift __A128 and __N128 to the left by the adjustment. */
> + switch (offset)
Ah, no, sorry, that is a bad suggestion then. On the other side,
(zext (word_var)) << shift
where zext is from "word" to double-word and shift i
On Mon, Feb 4, 2019 at 2:57 PM H.J. Lu wrote:
>
> On Mon, Feb 4, 2019 at 4:01 AM Uros Bizjak wrote:
> >
> > On Fri, Feb 1, 2019 at 10:18 PM H.J. Lu wrote:
> > >
> > > Emulate MMX punpcklXX/punpckhXX with SSE punpcklXX. For MMX punpckhXX,
> > > move bits 64:127 to bits 0:63 in SSE register. Onl
On Mon, Feb 4, 2019 at 5:59 AM Jakub Jelinek wrote:
>
> On Mon, Feb 04, 2019 at 05:36:12AM -0800, H.J. Lu wrote:
> > + /* Shift __A128 and __N128 to the left by the adjustment. */
> > + switch (offset)
>
> Ah, no, sorry, that is a bad suggestion then. On the other side,
The generated
On Mon, Feb 4, 2019 at 2:16 PM Richard Biener wrote:
> When I introduced tree-form bitmaps I forgot to think about GC.
> The following drops the chain_prev annotation to make the marker
> work for trees.
I don't understand this patch. How are the nodes in a bitmap tree now
to be found for marking
On Mon, 4 Feb 2019, Steven Bosscher wrote:
> On Mon, Feb 4, 2019 at 2:16 PM Richard Biener wrote:
> > When I introduced tree-form bitmaps I forgot to think about GC.
> > The following drops the chain_prev annotation to make the marker
> > work for trees.
>
> I don't understand this patch. How ar
The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding is this is a
straightforward rewrite. I've attached my own patch, but the file can
be obtained directly h
On 2/1/19 2:55 PM, Marek Polacek wrote:
On Fri, Feb 01, 2019 at 12:02:44PM -0500, Jason Merrill wrote:
On 2/1/19 11:26 AM, Marek Polacek wrote:
On Wed, Jan 30, 2019 at 01:39:11PM -0500, Jason Merrill wrote:
On 1/28/19 9:46 PM, Marek Polacek wrote:
This patch fixes an ICE-on-invalid (becase ou
On 2/1/19 3:52 PM, Paolo Carlini wrote:
Hi,
I think that this ICE on invalid (and valid, for c++17+) can be in fact
avoided by accepting in make_typename_type a TYPE_PACK_EXPANSION as
context, thus by not triggering the "‘T ...’ is not a class" error. Not
sure if a better fix would be somethi
This patch fixes an ICE in the Thumb-1 LDM peepholer. Thumb-1 LDMs
always update the base register except if the base is loaded.
The current implementation rejects LDMs where the base is not dead,
however this doesn't exclude the case where the base is loaded as
well as dead. Fix this by explicit
Hi.
The patch removes branches and calls information when using -f option.
I re-implemented how we calculate branches and calls summaries and
right now we can't print them on function bases. Thus I'm removing that.
One can take the information from *.gcov file or calculate that easily
from an inte
I will take another stab at un-nit-ing the changlog.
Jakub Jelinek writes:
> On Thu, Jan 31, 2019 at 09:08:52PM -0800, Thomas Rodgers wrote:
>> Update C++17 parallel algorithms to LLVM/MIT licensed upstream sources
>
> Just ChangeLog formatting nits below:
>>
>> * include/Makefile.am:update
Hi,
On 04/02/19 15:47, Jason Merrill wrote:
On 2/1/19 3:52 PM, Paolo Carlini wrote:
Hi,
I think that this ICE on invalid (and valid, for c++17+) can be in
fact avoided by accepting in make_typename_type a TYPE_PACK_EXPANSION
as context, thus by not triggering the "‘T ...’ is not a class"
er
On 2/4/19 6:15 AM, Richard Biener wrote:
>
> When I introduced tree-form bitmaps I forgot to think about GC.
> The following drops the chain_prev annotation to make the marker
> work for trees. I've also maked the obstack member GTY skip
> (and prevent bitmap_obstack from gengtype processing) bec
On February 4, 2019 5:07:00 PM GMT+01:00, Jeff Law wrote:
>On 2/4/19 6:15 AM, Richard Biener wrote:
>>
>> When I introduced tree-form bitmaps I forgot to think about GC.
>> The following drops the chain_prev annotation to make the marker
>> work for trees. I've also maked the obstack member GTY
On Mon, Feb 4, 2019 at 11:00 AM Paolo Carlini wrote:
> On 04/02/19 15:47, Jason Merrill wrote:
> > On 2/1/19 3:52 PM, Paolo Carlini wrote:
> >> Hi,
> >>
> >> I think that this ICE on invalid (and valid, for c++17+) can be in
> >> fact avoided by accepting in make_typename_type a TYPE_PACK_EXPANSIO
Ping. And adding Aarch64 Maintainers.
On Mon, 2019-01-28 at 16:11 -0800, Steve Ellcey wrote:
> On Sat, 2019-01-26 at 00:00 +0100, Jakub Jelinek wrote:
> >
> > > + /* Verify that there is no overlap in what bits are set in the
> > > two masks. */
> > > + if ((m1 + m2 + 1) != 0)
> > > +ret
> From cbe1dd5d72d5181b128c47b29e3de1c5e28c8a3c Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 24 Jan 2019 16:07:29 +0100
> Subject: [PATCH] Bail out when ipa_fn_summaries does not contain entry for
> callee (PR ipa/88958).
>
> gcc/ChangeLog:
>
> 2019-01-24 Martin Liska
>
> PR i
Forgot gcc-patches@
-- Forwarded message --
From: Marc Glisse
Reply-To: libstd...@gcc.gnu.org
To: Jonathan Wakely
Cc: Ville Voutilainen ,
libstdc++
Date: Mon, 4 Feb 2019 19:26:35 +0100 (CET)
Subject: Re: Reserve __is_trivially_relocatable for a builtin?
2019-02-04 Marc Gl
This is the second part of the fix for 89112, fixing the conditions that caused
it to happen.
This patch adds REG_BR_PROB notes to the branches generated by inline expansion
of memcmp
and strncmp. This prevents any of the code from being marked as cold and moved
to the end
of the function, which
In practice, false positives (and negatives) of both kinds, whether
they fit the formal definition or the informal one, are the nature
of virtually all non-trivial static diagnostics, certainly all those
that depend on control or data flow analysis. Some are due to bugs
or limitations in the impl
On Mon, 4 Feb 2019, Martin Sebor wrote:
In practice, false positives (and negatives) of both kinds, whether
they fit the formal definition or the informal one, are the nature
of virtually all non-trivial static diagnostics, certainly all those
that depend on control or data flow analysis. Some
In this test we have a user-defined conversion converting const int & to
T, and we're binding a const int to const int & -- the parameter of the
converting ctor. We call Func with "VIEW_CONVERT_EXPR(Val)"
as an argument. I like to use a diagram for the conversion like this:
ck_rvalue <- ck_u
Hi Paul,
On 02/04/19 10:49, Paul Richard Thomas wrote:
> Hi Harald,
>
> After nearly 12 years, I have been found out!
you cannot hide forever.
> OK for trunk. Since it has been such a long time, I suggest that you
> limit your backporting efforts to 8-branch and, at the most, 7-branch.
Sure.
[PATCH, rs6000] Fix instruction counts on powerpc64 test cases.
This patch fixes the assembler instruction counts for some test cases
that started failing due to changes in code generation. The targets
were adjusted a bit as well to avoid generating BE/LE endian code on
unsupported platforms.
B
On Mon, Feb 04, 2019 at 09:55:39PM +0100, Harald Anlauf wrote:
>
> On 02/04/19 10:49, Paul Richard Thomas wrote:
> > Hi Harald,
> >
> > After nearly 12 years, I have been found out!
>
> you cannot hide forever.
>
> > OK for trunk. Since it has been such a long time, I suggest that you
> > limit
Ping
On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote:
>
> Here we warn because i::dispatch has internal linkage (because l
> does) and is never instantiated (because the vtable is never emitted).
> The regression happened because devirtualization started adding it to
> cgraph as a possible t
On Mon, Feb 04, 2019 at 09:44:01AM -0500, Jason Merrill wrote:
> On 2/1/19 2:55 PM, Marek Polacek wrote:
> > On Fri, Feb 01, 2019 at 12:02:44PM -0500, Jason Merrill wrote:
> > > On 2/1/19 11:26 AM, Marek Polacek wrote:
> > > > On Wed, Jan 30, 2019 at 01:39:11PM -0500, Jason Merrill wrote:
> > > > >
Hi,
On Mon, Feb 04 2019, Marc Glisse wrote:
> On Mon, 4 Feb 2019, Martin Sebor wrote:
>>
...
>> You're right that this is hard to imagine without first hand experience
>> with the problem. If this is a common pattern with the warning in C++
>> class templates in general, a representative test c
On 04/02/19 19:28 +0100, Marc Glisse wrote:
Forgot gcc-patches@
And I forgot to reply to this one when approving it.
-- Forwarded message --
From: Marc Glisse
Reply-To: libstd...@gcc.gnu.org
To: Jonathan Wakely
Cc: Ville Voutilainen ,
libstdc++
Date: Mon, 4 Feb 2019 19:2
PR preprocessor/88937 reports a valgrind error:
"Conditional jump or move depends on uninitialised value(s)"
when compiling:
#if __has_include("x")
#endif
The issue is in parse_has_include, which has:
2211if (token->type == CPP_STRING || token->type == CPP_HEADER_NAME)
2212 {
On Mon, 4 Feb 2019, Jakub Jelinek wrote:
> > +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64')
> > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386')
>
> That is all from me, but I think you need a buy-in from the Fortran
> maintainers (if they are ok with such an extens
The attached patch relaxes -Wformat-overflow=2 to avoid warning about
individual directives that might (but need not) exceed the 4095 byte
limit, and about the total function output that likewise might (but
need not) exceed the INT_MAX limit.
The bug report actually requests that instead of the s
On 2/4/19, Martin Sebor wrote:
>>> In practice, false positives (and negatives) of both kinds, whether
>>> they fit the formal definition or the informal one, are the nature
>>> of virtually all non-trivial static diagnostics, certainly all those
>>> that depend on control or data flow analysis.
On 2/4/19, Martin Jambor wrote:
> Hi,
>
> On Mon, Feb 04 2019, Marc Glisse wrote:
>> On Mon, 4 Feb 2019, Martin Sebor wrote:
>>>
>
> ...
>
>>> You're right that this is hard to imagine without first hand experience
>>> with the problem. If this is a common pattern with the warning in C++
>>> clas
On 2/4/19, Martin Sebor wrote:
> The attached patch relaxes -Wformat-overflow=2 to avoid warning about
> individual directives that might (but need not) exceed the 4095 byte
> limit, and about the total function output that likewise might (but
> need not) exceed the INT_MAX limit.
>
> The bug repo
On Jan 30, 2019, Alexandre Oliva wrote:
> Because of rank compares, and checks for ck_list, we know that if we
> see user_conv_p or ck_list in ics1, we'll also see it in ics2. This
> reasoning does not extend to ck_aggr, however, so we might have
> ck_aggr conversions starting both ics1 and ics2
On Mon, 4 Feb 2019, Martin Jambor wrote:
Looking for "optional" and "-Wmaybe-uninitialized" shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Google also gives
https://www.boost.org/doc/libs/1_69_0/libs/optional/doc/html/boost_optional/t
On Jan 30, 2019, Paolo Carlini wrote:
> Hi,
> On 30/01/19 17:25, Alexandre Oliva wrote:
>> +static inline bool
>> +instantiates_primary_template_p (tree node)
> I'm rather surprised by the inline:
It's (so far) a single use function, so it will likely be inlined even
without it. But yeah, I gu
On Jan 31, 2019, Jason Merrill wrote:
> Let's use strip_using_decl instead
Aah, nice! Thanks, I'll make the changes, test them, and post a new patch.
>> @@ -13288,7 +13295,8 @@ grok_special_member_properties (tree decl)
>> {
>> tree class_type;
>> - if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (dec
83 matches
Mail list logo