I have one more example similar to PR86259, that resembles IMHO real world code:
Consider the following:
int fun (char *p)
{
char buf[16];
assert(strlen(p) < 4); //here: security relevant check
sprintf(buf, "echo %s - %s", p, p); //here: security relevant code
return system(buf);
}
W
Hello, Gerald,
I created a new mirror in Hong Kong. Can you add it too?
+Hong Kong:
+ http://mirror-hk.koddos.net/gcc/";>http://mirror-hk.koddos.net/gcc/ |
+ rsync://mirror-hk.koddos.net/gcc/,
+ thanks to Martin (mir...@koddos.net) at KoDDoS.
Regards,
Martin
On Wed, 28 Feb 2018, KoDDoS Mir
On Monday, 23/7/2018 16:22:24 EEST Jeff Law wrote:
> On 07/19/2018 08:12 PM, Dimitar Dimitrov wrote:
> > On събота, 23 юни 2018 г. 20:35:23 EEST Jakub Jelinek wrote:
> >> On Sat, Jun 23, 2018 at 03:26:50PM +0300, Dimitar Dimitrov wrote:
> >>> I took arm/ldmstm.md as an inspiration. See attached mac
> On Jul 26, 2018, at 7:34 PM, Joseph Myers wrote:
>
> On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
>
Port maintainers DO need to decide what to do about speculation, even if
it is explicitly that no mitigation is needed.
>>>
>>> Agreed. But I didn't yet see a request for
On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
> >> Port maintainers DO need to decide what to do about speculation, even if
> >> it is explicitly that no mitigation is needed.
> >
> > Agreed. But I didn't yet see a request for maintainers to decide that?
> >
>
> consider it made, then :
On Tue, 24 Jul 2018, Sandra Loosemore wrote:
> On 07/23/2018 10:17 PM, Sandra Loosemore wrote:
>
> > C-SKY proposes Han Mao and Yunhai Shang
> > as maintainers for this port.
>
> I apologize, I made a mistake here. The correct proposed maintainers are
> Xianmiao Qu and Yunhai Shang
> .
I'
On Fri, 20 Jul 2018, Martin Liška wrote:
> +C++ ObjC++ Ignore)
Stray ')' at the end of this line.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 19 Jul 2018, Martin Liška wrote:
> I must admit that was my intention :) In my eyes it makes it more consistent
> and
> it gives consumers feedback about usage of an option that does nothing.
> For x86_64 there's list of options that are Ignore and don't produce a
> warning:
The design
Hi Ulrich,
The problem is that io/asynch.h unconditionally uses a couple of
features that are not provided by gthr-simplex, in particular
__gthread_cond_t
and
__gthread_equal / __gthread_self
According to the documentation in gthr.h, the former is only available
if __GTHREAD_HAS_COND is d
On 07/26/2018 08:58 AM, Martin Sebor wrote:
On 07/26/2018 02:38 AM, Richard Biener wrote:
On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
I don't mean for the special value to be u
On Wed, 18 Jul 2018, Janne Blomqvist wrote:
> minimumNumber(a, NaN) = minimumNumber(NaN, a) = a
>
> That is minimumNumber corresponds to minnum in IEEE 754-2008 and fmin* in
No, it differs in the handling of signaling NaNs (with minimumNumber, if
the NaN argument is signaling, it results in the
On Thu, Jul 26, 2018 at 02:53:09PM -0500, Pat Haugen wrote:
> Probably an obvious patch but...
>
> The testcase fails because it looks like recent glibc headers (2.27 at least)
> no longer contain a declaration for __strdup, which results in warning
> messages being generated and failure for exc
On 26/07/18 16:03 -0400, Marek Polacek wrote:
We've been carrying this test internally for quite some time and I think it
would be beneficial for everyone to include it in the upstream testsuite, too.
Tested on x86_64-linux, ok for trunk and 8.3?
OK.
(Although as I said on internal IRC, I don
We've been carrying this test internally for quite some time and I think it
would be beneficial for everyone to include it in the upstream testsuite, too.
Tested on x86_64-linux, ok for trunk and 8.3?
2018-07-26 Marek Polacek
* 30_threads/condition_variable_any/cond.cc: New test.
---
Probably an obvious patch but...
The testcase fails because it looks like recent glibc headers (2.27 at least)
no longer contain a declaration for __strdup, which results in warning messages
being generated and failure for excess errors. Fixed by calling the standard
name.
Verified the testcas
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
> On 2018-07-20 06:05 AM, Richard Biener wrote:
>>> /* Return a new assembler name for a clone with SUFFIX of a decl named
>>> NAME. */
>>> @@ -521,14 +521,13 @@ tree
>>> clone_function_name_1 (const char *name, const char *suffix)
>>
>> pass
On Mon, 16 Jul 2018, Alexander von Gluck IV wrote:
> * We have been dragging these around since gcc 4.x.
> * Some tweaks will likely be needed, but this gets our foot
> in the door.
>
> Authors:
> Fredrik Holmqvist
> Jerome Duval
> Augustin Cavalier
> François Revol
> Simon South
>
On 07/25/2018 07:08 PM, Sudakshina Das wrote:
Hi Sam
On 25/07/18 14:08, Sam Tebbs wrote:
On 07/23/2018 05:01 PM, Sudakshina Das wrote:
Hi Sam
On Monday 23 July 2018 11:39 AM, Sam Tebbs wrote:
Hi all,
This patch extends the aarch64_get_lane_zero_extendsi instruction
definition to
also co
On 06/29/2018 11:05 AM, Jeff Law wrote:
On 06/07/2018 09:57 AM, Martin Sebor wrote:
The attached patch enhances the strlen pass to more consistently
deal with MEM_REF assignments (PR 86042) and to track string
lengths across calls to memcpy that overwrite parts of a string
with sequences of non-
Hi!
I've backported 4 commits of mine to gcc-8-branch, after
bootstrapping/regtesting them on x86_64-linux and i686-linux.
Jakub
2018-07-26 Jakub Jelinek
Backported from mainline
2018-07-10 Jakub Jelinek
PR fortran/86421
* module.c (omp_declare_simd
Umesh Kalappa wrote:
> Any more suggestions or comments on the patch ?
The patch is suboptimal as it introduces 2 additional instructions in a
fairly common path for a branch that is very unlikely to be taken in
practice.
I'm therefore proposing this alternative patch to fix the issue in an
o
Hi!
As mentioned in the PR and now that the middle-end bug is fixed, this fixes
thinkos in the testcase; the result variable has to be omp declare target,
otherwise the declared target functions called from the target regions can't
access it.
The testcase still fails to assemble due to exceptions
Hi!
We can't ignore map clauses for variables that are declare target to
if the map clause has always modifier, because we need to copy the data to
and/or from the device as user requested. This has slightly undesirable
effect that the vars inside of the construct are remapped, perhaps with more
On 26/07/18 08:59 -0700, Cesar Philippidis wrote:
On 07/26/2018 07:01 AM, jwak...@redhat.com wrote:
From: Jonathan Wakely
It looks like you're using git send-email for this patch series. And it
seems like you made the same mistake that I did when you configured git
sendmail.from. According to
On 26/07/18 16:59 +0100, Jonathan Wakely wrote:
On 26/07/18 11:51 -0400, Marek Polacek wrote:
On Thu, Jul 26, 2018 at 03:01:51PM +0100, jwak...@redhat.com wrote:
--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -201,7 +201,6 @@ namespace
fake_messages
On 07/26/2018 07:01 AM, jwak...@redhat.com wrote:
> From: Jonathan Wakely
It looks like you're using git send-email for this patch series. And it
seems like you made the same mistake that I did when you configured git
sendmail.from. According to the git sent-email manpage, from should be
your ema
On 26/07/18 11:51 -0400, Marek Polacek wrote:
On Thu, Jul 26, 2018 at 03:01:51PM +0100, jwak...@redhat.com wrote:
--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -201,7 +201,6 @@ namespace
fake_messages_w messages_w;
#endif
-#ifdef _GLIBCXX_USE_C99
On Thu, Jul 26, 2018 at 03:01:51PM +0100, jwak...@redhat.com wrote:
> --- a/libstdc++-v3/src/c++98/locale_init.cc
> +++ b/libstdc++-v3/src/c++98/locale_init.cc
> @@ -201,7 +201,6 @@ namespace
>fake_messages_w messages_w;
> #endif
>
> -#ifdef _GLIBCXX_USE_C99_STDINT_TR1
>typedef char fake
On 07/26/2018 04:27 PM, Cesar Philippidis wrote:
> Hi Tom,
>
> I see that you're reviewing the libgomp changes. Please disregard the
> following hunk:
>
> On 07/11/2018 12:13 PM, Cesar Philippidis wrote:
>> @@ -1199,12 +1202,59 @@ nvptx_exec (void (*fn), size_t mapnum, void
>> **hostaddrs, void
> Ulrich Weigand wrote:
> Nicholas Koenig wrote:
>
>> Hello everyone,
>>
>> I have committed the async I/O patch as r262978.
>>
>> The test cases are in libgomp.fortran for now, maybe that can be changed
>> later.
>
> It looks like this broke building libgfortran on spu, and presumably
> any p
> On Jul 26, 2018, at 3:26 AM, Richard Biener wrote:
>
> On Wed, 25 Jul 2018, Qing Zhao wrote:
>
>> Hi,
>>
>> As Wilco suggested, the new added strcmp/strncmp inlining should be only
>> enabled with O2 and above.
>>
>> this is the simple patch for this change.
>>
>> tested on both X86 and
On Thu, 26 Jul 2018, Martin Liška wrote:
Following patch implements new predictors that annotates malloc-like functions.
These almost every time return a non-null value.
Out of curiosity (the __builtin_expect there doesn't hurt and we don't
need to remove it), does it make __builtin_expect un
On 07/26/2018 02:38 AM, Richard Biener wrote:
On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
I don't mean for the special value to be used except internally
for the defaults. Othe
On Thu, Jul 26, 2018 at 08:40:01AM -0500, Kelvin Nilsen wrote:
> To improve internal consistency and to improve consistency with published ABI
> documents, this patch replaces the __uint128_t type with __uint128 and
> replaces __int128_t with __int128.
> Is this ok for trunk?
Looks good, thanks
Hi Kyrill,
On 07/26/2018 11:34 AM, Kyrill Tkachov wrote:
Hi Luis,
On 25/07/18 19:10, Luis Machado wrote:
The adjusted vector costs give Falkor a reasonable boost in
performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn't change INT
benchmarks that
much. About 0.7% for CPU2017 FP
Hi.
Following patch implements new predictors that annotates malloc-like functions.
These almost every time return a non-null value.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-07-26 Martin Liska
PR mi
Hi.
It's just a cosmetics change where I want to print 2 digits of fraction
part of heuristics probabilities. It helps to distinguish 100% from
PROB_VERY_LIKELY (99.96%).
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
201
On Fri, Jul 20, 2018 at 11:15 AM, H.J. Lu wrote:
> Tested on CET SDV using the CET kernel on cet branch at:
>
> https://github.com/yyu168/linux_cet/tree/cet
>
> OK for trunk and GCC 8 branch?
>
> Thanks.
>
>
> H.J.
> ---
> The CET kernel has been changed to place a restore token on shadow stack
>
On Thu, Jul 26, 2018 at 07:38:34AM -0700, H.J. Lu wrote:
> > PR target/86560
> > * asan/asan_interceptors.cc (swapcontext): Call REAL(swapcontext)
> > with indirect_return attribute on x86 if indirect_return attribute
> > is available.
> > * sanitizer_common/
On Fri, Jul 20, 2018 at 1:11 PM, H.J. Lu wrote:
> Cherry-pick compiler-rt revision 337603:
>
> When shadow stack from Intel CET is enabled, the first instruction of all
> indirect branch targets must be a special instruction, ENDBR.
>
> lib/asan/asan_interceptors.cc has
>
> ...
> int res = REAL(
Hi Luis,
On 25/07/18 19:10, Luis Machado wrote:
The adjusted vector costs give Falkor a reasonable boost in performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that
much. About 0.7% for CPU2017 FP and 1.54% for CPU2006 FP.
OK for trunk?
The patch looks
Hi Tom,
I see that you're reviewing the libgomp changes. Please disregard the
following hunk:
On 07/11/2018 12:13 PM, Cesar Philippidis wrote:
> @@ -1199,12 +1202,59 @@ nvptx_exec (void (*fn), size_t mapnum, void
> **hostaddrs, void **devaddrs,
>default_dims[GOMP_DIM_
On 07/26/2018 01:33 AM, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 5:30 PM Cesar Philippidis
> wrote:
>>
>> This patch teaches GCC to inform the user how it assigned parallelism
>> to each OpenACC loop at compile time using the -fopt-info-note-omp
>> flag. For instance, given the acc parallel
From: Jonathan Wakely
Tests for components which are no longer dependent on
_GLIBCXX_USE_C99_STDINT_TR1 do not need to require .
* testsuite/30_threads/recursive_mutex/cons/1.cc: Likewise.
* testsuite/30_threads/recursive_mutex/cons/assign_neg.cc: Likewise.
* testsuite/30
From: Jonathan Wakely
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: Add
dg-require-cstdint directive.
* testsuite/20_util/allocator/overaligned.cc: Likewise.
* testsuite/20_util/any/cons/aligned.cc: Likewise.
* testsuite/20_util/monotonic_buffer_re
From: Jonathan Wakely
Tests for components which are no longer dependent on
_GLIBCXX_USE_C99_STDINT_TR1 do not need to require .
* testsuite/18_support/numeric_limits/char16_32_t.cc: Qualify names
from namespace std.
* testsuite/20_util/align/2.cc: Remove dg-require-cstdi
From: Jonathan Wakely
Tests for components which are no longer dependent on
_GLIBCXX_USE_C99_STDINT_TR1 do not need to require .
* testsuite/30_threads/async/42819.cc: Remove dg-require-cstdint
directive.
* testsuite/30_threads/async/49668.cc: Likewise.
* testsuit
From: Jonathan Wakely
The throw_allocator extension depends on which depends on
_GLIBCXX_USE_C99_STDINT_TR1.
The Transactional Memory support uses fixed-width integer types from
.
* include/ext/throw_allocator.h [!_GLIBCXX_USE_C99_STDINT_TR1]
(random_condition, throw_value_rand
From: Jonathan Wakely
The char16_t and char32_t types are automatically defined by the
compiler and do not depend on support in . The char_traits
specializations depend on uint_leastNN_t but can be made to work anyway
by using the predefined macros, or as a last resort make_unsigned.
* i
From: Jonathan Wakely
std::__detail::__clp2 used uint_fast32_t and uint_fast64_t without
checking _GLIBCXX_USE_C99_STDINT_TR1 which was a potential bug. A
simpler implementation based on the new std::__ceil2 code performs
better and doesn't depend on types.
std::align and other C++11 functions
From: Jonathan Wakely
Currently huge swathes of the library are only enabled conditionally by:
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
This macro was created as part of the TR1 implementation, to detect whether
the C++98 compiler has access to a working header from C99. In
C++11 that header is requ
From: Jonathan Wakely
By adding fallback definitions of std::intmax_t and std::uintmax_t it's
possible to define without _GLIBCXX_USE_C99_STDINT_TR1. This in
turn allows most of to be defined, which removes the dependency
on _GLIBCXX_USE_C99_STDINT_TR1 for all of the C++11 concurrency features.
On 07/26/2018 02:26 PM, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 2:12 PM Martin Liška wrote:
>>
>> On 07/26/2018 01:34 PM, Richard Biener wrote:
>>> On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
Hi.
As requested in the PR, now we produce prefixes for temp files i
I wrote:
> Nicholas Koenig wrote:
>
> > Hello everyone,
> >
> > I have committed the async I/O patch as r262978.
> >
> > The test cases are in libgomp.fortran for now, maybe that can be changed
> > later.
>
> It looks like this broke building libgfortran on spu, and presumably
> any platform t
To improve internal consistency and to improve consistency with published ABI
documents, this patch replaces the __uint128_t type with __uint128 and replaces
__int128_t with __int128.
I have built and regression tested this patch on powerpc64le-unknown-linux with
no regressions. I have also bu
Nicholas Koenig wrote:
> Hello everyone,
>
> I have committed the async I/O patch as r262978.
>
> The test cases are in libgomp.fortran for now, maybe that can be changed
> later.
It looks like this broke building libgfortran on spu, and presumably
any platform that uses gthr-simple instead of
On Thu, Jul 26, 2018 at 3:06 PM Richard Earnshaw (lists)
wrote:
>
> On 26/07/18 13:41, Richard Biener wrote:
> > On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 25/07/18 14:47, Richard Biener wrote:
> >>> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
>
On 26/07/18 13:41, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 25/07/18 14:47, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
>>> wrote:
On 25/07/18 11:36, Richard Biener wrote:
> On Wed, Jul
>> Right, in fact there are two separate things you're trying to address
>> here: launch failure and occupancy heuristic, so split the patch.
> That hunk was small, so I included it with this patch. Although if you
> insist, I can remove it.
Please, for future reference, always assume that I insi
On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
wrote:
>
> On 25/07/18 14:47, Richard Biener wrote:
> > On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 25/07/18 11:36, Richard Biener wrote:
> >>> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
On Thu, Jul 26, 2018 at 2:12 PM Martin Liška wrote:
>
> On 07/26/2018 01:34 PM, Richard Biener wrote:
> > On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> As requested in the PR, now we produce prefixes for temp files in LTO:
> >>
> >> Example:
> >> $ gcc -flto main.o
On 24/07/18 15:12, Richard Biener wrote:
> On Tue, Jul 24, 2018 at 1:44 AM David Malcolm wrote:
>>
>> There are various ways that it's possible for a gimple statement to
>> have an UNKNOWN_LOCATION, and for that UNKNOWN_LOCATION to be wrapped
>> in an ad-hoc location to capture inlining informatio
> diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
> index 89326e57741..5022e462a3d 100644
> --- a/libgomp/plugin/plugin-nvptx.c
> +++ b/libgomp/plugin/plugin-nvptx.c
> @@ -1120,6 +1126,7 @@ nvptx_exec (void (*fn), size_t mapnum, void
> **hostaddrs, void **devaddrs,
>
On 07/26/2018 01:34 PM, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
>>
>> Hi.
>>
>> As requested in the PR, now we produce prefixes for temp files in LTO:
>>
>> Example:
>> $ gcc -flto main.o a.o --save-temps -o mybinary
>>
>> generates:
>> $ ls /tmp/mybinary*
>> /
> Content-Type: text/x-patch; name="trunk-libgomp-default-par.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename="trunk-libgomp-default-par.diff"
>From https://gcc.gnu.org/contribute.html#patches :
...
We prefer patches posted as plain text or as MIME parts of type
On Thu, Jul 26, 2018 at 01:16:42PM +0200, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:12 PM Segher Boessenkool
> wrote:
> >
> > The current code in reg_nonzero_bits_for_combine allows using the
> > reg_stat info when last_set_mode is a different integer mode. This is
> > completely wrong f
On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
>
> Hi.
>
> As requested in the PR, now we produce prefixes for temp files in LTO:
>
> Example:
> $ gcc -flto main.o a.o --save-temps -o mybinary
>
> generates:
> $ ls /tmp/mybinary*
> /tmp/mybinary /tmp/mybinary.ltrans0.o /tmp/mybinary.ltrans
On Thu, 26 Jul 2018 at 12:01, Tamar Christina wrote:
>
> Hi Thomas,
>
> > -Original Message-
> > From: Thomas Preudhomme
> > Sent: Thursday, July 26, 2018 09:29
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhakrishnan
> > ; Richard Earnshaw
> > ; ni...@redhat.co
On 26/07/18 13:11 +0200, Rainer Orth wrote:
Hi Jonathan,
Rainer, this is another place where alignof(max_align_t) gets encoded
into the ABI, so is affected by PR 77691 as well.
indeed, fixed by the following patch. Tested on i386-pc-solaris2.11,
ok for mainline?
OK, thanks.
The ugly thin
On Thu, Jul 26, 2018 at 12:29 PM Alexander Monakov wrote:
>
> Hi,
>
> when using explicit register variables ('register int foo asm("%ebp");'),
> using const/volatile type qualifiers on the declaration does not result in
> the logically expected effect.
>
> The main issue is that gcc-8 got "better
On Thu, Jul 26, 2018 at 12:12 PM Segher Boessenkool
wrote:
>
> The current code in reg_nonzero_bits_for_combine allows using the
> reg_stat info when last_set_mode is a different integer mode. This is
> completely wrong for non-pseudos. For example, as in the PR, a value
> in a DImode hard regis
On Thu, Jul 26, 2018 at 12:29 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Jul 25, 2018 at 1:09 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Tue, Jul 24, 2018 at 12:07 PM Richard Sandiford
> >> > wrote:
> >> >>
> >> >> This patch adds a patte
On Thu, Jul 26, 2018 at 1:10 PM Richard Sandiford
wrote:
>
> [Updated after new 37/46 and 38/46. 41 onwards are unaffected.]
>
> This patch replaces DR_VECT_AUX and vect_dr_stmt with a new
> vec_info::lookup_dr function, so that the lookup is relative
> to a particular vec_info rather than to glo
On Thu, Jul 26, 2018 at 1:08 PM Richard Sandiford
wrote:
>
> [Updated after new 37/46 and 38/46]
>
> After previous changes, it makes more sense for STMT_VINFO_UNALIGNED_DR
> to be dr_vec_info rather than a data_reference.
OK.
>
> 2018-07-26 Richard Sandiford
>
> gcc/
> * tree-vectori
On Thu, Jul 26, 2018 at 1:05 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Richard Biener writes:
> >> On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
> >> wrote:
> >>>
> >>> This patch makes various routines (mostly in tree-vect-data-refs.c)
> >>> take stmt_vec_infos rather
On Thu, Jul 26, 2018 at 12:55 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
> > wrote:
> >>
> >> Alignment information is really a property of a stmt_vec_info
> >> (and the way we want to vectorise it) rather than the original scala
Hi Jonathan,
> Rainer, this is another place where alignof(max_align_t) gets encoded
> into the ABI, so is affected by PR 77691 as well.
indeed, fixed by the following patch. Tested on i386-pc-solaris2.11,
ok for mainline?
The ugly thing about xfailing the affected tests is that they will XPASS
[Updated after new 37/46 and 38/46. 41 onwards are unaffected.]
This patch replaces DR_VECT_AUX and vect_dr_stmt with a new
vec_info::lookup_dr function, so that the lookup is relative
to a particular vec_info rather than to global state.
2018-07-26 Richard Sandiford
gcc/
* tree-vec
Hi Alexandre,
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Alexandre Oliva
> Sent: Thursday, July 26, 2018 08:46
> To: Tamar Christina
> Cc: Joseph Myers ; Jeff Law
> ; gcc-patches@gcc.gnu.org; nd ;
> bonz...@gnu.org; d...@redhat.com; nero...@gcc.gnu.org;
> r
[Updated after new 37/46 and 38/46]
After previous changes, it makes more sense for STMT_VINFO_UNALIGNED_DR
to be dr_vec_info rather than a data_reference.
2018-07-26 Richard Sandiford
gcc/
* tree-vectorizer.h (_loop_vec_info::unaligned_dr): Change to
dr_vec_info.
* t
Richard Sandiford writes:
> Richard Biener writes:
>> On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
>> wrote:
>>>
>>> This patch makes various routines (mostly in tree-vect-data-refs.c)
>>> take stmt_vec_infos rather than data_references. The affected routines
>>> are really dealing with t
Hi Thomas,
> -Original Message-
> From: Thomas Preudhomme
> Sent: Thursday, July 26, 2018 09:29
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: Re: [PATCH][GCC][Arm] Fix subreg crash in
Hi.
As requested in the PR, now we produce prefixes for temp files in LTO:
Example:
$ gcc -flto main.o a.o --save-temps -o mybinary
generates:
$ ls /tmp/mybinary*
/tmp/mybinary /tmp/mybinary.ltrans0.o /tmp/mybinary.ltrans0.s
/tmp/mybinary.ltrans.out
Patch can bootstrap on ppc64le-redhat-lin
Richard Biener writes:
> On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
> wrote:
>>
>> Alignment information is really a property of a stmt_vec_info
>> (and the way we want to vectorise it) rather than the original scalar dr.
>> I think that was true even before the recent dr sharing.
>
> But
Hi,
when using explicit register variables ('register int foo asm("%ebp");'),
using const/volatile type qualifiers on the declaration does not result in
the logically expected effect.
The main issue is that gcc-8 got "better" at propagating initializers of
'register const' variables to their uses
Richard Biener writes:
> On Wed, Jul 25, 2018 at 1:09 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Jul 24, 2018 at 12:07 PM Richard Sandiford
>> > wrote:
>> >>
>> >> This patch adds a pattern_stmt_p field to stmt_vec_info, so that it's
>> >> possible to tell whether t
Senthil Kumar Selvaraj writes:
> The below patch fixes a miscompilation of function calls with__memx address
> space
> arguments.
>
> For code like
>
> extern const __memx float a;
> extern const float b;
>
> int diff () { return a > b; }
>
> when compiled with -Os, a is never loaded and passe
The current code in reg_nonzero_bits_for_combine allows using the
reg_stat info when last_set_mode is a different integer mode. This is
completely wrong for non-pseudos. For example, as in the PR, a value
in a DImode hard register is set by eight writes to its constituent
QImode parts. The value
On 25/07/18 14:47, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 25/07/18 11:36, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
>>> wrote:
On 24/07/18 18:26, Richard Biener wrote:
> On Mon, Jul
On Thu, 26 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> I've noticed that while Jason documented the -fabi-version=13/-Wabi=12
> 8.2 fix in the C++ section, there is no mention of it in the 8.2 section,
> so if people just quickly look at what significant has changed in 8.2,
> they will not notice th
Hi!
I've noticed that while Jason documented the -fabi-version=13/-Wabi=12
8.2 fix in the C++ section, there is no mention of it in the 8.2 section,
so if people just quickly look at what significant has changed in 8.2,
they will not notice that.
This patch fixes the markup in Jason's changes et
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.
* cfgexpand.c (expand_gimple_stmt): Likewise.
* com
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 the .s file and only for one given O level.
I ran this bef
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.
(invalidate_from_clobbers): invalidate clobber highs.
(invalid
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.
(gen_hard_reg_clobber_high): New gen function.
* genconfig.c (wal
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.
* rtl.h (RTL_CHECKC3): Add macro.
(rtl_c
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.
2018-07-25 Alan Hayward
* rtl.h (reg_is_clobbered_by
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 high marker.
* lra-lives.c (process_bb_lives):
This is rebasing of the patch posted in November.
It's aim is to support aarch64 SVE register preservation around TLS calls
by adding a CLOBBER_HIGH expression.
Across a TLS call, Aarch64 SVE does not explicitly preserve the
SVE vector registers. However, the Neon vector registers are preserved.
D
1 - 100 of 115 matches
Mail list logo
