On Wed, Feb 13, 2019 at 12:43:32AM +, Joseph Myers wrote:
> On Wed, 13 Feb 2019, Jakub Jelinek wrote:
>
> > On Tue, Feb 12, 2019 at 11:21:04PM +, Joseph Myers wrote:
> > > I think this is changing architecture-independent code in a way that is
> > > not clearly safe based on the
From: Kito Cheng
This patch added a configure time option,
--with-riscv-attribute=[yes|no|default],
run time option, -mriscv-attribute to control the output of ELF attribute.
This feature is only enabled by default for ELF/Bare mental target
configuration.
Kito Cheng
Monk Chiang
From: Kito Cheng
Kito Cheng
Monk Chiang
ChangeLog:
gcc:
* common/config/riscv/riscv-common.c:
Include config/riscv/riscv-protos.h.
(INCLUDE_STRING): Defined.
(RISCV_DONT_CARE_VERSION): Defined.
(riscv_subset_t): Declare.
(riscv_subset_list):
This patch series is implementation of RISC-V ELF attribute[1], it consists of
two part, first part is improve the -march string parser, in order to support
arch string with version and all kind of extension in the RISC-V ISA spec
v2.2[2], and second part is attribute directive generation,
Hi,
In the gcc.backtrace module, either one of LibBacktrace or
UnwindBacktrace will always be defined. This patch gives
UnwindBacktrace a higher precedence over the libc backtrace as the
default backtrace handler as the latter depends on a rt.backtrace
module that is not compiled in.
Only
Covers for a generic fortran bug. The effect is that we'll needlessly
waste 64 bytes of stack space on some calls, but I don't see any
simple and fully correct patch in generic code. Bootstrapped and
regression tested powerpc64le-linux. OK mainline and branches?
PR target/87689
PING^1.
On 2/4/19 1:46 PM, Martin Liška wrote:
> 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
As seen in the PR, bump would be needed due to r268698.
Ready for GCC-8 branch?
Thanks,
Martin
gcc/ChangeLog:
2019-02-13 Martin Liska
PR lto/89260
* lto-streamer.h (LTO_minor_version): Bump version due
to r268698.
---
gcc/lto-streamer.h | 2 +-
1 file changed, 1
On 2/11/19 10:00 AM, Jan Hubicka wrote:
> Aha, yes, fundament of the patch is obvious - the barrier has to go :)
> There is same hunk of code in cfgrtl.c:1061, so please just merge it
> Note that I am not rtl reviewer. But as author of the code I would say
> that the updated patch can go in as
Hi.
This is patch candidate I created and tested. It's not adding
filtering based on opt_for_fn which I would defer to the next
stage1.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From d036f75a880bc91f67a5473767b35ba2f8a4ffe3 Mon
Hi.
The patch is very similar to r236460 where we should release dominance info
when the CFG is modified.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-02-12 Martin Liska
PR rtl-optimization/89242
Hi.
As Honza noticed, there's still some leftover from MPX removal.
May I remove another bunch of fields now, or should I wait
for next stage1?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
2019-02-13 Martin Liska
* builtins.h
Here we ICE because we're in a template and the constructor contains an
OVERLOAD, so calling check_narrowing -> maybe_constant_value crashes.
check_narrowing deliberately calls maybe_constant_value and not
fold_non_dependent_expr so as to avoid instantiating expressions twice.
So let's use
On Tue, Feb 12, 2019 at 4:43 PM Joseph Myers wrote:
>
> On Wed, 13 Feb 2019, Jakub Jelinek wrote:
>
> > On Tue, Feb 12, 2019 at 11:21:04PM +, Joseph Myers wrote:
> > > I think this is changing architecture-independent code in a way that is
> > > not clearly safe based on the
On Wed, 13 Feb 2019, Jakub Jelinek wrote:
> On Tue, Feb 12, 2019 at 11:21:04PM +, Joseph Myers wrote:
> > I think this is changing architecture-independent code in a way that is
> > not clearly safe based on the architecture-independent options design, in
> > order to address an
On Wed, Feb 13, 2019 at 12:51:26AM +0100, Eric Botcazou wrote:
> > The following hunk of code results in UB on the recently added testcase,
> > because if cmp_mode is SImode or DImode, then 1 << 32 or 1 << 64 is
> > undefined. Fixed by using GET_MODE_MASK, plus UINTVAL because size is
> > really
This patch fixes the gotools Makefile to remove some more test
directories when running `make mostlyclean`. It also cleans up the
chmod to avoid an error message when the directory does not exist.
This fixes PR 89193. Ran gotools tests, ran various make clean
targets on x86_64-pc-linux-gnu.
> The following hunk of code results in UB on the recently added testcase,
> because if cmp_mode is SImode or DImode, then 1 << 32 or 1 << 64 is
> undefined. Fixed by using GET_MODE_MASK, plus UINTVAL because size is
> really unsigned (code later on uses unsignedp=1 too).
Doesn't the current
Hi Martin,
> The attached patch removes the assumption introduced earlier today
> in my fix for bug 87996 that the valid_constant_size_p argument is
> a constant expression. I couldn't come up with a C/C++ test case
> where this isn't true but apparently it can happen in Ada which I
>
On Tue, Feb 12, 2019 at 11:21:04PM +, Joseph Myers wrote:
> I think this is changing architecture-independent code in a way that is
> not clearly safe based on the architecture-independent options design, in
> order to address an architecture-specific problem. The exclusion of
Actually, I
On Tue, 12 Feb 2019, H.J. Lu wrote:
> > > Prune joined switches with negation to allow -march=skylake-avx512 to
> > > override previous -march=native on command-line.
> > >
> > > PR driver/69471
> > > * opts-common.c (prune_options): Also prune joined switches
> > > with
Hi!
fold_binary_loc verifies that strlen argument is a pointer, but doesn't
verify what the pointee is.
The following patch just always converts it to the right pointer type
(const char *) and dereferences only that.
Another option would be punt if the pointee (TYPE_MAIN_VARIANT) is not
Hi!
As discussed recently on the mailing list, the norm2 simplification doesn't
work if we limit mpfr emin/emax to some values derived from maximum floating
exponents (and precision for denormals).
The following patch adjusts the computation, so that it is scaled down if
needed. In particular,
A proposed patch for Bug 88572 is attached to the bug report along
with a short description and Change Log (a link there gives a pretty
diff of the patch):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572#c15
I'd appreciate any review of this patch, as well as testing on more
platforms. The
Hi!
The following patch fixes ICE, when we try to split a double-word TLS load
or store. The problem is that x86_64_immediate_operand disallows CONST_INT
offsets with -mcmodel=large. I guess it is intentional for SYMBOL_REFs,
LABEL_REFs etc., but for the TLS LE UNSPECs it should be fine, there
Hi!
The following hunk of code results in UB on the recently added testcase,
because if cmp_mode is SImode or DImode, then 1 << 32 or 1 << 64 is
undefined. Fixed by using GET_MODE_MASK, plus UINTVAL because size is
really unsigned (code later on uses unsignedp=1 too).
Bootstrapped/regtested on
On Mon, Feb 11, 2019 at 1:38 PM Svante Signell wrote:
>
> On Mon, 2019-02-11 at 10:27 -0800, Ian Lance Taylor wrote:
>
> > It sound like the right fix is to use #ifdef WIFCONTINUED in
> > syscall/wait.c. If WIFCONTINUED is not defined, the Continued
> > function should always return 0.
> I can
On Tue, 12 Feb 2019 at 10:40, Richard Biener wrote:
>
> On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote:
> >
> > On Mon, 28 Jan 2019 at 13:10, Richard Biener
> > wrote:
> > >
> > > On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Following on
In this PR, we were unnecessarily rejecting a constexpr initializer_list
with no elements. This seems like a fairly useless degenerate case, but it
makes sense to avoid allocating an underlying array at all if there are no
elements and instead use a null pointer, like the initializer_list default
On Tue, Feb 12, 2019 at 12:24 PM Uros Bizjak wrote:
>
> On 2/12/19, H.J. Lu wrote:
> > On Tue, Feb 12, 2019 at 11:44 AM Uros Bizjak wrote:
> >>
> >> On Tue, Feb 12, 2019 at 8:35 PM H.J. Lu wrote:
> >> >
> >> > On Tue, Feb 12, 2019 at 5:43 AM Uros Bizjak wrote:
> >> > >
> >> > > On Mon, Feb
On 2/12/19, H.J. Lu wrote:
>> This way, it is clear that we enable alternative 0 only for native
>> mmx. It looks to me that we need to add similar treatment to a couple
>> of other patterns in sse.md, where we allow "y" constraint, e.g.
>> *vec_concatv2sf_sse, *vec_concatv2si_sse4_1, etc.
>>
>
On 2/12/19, H.J. Lu wrote:
> On Tue, Feb 12, 2019 at 11:44 AM Uros Bizjak wrote:
>>
>> On Tue, Feb 12, 2019 at 8:35 PM H.J. Lu wrote:
>> >
>> > On Tue, Feb 12, 2019 at 5:43 AM Uros Bizjak wrote:
>> > >
>> > > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>> > > >
>> > > > PR
On Tue, Feb 12, 2019 at 11:44 AM Uros Bizjak wrote:
>
> On Tue, Feb 12, 2019 at 8:35 PM H.J. Lu wrote:
> >
> > On Tue, Feb 12, 2019 at 5:43 AM Uros Bizjak wrote:
> > >
> > > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
> > > >
> > > > PR target/89021
> > > > *
Hi Pat,
On Tue, Feb 12, 2019 at 12:15:56PM -0600, Pat Haugen wrote:
> The options were removed in May 2018 (r260109), but documentation was not
> updated.
> 2019-02-12 Pat Haugen
>
> * doc/invoke.texi (RS/6000 and PowerPC Options): Remove duplicate
> -maltivec. Delete
On Tue, Feb 12, 2019 at 8:35 PM H.J. Lu wrote:
>
> On Tue, Feb 12, 2019 at 5:43 AM Uros Bizjak wrote:
> >
> > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
> > >
> > > PR target/89021
> > > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> > > mmx_ok to
On Tue, Feb 12, 2019 at 5:43 AM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
> >
> > PR target/89021
> > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> > mmx_ok to true if TARGET_MMX_WITH_SSE is true.
> >
Hi all,
The attached patch fixes a bug in recent work on OpenACC "kernels"
regions. Jumps within nested binds or try statements were not analyzed
correctly and could lead to ICEs.
Tested on x86_64 with offloading to NVPTX.
Thanks,
Gergö
Correctly handle nested bind and try statements in
On Tue, Feb 12, 2019 at 10:02 AM Uros Bizjak wrote:
>
> On Fri, Feb 8, 2019 at 12:29 PM H.J. Lu wrote:
> >
> > On Fri, Feb 8, 2019 at 1:51 AM Uros Bizjak wrote:
> > >
> > > On Thu, Feb 7, 2019 at 10:11 PM H.J. Lu wrote:
> > > >
> > > > OImode and TImode moves must be done in XImode to access
Hi,
This is a backport from phobos 2.084, the hppa changes that were
applied missed adding this one change in
allocator/building_blocks/region.d.
Bootstrapped and regression tested on x86_64-linux-gnu. Despite not
the ended target that's being fixed, only validates that scoping is
correct.
The options were removed in May 2018 (r260109), but documentation was not
updated.
Bootstrap on powerpc64le. Ok for trunk?
-Pat
2019-02-12 Pat Haugen
* doc/invoke.texi (RS/6000 and PowerPC Options): Remove duplicate
-maltivec. Delete -maltivec=be and -maltivec=le
On Fri, Feb 8, 2019 at 12:29 PM H.J. Lu wrote:
>
> On Fri, Feb 8, 2019 at 1:51 AM Uros Bizjak wrote:
> >
> > On Thu, Feb 7, 2019 at 10:11 PM H.J. Lu wrote:
> > >
> > > OImode and TImode moves must be done in XImode to access upper 16
> > > vector registers without AVX512VL. With AVX512VL, we
On Fri, Feb 8, 2019 at 3:09 PM H.J. Lu wrote:
>
> On Fri, Feb 8, 2019 at 3:02 PM H.J. Lu wrote:
> >
> > When -march=native is passed to host_detect_local_cpu to the backend,
> > it overrides all command lines after it. That means
> >
> > $ gcc -march=native -march=skylake-avx512
> >
> > is the
Hi Chung-Lin!
Happy New Year now to you, too! :-)
On Tue, 22 Jan 2019 22:52:09 +0800, Chung-Lin Tang
wrote:
> Hi, this is a rebase to current trunk and re-submission of the OpenACC Async
> re-organization work, aiming to commit when stage1 re-opens.
Thanks!
> This is technically
> the 2nd
On Mon, Feb 11, 2019 at 08:56:38PM -0600, Bill Schmidt wrote:
> It turns out that the new tests added today actually require POWER8 hardware
> at
> a minimum, since the vec_vsrad interface requires it. (Note that requiring
> P8 hardware obviates the need to specify -mvsx, so that is now
On Tue, Feb 12, 2019 at 12:36 AM Tom de Vries wrote:
>
> The call to bsearch in dwarf_lookup_pc can have NULL as base argument when
> the nmemb argument is 0. The base argument is required to be pointing to the
> initial member of an array of nmemb objects. It is not specified what
>
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> PR target/89021
> * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> mmx_ok to true if TARGET_MMX_WITH_SSE is true.
> (ix86_expand_vector_init_one_nonzero): Likewise.
>
I noticed that a 64-bit-default Solaris/SPARC gcc with -m32 doesn't
predefine __sparcv8, unlike the corresponding 32-bit-default compiler.
Since those defines happen in CPP_CPU_SPEC for any explicit -mcpu option
of v8, supersparc, v9 and beyond, this must be due to -mcpu being set in
the driver
Hi Alexander,
> It seems odd to me that the spec requires '(S+A) | T' instead of the (imho
> more intuitive) '(S|T) + A', but apart from the missing diagnostic from the
> linkers, it seems they do as they must and GCC was at fault.
Doing (S+A) | T means bit zero always correctly encodes the
On Tue, Feb 12, 2019 at 11:55:24AM +0100, Eric Botcazou wrote:
> > No, we should allow both integer and floating point insns for integer stores
> > always. We just get the cost estimates slightly wrong now, apparently.
>
> Note that my proof of concept patch doesn't disallow them either... So
Hi!
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00248.html
Thanks
Bernd.
On 2/5/19 4:07 PM, Bernd Edlinger wrote:
> Hi,
>
> due to the AAPCS parameter passing of 8-byte aligned structures, which happen
> to
> be 8-byte aligned or only 4-byte aligned in the
Ilya Leoshkevich wrote:
> gcc/ChangeLog:
>
> 2019-02-11 Ilya Leoshkevich
>
> PR target/89233
> * config/s390/s390.c (s390_decompose_address): Update comment.
> (s390_check_qrst_address): Reject invalid address forms after
> LRA.
>
> gcc/testsuite/ChangeLog:
>
>
Hi,
in the function MurmurHash3::put an unaligned access fault happens on an arm
system.
The linux kernel is able to emulate the unaligned LDM instruction, but it is
still not
desirable, to generate code that depends on that.
Fixed by the attached patch.
Bootstrapped and reg-tested on
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Allow MMX intrinsic emulation with SSE/SSE2/SSSE3. Don't enable MMX ISA
> by default with TARGET_MMX_WITH_SSE.
>
> For pr82483-1.c and pr82483-2.c, "-mssse3 -mno-mmx" compiles in 64-bit
> mode since MMX intrinsics can be emulated wit SSE.
>
>
On Tue, Feb 12, 2019 at 12:41:47PM +0100, Eric Botcazou wrote:
> > Ok, stand corrected on that, 128-bit indeed, but even that is nothing not
> > really used.
>
> The irony is that I'm doing this for 32-bit SPARC (we cannot get ASAN to work
> in 64-bit mode for the time being) and the maximum
> Ok, stand corrected on that, 128-bit indeed, but even that is nothing not
> really used.
The irony is that I'm doing this for 32-bit SPARC (we cannot get ASAN to work
in 64-bit mode for the time being) and the maximum alignment on 32-bit SPARC
is 64-bit (even long doubles) so this will be
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX version of palignrq with SSE version by concatenating 2
> 64-bit MMX operands into a single 128-bit SSE operand, followed by
> SSE psrldq. Only SSE register source operand is allowed.
>
> PR target/89021
> *
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX ssse3_phwv4hi3 with SSE by moving bits
> 64:95 to bits 32:63 in SSE register. Only SSE register source operand
> is allowed.
>
> PR target/89021
> * config/i386/sse.md (ssse3_phwv4hi3):
> Changed to
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX ssse3_phdv2si3 with SSE by moving bits
> 64:95 to bits 32:63 in SSE register. Only SSE register source operand
> is allowed.
>
> PR target/89021
> * config/i386/sse.md (ssse3_phdv2si3):
> Changed to
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX version of pshufb with SSE version by masking out the bit 3
> of the shuffle control byte. Only SSE register source operand is allowed.
>
> PR target/89021
> * config/i386/sse.md (ssse3_pshufbv8qi3): Renamed to ...
>
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX mmx_pmovmskb with SSE by zero-extending result of SSE pmovmskb
> from QImode to SImode. Only SSE register source operand is allowed.
>
> PR target/89021
> * config/i386/mmx.md (mmx_pmovmskb): Changed to
>
On Mon, Feb 11, 2019 at 11:55 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
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX packsswb/packssdw/packuswb with SSE packsswb/packssdw/packuswb
> plus moving bits 64:95 to bits 32:63 in SSE register. Only SSE register
> source operand is allowed.
>
> 2019-02-08 H.J. Lu
> Uros Bizjak
>
>
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX movntq with SSE2 movntidi. Only SSE register source operand
> is allowed.
Actually, it allows general register source operand.
>
> PR target/89021
> * config/i386/mmx.md (sse_movntq): Renamed to ...
>
> No, we should allow both integer and floating point insns for integer stores
> always. We just get the cost estimates slightly wrong now, apparently.
Note that my proof of concept patch doesn't disallow them either... So what
do you suggest? Just putting back the '*' modifiers in the DI
Committed attached patch to aarch64/sve-acle-branch.
Thanks,
Prathamesh
diff --git a/gcc/config/aarch64/aarch64-sve-builtins.c b/gcc/config/aarch64/aarch64-sve-builtins.c
index ed06db9b7c6..598411fb834 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.c
+++
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX maskmovq with SSE2 maskmovdqu in 64-bit mode by zero-extending
> source and mask operands to 128 bits. Handle unmapped bits 64:127 at
> memory address by adjusting source and mask operands together with memory
> address.
>
>
On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote:
>
> Emulate MMX sse_cvtpi2ps with SSE2 cvtdq2ps, preserving upper 64 bits of
> destination XMM register. Only SSE register source operand is allowed.
>
> PR target/89021
> * config/i386/mmx.md (UNSPEC_CVTPI2PS): New.
>
On Sun, Feb 10, 2019 at 11:07 PM Jan Hubicka wrote:
>
> Hi,
> I am attaching correct patch.
> The option is new only in a relative sense - it was added 5 years ago
> with the orinal ODR warning infrastructure.
> We have -Wodr-type-merging that controls streming data needed for -Wodr
> to work and
On Sun, 10 Feb 2019, Jan Hubicka wrote:
> > Hi,
> > this patch drops test for TYPE_NEEDS_CONSTRUCTING in tree.h and instead
> > sets TREE_READONLY to 0 for external vars of this type. For vars
> > declared locally we drop TREE_READONLY while expanding constructor.
> > Note that I have tried to
For review.
The attached patch and change logs is to treat SIGN in the same way as
DIM, MOD and MODULO in regard to the GNU extension i.e. when -std=gnu.
The change logs have no dates, they can be added when the patch is
committed provided this patch is accepted.
Note: I do not have write
On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote:
>
> On Mon, 28 Jan 2019 at 13:10, Richard Biener
> wrote:
> >
> > On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw wrote:
> > >
> > > Hi,
> > >
> > > Following on from the last, this adds target-zlib to target_libraries
> > > and updates libphobos
Hi,
The call to bsearch in dwarf_lookup_pc can have NULL as base argument when
the nmemb argument is 0. The base argument is required to be pointing to the
initial member of an array of nmemb objects. It is not specified what
constitutes a valid pointer to an array of 0 objects, but glibc
72 matches
Mail list logo
