https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68897
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> > You just need to come up with a good name and implement a patch like the
> > ones shown in PR7651. Finding
On 10/16/19 6:11 AM, Richard Biener wrote:
The following makes sure we correctly identify a parm DIE created
early in a formal parameter pack during late annotation.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
OK?
OK, thanks.
Jason
On Sat, Oct 12, 2019 at 05:39:51PM -0500, Segher Boessenkool wrote:
> On Sat, Oct 12, 2019 at 10:13:16PM +0100, Iain Sandoe wrote:
> > For 32bit cases this isn't a problem since we can load/store to unaligned
> > addresses using D-mode insns.
>
> Can you? -m32 -mpowerpc64? We did have a bug
On 10/16/19 11:59 AM, Paolo Carlini wrote:
... the below, slightly extended patch: 1- Makes sure the
in_system_header_at calls surviving in decl.c get the same location used
for the corresponding diagnostic
Hmm, we probably want to change permerror to respect warn_system_headers
like warning
On 10/16/19 9:43 AM, Martin Sebor wrote:
> On 10/16/19 9:11 AM, Richard Sandiford wrote:
>> Sorry for the slow reply.
>>
>> Bernd Edlinger writes:
>>> Hi,
>>>
>>> this is probably on the border to obvious.
>>>
>>> The REGEXP_xxx macros in genautomata are invoked
>>> recursively, and the local
On 10/16/19 5:40 PM, Alan Lehotsky via DejaGnu wrote:
> The one example I found via a web search seems to want to do
> everything in the virtual machine - but I have to believe that’s
> going to be insanely slow…
Well, qemu is a virtual machine... Here's the ones I used for GNU
toolchain cross
I’m trying to grapple with connecting dejagnu to a QEMU simulator; not finding
any obvious examples to work with.
I’ve had a lot of familiarity using CGEN simulators connected to dejagnu, but
QEMU’s a new breed of cat….
Can anyone point me to a boards/.exp that is based on using QEMU, or
On 10/16/19, Jakub Jelinek wrote:
> On Wed, Oct 16, 2019 at 10:03:51AM -0600, Martin Sebor wrote:
>> > The counter example would be:
>> > #define F(x) \
>> >__extension__ (({ __typeof__ (x) _x = x; _x < 0 ? -_x : _x; }))
>> > #define G(x) \
>> >__extension__ (({ __typeof__ (x) _x = x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #6 from Steve Kargl ---
On Wed, Oct 16, 2019 at 10:57:05PM +, angus at agibson dot me wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
>
> --- Comment #5 from Angus Gibson ---
> I agree that it's not ideal...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #5 from Angus Gibson ---
I agree that it's not ideal... Unfortunately an awkward file format, and
fortran is usually the wrong language for this kind of IO anyway. I guess the
note that "A processor may prohibit some control
Segher Boessenkool writes:
> On Wed, Oct 16, 2019 at 09:04:18PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > This isn't canonical RTL. Does combine not simplify this?
>> >
>> > Or, rather, it should not be what we canonicalise to: nothing is defined
>> > here.
>>
>> But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #8 from Armin Rigo ---
I'd like to point out that the problem only shows up with all the extra lines
of code that appear unrelated: everything before the loop, and the first half
of the loop itself (the switch-with-goto with cases 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91363
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
I've found this stale reference while looking at cp-gimplify.c. tree-gimplify.c
no longer exists and its contents were merged into gimple.c.
Seems obvious enough.
gcc/cp/ChangeLog:
2019-10-16 Luis Machado
* cp-gimplify.c: Fix reference to non-existing tree-gimplify.c file.
On Mon, Oct 14, 2019 at 06:23:22PM -0600, Martin Sebor wrote:
>
> gcc/ChangeLog:
>
> PR tree-optimization/83821
> * tree-ssa-strlen.c (maybe_invalidate): Add argument. Consider
> the length of a string when available.
> + fprintf (dump_file,
> +
gcc/ChangeLog:
* config/i386/driver-i386.c (host_detect_local_cpu): Handle
icelake-client and icelake-server.
* testsuite/gcc.target/i386/builtin_target.c (check_intel_cpu_model):
Verify icelakes are detected correctly.
libgcc/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #7 from Armin Rigo ---
Created attachment 47056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47056=edit
made the example runnable
Here is a main(). Compare:
* gcc -Og foomin3.c foomin3main.c && a.out
* gcc -O1 foomin3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #6 from Jakub Jelinek ---
The reason the intersection gives [-INF, -8] is that compare_values (
-7, e.7_8 + 9223372036854775806 ) returns -1 rather than -2. And that is
because it thinks exactly 9223372036854775806 is added to
Thanks, Jason! I fixed those last things and I put the changelog below
in the e-mail. I'll figure out how to write a good changelog in a
commit message on the command line soon. :D
2019-10-16 JeanHeyd Meneide
gcc/
* escaped_string.h: New. Refactored out of tree.c
On Wed, Oct 16, 2019 at 09:04:18PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > This isn't canonical RTL. Does combine not simplify this?
> >
> > Or, rather, it should not be what we canonicalise to: nothing is defined
> > here.
>
> But when nothing is defined, let's match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #5 from Jakub Jelinek ---
Or, more likely the intersection into [-INF, -8] is incorrect.
Wilco Dijkstra writes:
> ping
>
> PR79262 has been fixed for almost all AArch64 cpus, however the example is
> still
> vectorized in a few cases, resulting in lower performance. Increase the cost
> of
> vector-to-scalar moves so it is more similar to the other vector costs. As a
> result
>
This finishes the part 1 of 2 patch submitted by Andrew Burgess on Aug 19.
This adds the argument registers but not t0 (aka x5) to SIBCALL_REGS. It
also adds the missing riscv_regno_to_class change.
Tested with cross riscv32-elf and riscv64-linux toolchain build and check.
There were no
On 10/15/19 8:31 PM, JeanHeyd Meneide wrote:
Attached is a patch for p1301 that improves in the way Jason Merrill
specified earlier
(https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00858.html)
Great, thanks!
This mail is missing ChangeLog entries. My guess is that you're using
git diff to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #4 from Jakub Jelinek ---
From what I can see, the weird + 0x7ffe is created when
extract_range_from_plus_minus_expr is called with PLUS_EXPR and VARYING and
long int [-INF, e.7_8 + -1] ranges.
/* Build the symbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67299
Miguel Saldivar changed:
What|Removed |Added
CC||saldivarcher at gmail dot com
---
On 10/16/19 12:27 PM, Jakub Jelinek wrote:
> On Fri, Oct 11, 2019 at 04:14:16PM -0400, Jason Merrill wrote:
>>> On x86_64 and most other targets, cleanup here (if non-NULL) is the
>>> CALL_EXPR, as destructor return type is void, but on arm, as the dtor return
>>> type is some pointer, the
On 10/16/19 12:27 PM, Jakub Jelinek wrote:
On Fri, Oct 11, 2019 at 04:14:16PM -0400, Jason Merrill wrote:
On x86_64 and most other targets, cleanup here (if non-NULL) is the
CALL_EXPR, as destructor return type is void, but on arm, as the dtor return
type is some pointer, the CALL_EXPR is
Here is a version with __detail::__copy and __detail::__copy_backward.
I prefered to introduce the __detail namespace cause __copy is quite a
common name so putting it in __detail namespace will I hope clarify that
it is for internal usage only.
I even hesitated to put more details into this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #7 from Witold Baryluk ---
Online examples: https://gcc.godbolt.org/z/Nyjty3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92127
--- Comment #1 from seurer at gcc dot gnu.org ---
Also this test:
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect
"vectorization not profitable" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #3 from Jakub Jelinek ---
The testcase is not very good because it is missing main and calling the
function with some arguments that will trigger the miscompilation.
Anyway, at least at -O2 it seems to be a VRP bug to me:
ao_31 =
Segher Boessenkool writes:
> Hi,
>
> [ Please don't use application/octet-stream attachments. Thanks! ]
>
> On Wed, Oct 16, 2019 at 04:24:29PM +, Yuliang Wang wrote:
>> +;; Unpredicated bitwise select.
>> +(define_insn "*aarch64_sve2_bsl"
>> + [(set (match_operand:SVE_I 0 "register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #2 from Armin Rigo ---
Created attachment 47054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47054=edit
slightly different version, with comments showing the expected values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #6 from Witold Baryluk ---
I also tested clang with LLVM 10~svn374655 and it does vectorize the loop
properly, even when both frequency and amplitude variables are updated every
loop.
It still doesn't inline calls to sinf, even if
Thanks for the patch, looks really good.
Yuliang Wang writes:
> +;; Use NBSL for vector NOR.
> +(define_insn_and_rewrite "*aarch64_sve2_nor"
> + [(set (match_operand:SVE_I 0 "register_operand" "=w, w, ?")
> + (unspec:SVE_I
> + [(match_operand 3)
> +(and:SVE_I
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92132
Bug ID: 92132
Summary: new test case gcc.dg/vect/vect-cond-reduc-4.c fails
with its introduction in r277067
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
--- Comment #19 from Iain Sandoe ---
(In reply to Zaak from comment #18)
> (In reply to Iain Sandoe from comment #17)
> > by the way, I haven't been able to find a C reproducer for this issue - if
> > you feel we should have a testcase for it
On Wed, Oct 16, 2019 at 10:03:51AM -0600, Martin Sebor wrote:
> PS The counterexample nicely illustrates why -Wself-init should
> be in -Wall like in Clang or MSVC, or at least in -Wextra like in
> ICC. Let me take it as a reminder to submit a patch for GCC 10.
c-family/c-gimplify.c says:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #5 from Witold Baryluk ---
As a bonus:
static float perlin1d(float x) {
float accum = 0.0f;
for (int i = 0; i < 8; i++) {
accum += powf(0.781f, i) * sinf(x * powf(2.131f, i));
}
return accum;
}
claims to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
--- Comment #8 from Martin Sebor ---
The test committed for the solution for pr83821 is disabled for all targets
except LP64 x86_64 to get around this limitation. Once this is implemented
across all targets the test should be enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 83821, which changed state.
Bug 83821 Summary: local aggregate initialization defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #4 from Witold Baryluk ---
If I reduce minimized test case even further:
only frequency update: VECTORIZED:
static float perlin1d(float x) {
float accum = 0.0f;
float amplitude = 1.0f;
float frequency = 1.0f;
for (int i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #1 from Armin Rigo ---
Comment on attachment 47053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053
creduce'd C source that miscompiles in -O>=1
BTW I just noticed that the reduced code is highly self-recursive, but that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821
--- Comment #6 from Martin Sebor ---
Author: msebor
Date: Wed Oct 16 19:24:36 2019
New Revision: 277080
URL: https://gcc.gnu.org/viewcvs?rev=277080=gcc=rev
Log:
PR tree-optimization/83821 - local aggregate initialization defeats strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
--- Comment #11 from Iain Sandoe ---
Author: iains
Date: Wed Oct 16 19:22:17 2019
New Revision: 277079
URL: https://gcc.gnu.org/viewcvs?rev=277079=gcc=rev
Log:
[Darwin] Pick up SDKROOT as the sysroot fallback.
For compatibility with xcrun and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #3 from Witold Baryluk ---
If only the frequency is updated in the inner loop:
frequency *= 2.131f;
function fill_data is vectorized:
mesh_minimal.c:34:3: optimized: loop vectorized using 64 byte vectors
mesh_minimal.c:33:13:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
Bug ID: 92131
Summary: incorrect assumption that (ao >= 0) is always false
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #2 from Witold Baryluk ---
Added a minimized test case that has only one outer loop, and f and h are
removed for simple inlined replacement.
Example diagnostic:
$ gcc -std=c17 -march=knm -O3 -ffast-math -fassociative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
--- Comment #1 from Witold Baryluk ---
Created attachment 47052
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47052=edit
Minimized test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92129
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
This patch (for the openacc-gcc-9-branch) reworks how the partitioning
level for OpenACC "private" variables is calculated and represented in
the compiler. There have been two previous approaches:
- The first (by Chung-Lin Tang) recorded which variables should be
made private per-gang in each
This patch adds support for AMD GCN offloading to the
libgomp.oacc-c-c++-common/serial-dims.c test case.
I will apply to the og9 branch shortly.
Thanks,
Julian
ChangeLog
libgomp/
* testsuite/libgomp.oacc-c-c++-common/serial-dims.c: Support AMD GCN.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92124
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
Hi,
[ Please don't use application/octet-stream attachments. Thanks! ]
On Wed, Oct 16, 2019 at 04:24:29PM +, Yuliang Wang wrote:
> +;; Unpredicated bitwise select.
> +(define_insn "*aarch64_sve2_bsl"
> + [(set (match_operand:SVE_I 0 "register_operand" "=w, ?")
> + (xor:SVE_I
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130
Bug ID: 92130
Summary: Missed vectorization for iteration dependent loads and
simple multiplicative accumulators
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92129
Bug ID: 92129
Summary: [10 Regression] ICE in vectorizable_reduction, at
tree-vect-loop.c:5869
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92117
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #4 from kargl at gcc dot gnu.org ---
Here's a self-contained program. AFAICT, pos= has an effect only within the
first record, and thereafter it is ignored.
F2018, 12.3.3.4(4) gives a bulleted list of things that can cause problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 47050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47050=edit
self-contained program
Dear Dave,
Thanks for sharing all of that! It was very helpful to read it
over again, and it was helpful in IRC yesterday.
As a bit of a "that was strange" moment, I ran the builds again
and did NOT do --disable-bootstrap with the patch on a different
machine. They built and ran fine,
On Wed, 16 Oct 2019 19:02:17 +0200
Jakub Jelinek wrote:
> On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote:
> > We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
> > When we process the arguments to:
> > __builtin_umul_overflow ((unsigned int) (-1), y,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63945
Witold Baryluk changed:
What|Removed |Added
CC||witold.baryluk+gcc at gmail
dot co
Hi,
Previously, the lto-wrapper communicates with ld by creating a pipe from
lto-wrapper's stdout to ld's stdin. This patch uses a temporary file for
this communication, releasing stdout to be used for debugging.
I've run a full testsuite and bootstrapped LTO in a linux x86_64, and found
no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 91996, which changed state.
Bug 91996 Summary: fold non-constant strlen relational expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91996
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91996
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92128
Martin Sebor changed:
What|Removed |Added
Blocks||83819
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92128
Bug ID: 92128
Summary: fold more non-constant strlen relational expressions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91996
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Wed Oct 16 17:18:57 2019
New Revision: 277076
URL: https://gcc.gnu.org/viewcvs?rev=277076=gcc=rev
Log:
PR tree-optimization/91996 - fold non-constant strlen relational expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114
--- Comment #2 from Steve Kargl ---
On Wed, Oct 16, 2019 at 05:02:50PM +, kargl at gcc dot gnu.org wrote:
> >
> > GNU Fortran (GCC) 7.4.0
This was released in Dec 2018, so ...
> This may have been fixed by
>
> r242802 | kargl |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote:
> We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
> When we process the arguments to:
> __builtin_umul_overflow ((unsigned int) (-1), y, );
> at expr.c:8952, they go through a few transformations.
>
>
On Wed, Oct 16, 2019 at 03:22:52PM +0200, Thomas Schwinge wrote:
> Stumbled over this while reviewing Julian's "Factor out duplicate code in
> gimplify_scan_omp_clauses":
> ..., which here gets writte to...
>
> > + if (base != decl)
> > + break;
> >
On Wed, 9 Oct 2019 16:03:34 +0200
Jakub Jelinek wrote:
> On Wed, Oct 09, 2019 at 02:40:42PM +0100, Jozef Lawrynowicz wrote:
> > I've added a new define_expand for msp430 to handle "mulhisi", but when
> > testing
> > the changes, some builtin tests (e.g. builtin-arith-overflow-{1,5,p-1}.c)
> >
On Wed, Oct 16, 2019 at 10:03:51AM -0600, Martin Sebor wrote:
> > The counter example would be:
> > #define F(x) \
> >__extension__ (({ __typeof__ (x) _x = x; _x < 0 ? -_x : _x; }))
> > #define G(x) \
> >__extension__ (({ __typeof__ (x) _x = x; F(_x); }))
> > where a -Wshadow diagnostics
The Arm port is failing bootstrap because GCC is now warning about an
unitialized array.
The code is complex enough that I certainly can't be sure the compiler
is wrong, so perhaps the best fix here is just to memset the entire
array before use.
* config/arm/arm.c
On Wed, 16 Oct 2019, Jakub Jelinek wrote:
> The counter example would be:
> #define F(x) \
> __extension__ (({ __typeof__ (x) _x = x; _x < 0 ? -_x : _x; }))
> #define G(x) \
> __extension__ (({ __typeof__ (x) _x = x; F(_x); }))
> where a -Wshadow diagnostics could point the author at a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92127
Bug ID: 92127
Summary: [10 regression]
gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr2
9925.c fails after r276645 on power7
Product: gcc
Version: 10.0
On Fri, Oct 11, 2019 at 04:14:16PM -0400, Jason Merrill wrote:
> > On x86_64 and most other targets, cleanup here (if non-NULL) is the
> > CALL_EXPR, as destructor return type is void, but on arm, as the dtor return
> > type is some pointer, the CALL_EXPR is wrapped into a NOP_EXPR to void.
> >
Hi,
This patch adds combine pass support for the following SVE2 bitwise logic
instructions:
- EOR3 (3-way vector exclusive OR)
- BSL (bitwise select)
- NBSL (inverted ")
- BSL1N (" with first input inverted)
- BSL2N (" with second input inverted)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91055
Kamlesh Kumar changed:
What|Removed |Added
CC||kamleshbhalui at gmail dot com
---
On 11/10/2019 00:08, Ramana Radhakrishnan wrote:
On Thu, Oct 10, 2019 at 7:06 PM Richard Sandiford
wrote:
Wilco Dijkstra writes:
ping
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
Hi!
On 2018-07-26T11:56:36+, ja...@gcc.gnu.org wrote:
> Files modified in the GCC repository. Log entry:
>
> Fix up a typo in the release year.
..., but the day also needs to be fixed. ;-)
Pushed to wwwdocs the attached commit
0dd4c6860fe284cef2df33ec98b2754c25d10438 "Fix GCC 8.2 release
On 10/16/19 9:50 AM, Jakub Jelinek wrote:
On Wed, Oct 16, 2019 at 09:43:49AM -0600, Martin Sebor wrote:
Should the warning trigger when the shadowing name results from
macro expansion? The author of a macro can't (in general) know
what context it's going to be used, and when different macros
... the below, slightly extended patch: 1- Makes sure the
in_system_header_at calls surviving in decl.c get the same location used
for the corresponding diagnostic; exploit locations[ds_typedef] in an
error_at in grokdeclarator.
Tested, as usual, on x86_64-linux.
Thanks, Paolo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92126
Bug ID: 92126
Summary: [10 regression] gcc.dg/vect/pr62171.c fails after
r276876 on power7
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On Wed, Oct 16, 2019 at 09:43:49AM -0600, Martin Sebor wrote:
> Should the warning trigger when the shadowing name results from
> macro expansion? The author of a macro can't (in general) know
> what context it's going to be used, and when different macros
> come from two different third party
On 10/16/19 9:11 AM, Richard Sandiford wrote:
Sorry for the slow reply.
Bernd Edlinger writes:
Hi,
this is probably on the border to obvious.
The REGEXP_xxx macros in genautomata are invoked
recursively, and the local values are all named _regexp
and shadow each other.
Fixed by using
On 16/10/2019 13:13, Wilco Dijkstra wrote:
Hi Christophe,
I've noticed that your patch caused a regression:
FAIL: gcc.dg/tree-prof/pr77698.c scan-rtl-dump-times alignments
"internal loop alignment added" 1
That's just a testism - it only tests for loop alignment and doesn't
consider the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78260
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92015
--- Comment #3 from Jakub Jelinek ---
Created attachment 47049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47049=edit
gcc10-pr92015.patch
Like this. Untested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92015
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92110
--- Comment #2 from Martin Sebor ---
The __builtin_warning patch implements the per-location solution
(https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html) but I think the more
aggregate approach would be more informative and so preferable.
On 10/16/19 9:03 AM, Mihailo Stojanovic wrote:
> Unnecessary moves around dpadd and dpsub are caused by different pseudos
> being assigned to the input-output operands which correspond to the same
> register.
>
> This forces the same pseudo to the input-output operands, which removes
> unnecesary
Sorry for the slow reply.
Bernd Edlinger writes:
> Hi,
>
> this is probably on the border to obvious.
>
> The REGEXP_xxx macros in genautomata are invoked
> recursively, and the local values are all named _regexp
> and shadow each other.
>
>
> Fixed by using different names _regexp1..6 for each
On 10/14/19 6:23 PM, Martin Sebor wrote:
> When a subsequent element or member of a local aggregate containing
> a prior character array is initialized the strlen pass discards
> the length it computed for the prior element/member. E.g., here:
>
> struct { char a[4], b[4]; } s = { "1", "12" };
On 10/15/19 3:24 PM, Martin Sebor wrote:
> The attached patch removes a FIXME added recently to the strlen
> pass as a reminder to extend the handling of multi-byte stores
> of characters copied from non-constant strings with constant
> lengths to strings with non-constant lengths in some known
i386.h has
#define CLEAR_RATIO(speed) ((speed) ? MIN (6, ix86_cost->move_ratio) : 2)
It is impossible to have CLEAR_RATIO > 6. This patch adds clear_ratio
to processor_costs, sets it to the minimum of 6 and move_ratio in all
cost models and defines CLEAR_RATIO with clear_ratio.
*
1 - 100 of 214 matches
Mail list logo
