On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not strip anything but _exactly_ one NUL
>>
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> Add the remainder of clobber high checks.
> Happy to split this into smaller patches if required (there didn't
> seem anything obvious to split into).
>
> 2018-07-25 Alan Hayward
>
> * alias.c (record_set): Check for clobber high.
> *
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> Add the clobber high expressions to tls_desc for aarch64.
> It also adds three tests.
>
> In addition I also tested by taking the gcc torture test suite and making
> all global variables __thread. Then emended the suite to compile with -fpic,
> save
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> The cse specific changes for clobber_high.
>
> 2018-07-25 Alan Hayward
>
> * cse.c (invalidate_reg): New function extracted from...
> (invalidate): ...here.
> (canonicalize_insn): Check for clobber high.
>
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> The lra specific changes for clobber_high.
>
> 2018-07-25 Alan Hayward
>
> * lra-eliminations.c (lra_eliminate_regs_1): Check for clobber high.
> (mark_not_eliminable): Likewise.
> * lra-int.h (struct lra_insn_reg): Add clobber
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> Given a CLOBBER_HIGH expression and a register, it checks if
> the register will be clobbered.
>
> A second version exists for the cases where the expressions are
> not available.
>
> The function will be used throughout the following patches.
>
>
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> Ensure clobber high is a register expression.
> Info is passed through for the error case.
>
> 2018-07-25 Alan Hayward
>
> * emit-rtl.c (verify_rtx_sharing): Check for CLOBBER_HIGH.
> (copy_insn_1): Likewise.
>
On 07/26/2018 03:13 AM, Alan Hayward wrote:
> Includes documentation.
>
> 2018-07-25 Alan Hayward
>
> * doc/rtl.texi (clobber_high): Add.
> (parallel): Add in clobber high
> * rtl.c (rtl_check_failed_code3): Add function.
> * rtl.def (CLOBBER_HIGH): Add expression.
>
I've checked in this patch to fix the c-c++-common/spec-barrier-1.c test
failure on nios2. Per previous discussions about Spectre
vulnerabilities with Altera/Intel, this architecture is not affected so
no special handling is required here.
-Sandra
2018-08-03 Sandra Loosemore
gcc/
*
Hi Cristophe,
this is seriously weird - there is not even an I/O statement in that test case.
One question: Is this real hardware or an emulator?
Also, Could you try a few things?
Run the test case manually. Do you still fail?
Is there an error if the executable is run under valgrind?
If you
On 08/01/2018 04:34 AM, Uros Bizjak wrote:
> Hello!
>
> The testcase fails with:
>
> FAIL: g++.dg/pr83239.C -std=gnu++11 scan-tree-dump-not optimized
> "_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
> FAIL: g++.dg/pr83239.C -std=gnu++14 scan-tree-dump-not optimized
>
On 08/01/2018 11:21 AM, Martin Sebor wrote:
> On 08/01/2018 04:34 AM, Uros Bizjak wrote:
>> Hello!
>>
>> The testcase fails with:
>>
>> FAIL: g++.dg/pr83239.C -std=gnu++11 scan-tree-dump-not optimized
>> "_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
>> FAIL: g++.dg/pr83239.C -std=gnu++14
On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not strip anything but _exactly_ one NUL
>>
On 08/03/18 23:15, Jeff Law wrote:
> On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
>> On 07/30/18 21:52, Martin Sebor wrote:
>>> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
> Hi,
>
> this completes the previous patches, and adds a check in varasm.c
> that ensures that all string constants are NUL terminated,
> And that varasm does not strip anything but _exactly_ one NUL
> character.
>
> Bootstrapped and reg-tested on
On Fri, Aug 03, 2018 at 03:16:41PM -0600, Jeff Law wrote:
> On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
> > On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
> >>> We do not want to change what is currently accepted by the
> >>> front end. period.
> >>
> >> On whose behalf are you
On 07/30/2018 01:52 PM, Martin Sebor wrote:
> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>> On 07/30/18 01:05, Martin Sebor wrote:
>>> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants.
On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
>>> We do not want to change what is currently accepted by the
>>> front end. period.
>>
>> On whose behalf are you making such categorical statements?
>> It was Jakub and Richard's
On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
> On 07/30/18 21:52, Martin Sebor wrote:
>> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>>> On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
> Hi!
>
> This fixes two wrong code bugs where
On 07/28/2018 07:04 AM, slyfox.inbox.ru via gcc-patches wrote:
> From: Sergei Trofimovich
>
> Cc: Andreas Schwab
> Cc: Torvald Riegel
> Cc: Alexandre Oliva
> Cc: Oleg Endo
> Cc: Kaz Kojima
> Signed-off-by: Sergei Trofimovich
> ---
> libitm/config/sh/sjlj.S | 4 ++--
> 1 file changed, 2
On 08/03/2018 07:00 AM, Bernd Edlinger wrote:
On 08/02/18 22:34, Martin Sebor wrote:
On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree
On Tue, 2018-05-01 at 07:18 -0400, Nathan Sidwell wrote:
> On 04/30/2018 08:29 PM, David Malcolm wrote:
> > Following on from the thread on the "gcc" list here:
> >
> >https://gcc.gnu.org/ml/gcc/2018-04/msg00172.html
> >
> > here's an updated version of Jonathan's patch, which:
> > + {
> >
On 08/03/18 18:50, Olivier Hainque wrote:
> Hi Bernd,
>
>> On 31 Jul 2018, at 14:07, Bernd Edlinger wrote:
>>
>> Hi!
>>
>>
>> This fixes a couple STRING_CST that are not explicitly NUL terminated.
>> These were caught in a new check in varasm.c I am currently working on.
>>
>> Having a NUL
On 07/24/2018 04:28 AM, tamar.christ...@arm.com wrote:
> Hi All,
>
> This patch cleans up the testsuite when a run is done with stack clash
> protection turned on.
>
> Concretely this switches off -fstack-clash-protection for a couple of tests:
>
> * sve: We don't yet support
On 07/31/2018 02:58 PM, Martin Sebor wrote:
> I can't approve patches but this one seems to be in
> the obvious category so I think it could be checked in
> without formal approval.
>
> It is however missing a couple of things: 1) a test case,
> and 2) a reference to the bug it fixes in the
On 07/31/2018 12:50 PM, Martin Sebor wrote:
> Attached is a much scaled-down patch that only adds a note
> to the -Warray-bounds warnings mentioning the declaration
> to which the out-of-bounds index or offset applies.
>
> Printing the inlining context needs a bit more work but
> this small
On 07/27/2018 03:44 PM, Eric Botcazou wrote:
>> Apropos of the discussion about improving the docs for
>> TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port
>> submission,
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html
>>
>> here is the patch I've come up with
On 07/27/2018 07:09 AM, Jozef Lawrynowicz wrote:
> As reported in PR/86662, use of __int20 in a program built with -mlarge and
> -flto causes a segfault for msp430 due to endless recursion in
> gimple_get_alias_set.
> The attached patch fixes this.
> The segfault can be observed on the gcc-7 and
On 07/25/2018 08:59 AM, David Malcolm wrote:
> On Tue, 2018-07-24 at 16:11 +0200, Richard Biener wrote:
>> On Mon, Jul 23, 2018 at 9:20 PM David Malcolm
>> wrote:
>>>
>>> On Mon, 2018-07-23 at 11:46 +0200, Richard Biener wrote:
On Fri, Jul 20, 2018 at 6:27 PM David Malcolm >>> m>
wrote:
On 07/25/2018 05:09 AM, Tamar Christina wrote:
> Hi All,
>
> Attached an updated patch which documents what the test cases are expecting
> as requested.
>
> Ok for trunk?
>
> Thanks,
> Tamar
>
> gcc/
> 2018-07-25 Tamar Christina
>
> PR target/86486
> * config/aarch64/aarch64.h
On 07/25/2018 05:09 AM, Tamar Christina wrote:
> Hi All,
>
> Attached is an updated patch that clarifies some of the comments in the patch
> and adds comments to the individual testcases
> as requested.
>
> Ok for trunk?
>
> Thanks,
> Tamar
>
> gcc/
> 2018-07-25 Jeff Law
>
On 07/24/2018 08:14 AM, Tamar Christina wrote:
> Hi All,
>
> Here's an updated patch with documentation.
>
>
> Ok for trunk?
>
> Thanks,
> Tamar
>
> gcc/
> 2018-07-24 Tamar Christina
>
> PR target/86486
> * configure.ac: Add stack-clash-protection-guard-size.
> *
On 07/24/2018 04:29 AM, tamar.christ...@arm.com wrote:
> Hi All,
>
> This patch is re-spun to handle the configure changes in patch 4 / 6 of the
> previous series.
>
> This patch now changes it so that default parameters are validated during
> initialization. This change is needed to ensure
AFAIK there's not enough building blocks on the mn103 series to mount a
spectre v1 attack.
Committed to the trunk.
Jeff
commit 2419ebf7b73827b1266f265b325d24c2e9daf0f1
Author: law
Date: Fri Aug 3 17:39:00 2018 +
PR target/86795
* config/mn10300/mn10300.c
On 08/02/2018 02:19 PM, John David Anglin wrote:
> On 2018-08-02 2:40 PM, Jeff Law wrote:
>> It's been eons. I think there's enough building blocks on the PA to
>> mount a spectre v1 attack. They've got branch prediction with varying
>> degress of speculative execution, caches and user
Hi Bernd,
> On 31 Jul 2018, at 14:07, Bernd Edlinger wrote:
>
> Hi!
>
>
> This fixes a couple STRING_CST that are not explicitly NUL terminated.
> These were caught in a new check in varasm.c I am currently working on.
>
> Having a NUL terminated string does not change the binary output, but
On 02/08/18 20:18, James Greenhalgh wrote:
On Tue, Jul 31, 2018 at 04:53:19AM -0500, Matthew Malcomson wrote:
Fixing the ilp32 issue that Christophe found.
The existing testcase uses `long` to represent a 64 bit integer.
This breaks when compiled using the `-mabi=ilp32` flag.
We switch the use
On 08/02/2018 04:27 PM, Jeff Law wrote:
I think the cse_cc pass is really just working around one or more bugs
in CSE and/or a backend bug. The RTL above clearly shows a common
subexpression that is not eliminated by CSE.
What CSE should be trying to do is changing the second and third
Hi!
Some time ago, I've moved the poor man's offsetof recognizing hack to
cp_fold. On the following testcase that means we don't fold it early during
parsing. Now, if we try to evaluate those inside of constexpr contexts
with !ctx->quiet, it is diagnosed as invalid (but *non_constant_p is not
Hi James,
Thanks for the review.
> -Original Message-
> From: James Greenhalgh
> Sent: Tuesday, July 31, 2018 22:07
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
>
> Subject: Re: [PATCH][GCC][AArch64] Cleanup the AArch64 testsuite when
Hi!
As the comment say, we want to insert (if should_insert_square_recip
is true) new_square_stmt right after new_stmt. The current code does
that correctly if new_stmt is inserted with
gsi_insert_before (, new_stmt, GSI_SAME_STMT);
because the following
gsi_insert_before (,
Hi!
As mentioned in the PR, for valid structured bindings this patch should be
unnecessary, because the identifiers from the structured binding shouldn't
be used in the initializer of the structured binding, but for invalid source
it can matter. When tsubst_init is called before
On 08/03/2018 08:22 AM, Tom de Vries wrote:
> On 08/01/2018 09:11 PM, Cesar Philippidis wrote:
>> On 08/01/2018 07:12 AM, Tom de Vries wrote:
>>
>> + gangs = grids * (blocks / warp_size);
>
> So, we launch with gangs == grids * workers ? Is that intentional?
Yes.
The "@" handling broke -mlow-precision-div, because the scalar forms of
the instruction were provided by a pattern that also provided FRECPX
(and so were parameterised on an unspec code as well as a mode),
while the SIMD versions had a dedicated FRECPE pattern. This patch
moves the scalar FRECPE
On Wed, 1 Aug 2018, Bogdan Harjoc wrote:
> > seen_error () is the idiomatic way of testing whether an error has been
> > reported.
>
> The updated patch is attached and includes a test that passes with:
>
> make check-gcc RUNTESTFLAGS="dg.exp=union-duplicate-field.c"
Thanks, committed.
--
On 08/01/2018 09:11 PM, Cesar Philippidis wrote:
> On 08/01/2018 07:12 AM, Tom de Vries wrote:
>
> + gangs = grids * (blocks / warp_size);
So, we launch with gangs == grids * workers ? Is that intentional?
>>>
>>> Yes. At least that's what I've been using in og8. Setting
On Fri, 3 Aug 2018, David Malcolm wrote:
> A manpage checker [1] detected various stray repeated words
> in the generated manpages for gcc and gcov, which this patch
> fixes.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
OK (in my view this patch is
On Aug 03 2018, Pierre-Marie de Rodat wrote:
> Understood, thank you for the context. Let’s try to fix the underlying
> problem if you have issues with canadian crosses again. :-)
There should at least be a way to find the build gnatmake under a
different name.
Andreas.
--
Andreas Schwab,
On 02/08/18 17:26, matthew.malcom...@arm.com wrote:
> Use the STLUR instruction introduced in Armv8.4-a.
> This insruction has the store-release semantic like STLR but can take a
> 9-bit unscaled signed immediate offset.
>
> Example test case:
> ```
> void
> foo ()
> {
> int32_t *atomic_vals
On 08/03/2018 02:45 AM, Jakub Jelinek wrote:
Hi!
This is Jason's patch from the PR for which I've added a reduced testcase
and bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for trunk and 8.3 (perhaps after a while)?
2018-07-30 Jason Merrill
PR c++/86706
*
> On Aug 3, 2018, at 9:19 AM, Janne Blomqvist wrote:
>
> The getentropy function, found on Linux, OpenBSD, and recently also
> FreeBSD, can be used to get random bytes to initialize the PRNG. It
> is similar to the traditional way of reading from /dev/urandom, but
> being a system call
On Fri, Aug 3, 2018 at 4:28 PM, Jakub Jelinek wrote:
> On Fri, Aug 03, 2018 at 04:19:03PM +0300, Janne Blomqvist wrote:
> > --- a/libgfortran/intrinsics/random.c
> > +++ b/libgfortran/intrinsics/random.c
> > @@ -309,12 +309,9 @@ getosrandom (void *buf, size_t buflen)
> >for (size_t i = 0; i
On Fri, Aug 03, 2018 at 04:19:03PM +0300, Janne Blomqvist wrote:
> --- a/libgfortran/intrinsics/random.c
> +++ b/libgfortran/intrinsics/random.c
> @@ -309,12 +309,9 @@ getosrandom (void *buf, size_t buflen)
>for (size_t i = 0; i < buflen / sizeof (unsigned int); i++)
> rand_s ([i]);
>
Hi Allan,
> On 3 Aug 2018, at 12:56, Allan Sandfeld Jensen wrote:
>
> On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote:
>> On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
>>> gcc/
>
> 2018-07-29 Allan Sandfeld Jensen
>
> gcc/doc
>
>* invoke.texi: Document -r
>
> gcc/
>
On 08/02/2018 04:44 PM, Jim Wilson wrote:
I only needed it for the first canadian cross build. If it is causing
problems for you it can be dropped. If I need it again, it is easy
enough to write again.
Ok, thank you! I’ve just committed the revert.
I ran into a problem where the search
The getentropy function, found on Linux, OpenBSD, and recently also
FreeBSD, can be used to get random bytes to initialize the PRNG. It
is similar to the traditional way of reading from /dev/urandom, but
being a system call rather than a special file, it doesn't suffer from
problems like running
On 08/02/18 22:34, Martin Sebor wrote:
> On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
>> On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree len = c_strlen (src, 0,
Richard Biener writes:
> On Fri, Jul 20, 2018 at 12:22 PM Richard Sandiford
> wrote:
>>
>> We couldn't vectorise:
>>
>> for (int j = 0; j < n; ++j)
>> {
>> for (int i = 0; i < 16; ++i)
>> a[i] = (b[i] + c[i]) >> 1;
>> a += step;
>> b += step;
>> c += step;
On 02/08/18 13:05 -0400, David Edelsohn wrote:
On Thu, Aug 2, 2018 at 12:12 PM Jonathan Wakely wrote:
On 02/08/18 11:32 -0400, David Edelsohn wrote:
>Jonathan
>
>This patch broke AIX bootstrap.
>
>/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++11/system_error.cc: In
>member function 'virtual
Hello Rasmus,
(Back after a summer break & some backlog preemption)
Thanks for resubmitting those patches.
Re reviewing; will get back to you when I'm done,
hopefully soon :)
Olivier
> On 28 Jun 2018, at 10:43, Rasmus Villemoes wrote:
>
> Patches 1, 2 and 4 (the latter was number 6
Hi Matthew
On 02/08/18 17:26, matthew.malcom...@arm.com wrote:
Use the STLUR instruction introduced in Armv8.4-a.
This insruction has the store-release semantic like STLR but can take a
9-bit unscaled signed immediate offset.
Example test case:
```
void
foo ()
{
int32_t *atomic_vals =
On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote:
> On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> > gcc/
> >
> > * gcc.c: Correct default specs for -r
>
> I don't follow why your changes (which would need describing for each
> individual spec changed) are corrections.
>
> >
On Fri, Aug 03, 2018 at 11:45:31AM +0200, Tom de Vries wrote:
> If a target does not support exceptions, it can indicate this by returning
> UI_NONE in TARGET_EXCEPT_UNWIND_INFO. Currently the compiler still emits
> exception tables for such a target.
>
> This patch makes sure that no exception
[ was: Re: [PATCH][nvptx] Ignore c++ exceptions ]
On Thu, Aug 02, 2018 at 06:10:50PM +0200, Tom de Vries wrote:
> On 08/02/2018 05:39 PM, Jakub Jelinek wrote:
> > On Thu, Aug 02, 2018 at 05:30:53PM +0200, Tom de Vries wrote:
> >> The nvptx port can't support exceptions using sjlj, because ptx
Hi!
This is Jason's patch from the PR for which I've added a reduced testcase
and bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for trunk and 8.3 (perhaps after a while)?
2018-07-30 Jason Merrill
PR c++/86706
* class.c (build_base_path): Use currently_open_class.
On 02/08/18 21:19, John David Anglin wrote:
> On 2018-08-02 2:40 PM, Jeff Law wrote:
>> It's been eons. I think there's enough building blocks on the PA to
>> mount a spectre v1 attack. They've got branch prediction with varying
>> degress of speculative execution, caches and user accessable
A manpage checker [1] detected various stray repeated words
in the generated manpages for gcc and gcov, which this patch
fixes.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks
Dave
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1611292
gcc/ChangeLog:
On Thu, 2 Aug 2018 at 19:05, Nicolas Koenig wrote:
>
> On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote:
> > On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig
> > wrote:
> > >
> > >
> > > Hello everyone,
> > >
> > > Here is an updated version of the patch that hopefully fixes the
> >
> 在 2018年8月3日，06:27，Jeff Law 写道：
>
> On 07/26/2018 12:06 AM, 瞿仙淼 wrote:
>>
>>> 在 2018年7月25日，上午5:24，Jeff Law 写道：
>>>
>>> On 07/24/2018 12:18 PM, Sandra Loosemore wrote:
On 07/24/2018 09:45 AM, Jeff Law wrote:
> On 07/23/2018 10:21 PM, Sandra Loosemore wrote:
> I'm not a big fan
On Fri, Aug 03, 2018 at 01:19:14AM -0600, Jeff Law wrote:
> I'm leaning towards a similar conclusion, namely that we can only rely
> on type information for the pointer that actually gets passed to strlen,
> which 99.9% of the time is (char *), potentially with const qualifiers.
You can't derive
On 08/01/2018 09:13 PM, Martin Sebor wrote:
> On 08/01/2018 01:19 AM, Richard Biener wrote:
>> On Tue, 31 Jul 2018, Martin Sebor wrote:
>>
>>> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
> On 07/31/2018 12:38 AM, Jakub Jelinek
On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
> > If I call this with foo (2, 1), do you still claim it is not valid C?
>
> String functions like strlen operate on character strings stored
> in character arrays. Calling strlen ([1]) is invalid because
> [1] is not the address of
On 08/01/2018 01:19 AM, Richard Biener wrote:
> On Tue, 31 Jul 2018, Martin Sebor wrote:
>
>> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
>>> On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 09:45:49PM
On 07/25/2018 01:36 PM, Martin Sebor wrote:
>> BUT - for the string_constant and c_strlen functions we are,
>> in all cases we return something interesting, able to look
>> at an initializer which then determines that type. Hopefully.
>> I think the strlen() folding code when it sets SSA ranges
On 07/25/2018 01:23 AM, Richard Biener wrote:
> On Tue, 24 Jul 2018, Bernd Edlinger wrote:
>
>> On 07/24/18 23:46, Jeff Law wrote:
>>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range computations more conservative.
Firstly if there is a
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
> On 07/24/18 23:46, Jeff Law wrote:
>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> This patch makes strlen range computations more conservative.
>>>
>>> Firstly if there is a visible type cast from type A to B before passing
>>> then
76 matches
Mail list logo
