On Jan 19, 2018, at 6:06 PM, Bill Schmidt wrote:
>
> I'm having a lot of heartburn over this because my test machine is
> experiencing disk slowdowns, so it's taking me up to 4 hours to complete
> a bootstrap and regression test.
Ah, the joys of crosses, no bootstrap. The gcc C testsuite runs i
On Jan 19, 2018, at 2:53 PM, Nathan Sidwell wrote:
> what do you think about deprecating the ARM-era for-scope handling
I endorse this idea. :-) 20 years is enough for anyone to update their code,
right? :-)
smime.p7s
Description: S/MIME cryptographic signature
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-7.2.0.es.po', has just
As Jakub says in the PR, the problem here was that the x86/built-in
version of the scatter support was using a bogus scatter_src_dt
when calling vect_get_vec_def_for_stmt_copy (and had since it
was added). The patch uses the vect_def_type from the original
call to vect_is_simple_use instead.
Howe
Hello Julia,
On 12 Jan 08:55, Koval, Julia wrote:
> Changelog
>
> gcc/
> * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
> _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask,
> _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
> _m
Boris Kolpackov:
> Ximin Luo writes:
>
>> Higher-level build scripts sometimes like to save CFLAGS etc into the build
>> output, making the overall build output unreproducible even if GCC is
>> playing
>> nicely. Rather than add logic to strip -f{file,debug,macro,...}-prefix-map,
>> into all
On January 20, 2018 11:35:12 AM GMT+01:00, Richard Sandiford
wrote:
>As Jakub says in the PR, the problem here was that the x86/built-in
>version of the scatter support was using a bogus scatter_src_dt
>when calling vect_get_vec_def_for_stmt_copy (and had since it
>was added). The patch uses the
> Date: Thu, 18 Jan 2018 05:25:20 +0200
> From: Eli Zaretskii
> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
>
> > From: DJ Delorie
> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
> > gdb-patc...@sourceware.org
> > Date: Wed, 17 Jan 2018 15:47:49 -
On Jan 19, 2018, at 10:48 PM, Bill Schmidt wrote:
>
> Hi,
>
> Here's another version of this patch incorporating the late-breaking news
> that the AIX assembler doesn't comprehend the "eq" symbol. Same as
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
> change to use
Hi Bill,
On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
> Here's another version of this patch incorporating the late-breaking news
> that the AIX assembler doesn't comprehend the "eq" symbol. Same as
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
> chan
On Jan 20, 2018, at 7:12 AM, Segher Boessenkool
wrote:
>
> Hi Bill,
>
> On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
>> Here's another version of this patch incorporating the late-breaking news
>> that the AIX assembler doesn't comprehend the "eq" symbol. Same as
>> https://g
On Sat, Jan 20, 2018 at 07:14:56AM -0600, Bill Schmidt wrote:
> On Jan 20, 2018, at 7:12 AM, Segher Boessenkool
> wrote:
> >
> > Hi Bill,
> >
> > On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
> >> Here's another version of this patch incorporating the late-breaking news
> >> tha
On January 20, 2018 4:34:20 AM GMT+01:00, Bill Schmidt
wrote:
>Forgot to mention, these have also been tested successfully as
>backports in
>gcc-7-branch. Okay to fix there as well?
OK.
Richard.
>Thanks,
>Bill
>
>> On Jan 19, 2018, at 9:31 PM, Bill Schmidt
> wrote:
>>
>> Hi,
>>
>> Here's
Hi!
I am seeing multiple assembler errors with error message "Error:
conditional branch out of range" for customer code.
The root cause of the bug is that conditional branches are generated
whose branch target ends up being too far away to be encoded in the
instruction. It appears that there was
Ximin Luo writes:
> Boris Kolpackov:
>
> > This does feel like we are trying to fix the issue in the wrong place.
> > Also, won't such broken packages normally store all options (including
> > -I) rather than just CFLAGS? And if the answer is no, then perhaps you
> > could put -ffile-prefix-map i
On Fri, Jan 19, 2018 at 5:42 PM, Bin Cheng wrote:
> Hi,
> This patch is supposed to fix regression caused by loop distribution when
> ftree-parallelize-loops. The reason is distributed memset call can't be
> understood/analyzed in data reference analysis, as a result, parloop can
> only paralleli
On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor wrote:
> On 01/19/2018 10:14 AM, Martin Sebor wrote:
>>
>> On 01/14/2018 07:29 AM, H.J. Lu wrote:
>>>
>>> When address of packed member of struct or union is taken, it may result
>>> in an unaligned pointer value. This patch adds
>>> -Waddress-of-pack
Boris Kolpackov:
> Ximin Luo writes:
>> Boris Kolpackov:
>>
>>> This does feel like we are trying to fix the issue in the wrong place.
>>> Also, won't such broken packages normally store all options (including
>>> -I) rather than just CFLAGS? And if the answer is no, then perhaps you
>>> could put
Hi!
On Fri, Jan 19, 2018 at 09:46:27PM -0600, Bill Schmidt wrote:
> Segher had previously requested some cleanups in
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01605.html.
> Due to time pressures, I delayed those, but they are ready now. Here they
> are,
> bootstrapped and tested on powerp
On Sat, Jan 20, 2018 at 8:31 AM, H.J. Lu wrote:
> On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor wrote:
>> On 01/19/2018 10:14 AM, Martin Sebor wrote:
>>>
>
>> After reading the Clang code review for the warning
>> (https://reviews.llvm.org/D20561) and experimenting with a few
>> more test cases I
The attache patch is a follow-up to my patch for
PR fortran/83900, which removed a bogus assert.
This allowed gfc_simplify_matmul to do its job,
except it did not properly set the type of the
result. The attach fixes that issue.
Regression tested on x86_64-*-freebsd.
OK to commit?
2018-01-20
On 01/20/2018 12:19 PM, Steve Kargl wrote:
> The attache patch is a follow-up to my patch for
> PR fortran/83900, which removed a bogus assert.
> This allowed gfc_simplify_matmul to do its job,
> except it did not properly set the type of the
> result. The attach fixes that issue.
>
> Regression
On Sat, Jan 20, 2018 at 9:50 AM, H.J. Lu wrote:
> On Sat, Jan 20, 2018 at 8:31 AM, H.J. Lu wrote:
>> On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor wrote:
>>> On 01/19/2018 10:14 AM, Martin Sebor wrote:
>>
>>> After reading the Clang code review for the warning
>>> (https://reviews.llvm.org/
On 01/19/2018 05:35 PM, Jakub Jelinek wrote:
> On Fri, Jan 19, 2018 at 05:33:10PM -0600, Daniel Santos wrote:
>> When stepping through tail-call restore stubs the debugger has to assume
>> that rsp - 8 is the CFA, although it is not. This is because I did not
>> explicitly add any .cfi directives.
Hi,
Somehow I never managed to commit the attached patch.
Better late than never.
Cheers,
Oleg? gcc7_rx_sh_update.patch
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1
On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii wrote:
>> Date: Thu, 18 Jan 2018 05:25:20 +0200
>> From: Eli Zaretskii
>> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
>> gdb-patc...@sourceware.org
>>
>> > From: DJ Delorie
>> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,
>> > gd
Hi,
The following fixed PR 80870.
For whatever reason one of the source files in config/sh was still
including and directly...
Committed as r256926 (trunk), r256928 (GCC 7), r256929 (GCC 6).
Cheers,
Oleg
gcc/ChangeLog:
PR target/80870
* config/sh/sh_optimize_sett_clrt.cc:
On 1/19/18, Nathan Sidwell wrote:
> Jason,
> what do you think about deprecating the ARM-era for-scope handling that
> allows:
>void f ()
>{
> for (int i = 0;;);
> i = 2;
>}
>
> we noisily accept that in c++98 mode with -fpermissive. It wasn't even
> well formed then. Imple
On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
> As far as adding tests, I guess I would need to dig into
> lib/gcc-gdb-test.exp to figure out how to do that.
The gdb-test infrastructure allows essentially
b linenumber
p something
p somethingother
Not sure if it would work if inst
29 matches
Mail list logo
