On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
Martin
>From 5450c99b54131d1942ece3ffb6bbe415b1c85151 Mon Sep 17 00:00:00 2001
On 5/19/20 10:23 AM, Jakub Jelinek wrote:
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
I find this format more helpful for the reasons below so unless your
script can be tweaked to do something similar I'd like to be able to
continue to use mine going forward with the new
On 5/15/20 5:06 PM, Martin Sebor wrote:
On 5/15/20 2:59 AM, Martin Liška wrote:
Hi.
Since we moved to git world and we're in the preparation for ChangeLog messages
being in git commit messages, I think it's the right time to also simplify mklog
script.
I'm sending a new version (which should
Hello.
We've just installed server git hooks that verify git messages
for a correct ChangeLog format. For a limited time period, please
still apply ChangeLog changes to the corresponding ChangeLog files.
We'll use it for comparison of auto-generated CangeLog entries.
The format is documented
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > I find this format more helpful for the reasons below so unless your
> > script can be tweaked to do something similar I'd like to be able to
> > continue to use mine going forward with the new infrastructure.
>
> Let's extend the
On 11/05/2020 17:43, Christophe Lyon via Gcc wrote:
> Hi,
>
>
> As you may know, I've been running validations of GCC trunk in many
> configurations for Arm and Aarch64.
>
>
> I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE, and
> ACLE tests because in several
FYI: I've verified that when building with GCC 10, outline atomics are
correctly initialized on LSE machines. The ld.so ELF constructors
eventually get run and initialize __aarch64_have_lse_atomics.
One minor improvement would be to document __aarch64_have_lse_atomics as
interposable on the GCC
On 5/19/20 10:53 AM, Martin Liška wrote:
On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
Martin
Ok, I'm going to install the
On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> This is really a wart in the GNU coding style. And one reason why I
> tend to indent such labels by a single space. It particularly affects
> things like class definitions where public, private, etc statements
> often appear in
I hope the offer by some of you to support people like me who Git
appears to hate with a fervor still stands? ;-)
And I volunteer to enhance our documentation if it appears useful.
Usecase: I've got a patch approved and pushed to HEAD, and approved
for active release branches -
On 19/05/2020 15:51, Michael Matz wrote:
> Hello,
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
>>> The common problems I remember is that e.g. when changing a function comment
>>> above some function, it is attributed to the previous function rather than
>>> following, labels in function
Hello,
On Tue, 19 May 2020, Martin Liška wrote:
> > The common problems I remember is that e.g. when changing a function comment
> > above some function, it is attributed to the previous function rather than
> > following, labels in function confusing it:
> > void
> > foo ()
> > {
> >
On Tue, 19 May 2020, Martin Liška wrote:
> On 5/19/20 10:11 AM, Martin Liška wrote:
> > Can you please share how do you do it? It would be easy to add it.
>
> I added the feature via --fill-up-bug-titles option. It uses common
> request and beatifulsoup packages.
The REST interface is much
On Tue, 19 May 2020 at 17:19, Gerald Pfeifer wrote:
>
> I hope the offer by some of you to support people like me who Git
> appears to hate with a fervor still stands? ;-)
>
> And I volunteer to enhance our documentation if it appears useful.
>
>
> Usecase: I've got a patch approved and pushed to
On Mai 19 2020, Gerald Pfeifer wrote:
> What now?
$ sudo zypper in git-merge-changelog
$ git config --global merge.merge-changelog.name "GNU-style ChangeLog merge
driver"
$ git config --global merge.merge-changelog.driver "git-merge-changelog %O %A
%B"
$ printf
On Tue, 19 May 2020 at 17:36, Jonathan Wakely wrote:
>
> On Tue, 19 May 2020 at 17:19, Gerald Pfeifer wrote:
> >
> > I hope the offer by some of you to support people like me who Git
> > appears to hate with a fervor still stands? ;-)
> >
> > And I volunteer to enhance our documentation if it
On 5/19/20 1:03 PM, Martin Sebor wrote:
I'm having trouble with the commit hook that tries to enforce
ChangeLog contents. It fails with an error that doesn't make
sense to me: the file it complains isn't mentioned clearly is
listed there and I can't tell what about how it's mentioned
the hook
On 5/19/20 9:19 PM, Martin Sebor via Gcc wrote:
Yep, that was it. It's one of those things that you can stare at
for minutes before you notice it.
Thank you for the report, it's 1:0 for the hook ;)
Next time, please CC me to a similar issue with the hook.
Martin
I'm having trouble with the commit hook that tries to enforce
ChangeLog contents. It fails with an error that doesn't make
sense to me: the file it complains isn't mentioned clearly is
listed there and I can't tell what about how it's mentioned
the hook is having a problem with.
Thanks
Martin
On 5/19/20 5:53 PM, Joseph Myers wrote:
On Tue, 19 May 2020, Martin Liška wrote:
On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
On Tue, 2020-05-19 at 13:03 -0600, Martin Sebor via Gcc wrote:
> I'm having trouble with the commit hook that tries to enforce
> ChangeLog contents. It fails with an error that doesn't make
> sense to me: the file it complains isn't mentioned clearly is
> listed there and I can't tell what about
On 5/19/20 1:26 PM, Martin Liška wrote:
On 5/19/20 9:19 PM, Martin Sebor via Gcc wrote:
Yep, that was it. It's one of those things that you can stare at
for minutes before you notice it.
Thank you for the report, it's 1:0 for the hook ;)
Next time, please CC me to a similar issue with the
On 5/19/20 1:11 PM, Marek Polacek wrote:
On Tue, May 19, 2020 at 01:03:09PM -0600, Martin Sebor via Gcc wrote:
I'm having trouble with the commit hook that tries to enforce
ChangeLog contents. It fails with an error that doesn't make
sense to me: the file it complains isn't mentioned clearly
On Tue, May 19, 2020 at 01:03:09PM -0600, Martin Sebor via Gcc wrote:
> I'm having trouble with the commit hook that tries to enforce
> ChangeLog contents. It fails with an error that doesn't make
> sense to me: the file it complains isn't mentioned clearly is
> listed there and I can't tell what
On Tue, 19 May 2020 at 09:26, Jakub Jelinek via Gcc wrote:
>
> On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > > I find this format more helpful for the reasons below so unless your
> > > script can be tweaked to do something similar I'd like to be able to
> > > continue to use
On 5/19/20 3:38 AM, Florian Weimer via Gcc wrote:
> One minor improvement would be to document __aarch64_have_lse_atomics as
> interposable on the GCC side and define that directly in glibc, so that
> lse-init.o is not linked in anymore and __aarch64_have_lse_atomics can
> be initialized as soon
Hello,
On Tue, 19 May 2020, Jakub Jelinek wrote:
> On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> > This is really a wart in the GNU coding style. And one reason why I
> > tend to indent such labels by a single space. It particularly affects
> > things like class
On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
>
> Hello.
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison
On Tue, 19 May 2020 at 17:13, Joseph Myers wrote:
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
> > On 5/19/20 10:11 AM, Martin Liška wrote:
> > > Can you please share how do you do it? It would be easy to add it.
> >
> > I added the feature via --fill-up-bug-titles option. It uses common
> >
On Tue, 19 May 2020 at 23:19, Jonathan Wakely wrote:
>
> On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
> >
> > Hello.
> >
> > We've just installed server git hooks that verify git messages
> > for a correct ChangeLog format. For a limited time period, please
> > still apply ChangeLog changes
I got:
$ git push origin releases/gcc-10
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 1.15 KiB | 1.15 MiB/s, done.
Total 8 (delta 7), reused 2 (delta 2), pack-reused
Hi,
We, EPI, SiPearl, and SiFive, have come out with a RFC for RISC-V
vector intrinsics. If you are interested in the RISC-V vector
intrinsics design, welcome to join the discussion. We have created a
github repository[0] for the documents.
In this RFC[1], we defined the type system, programming
This fixes an integer overflow warning that ultimatively happens because
of TREE_OVERFLOW propagating through transforms and the existing guard
against this,
375 if (TREE_OVERFLOW_P (ret)
376 && !TREE_OVERFLOW_P (op0)
377 && !TREE_OVERFLOW_P (op1))
378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
--- Comment #2 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #0)
> ```
> module t1;
>
> extern(C)
> private final int f() {
> return 5;
> }
> pragma(msg, f.mangleof);
>
> ```
>
> `gdc -c t1.d -o t1.o` results in object with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82531
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
--- Comment #3 from Martin Liška ---
> "writing 1 bytes into a region of size 0 -Wstringop-overflow=". Yet
> -Wno-stringop-overflow is passed to the compiler. I tried disabling the
> warning with #pragma diagnostic, no luck there.
I must
Jiufu Guo writes:
Hi,
I'd like to ping this patch for trunk on stage 1.
This patch could fix the issue on incorrect COUNT/FREQUENCES of loop
unrolled blocks, and also could help the improve the cold/hot issue of
the unrolled loops.
patch is also at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962
--- Comment #6 from Hongtao.liu ---
(In reply to Nemo from comment #5)
> (In reply to Jakub Jelinek from comment #2)
>
> I would be happy if GCC could just emit optimal code (single vcmpeqd
> instruction) for this useful constant:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Richard Biener changed:
What|Removed |Added
Known to fail||10.1.0
Keywords|
Committed, thanks :)
On Wed, May 13, 2020 at 6:37 AM Jim Wilson wrote:
> On Sun, Apr 12, 2020 at 7:54 PM Kito Cheng wrote:
> > On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote:
> > > Do we really need this now? It is a new feature not a bug fix, so it
> > > might be better to wait until we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Mon, May 18, 2020 at 8:21 PM Aldy Hernandez via Gcc-patches
wrote:
>
> As a follow-up to the patch moving array bounds checking into its own
> class, this moves the class into its own files. As I've mentioned
> previously, having it in tree-vrp just pollutes the file with unrelated
> stuff.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches
wrote:
>
> We already moved the value_range class into its own class in the last
> release. I think it's time to move the value_range_equiv stuff into its
> own class, as it's a distraction from the VRP code.
>
> I've moved it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95187
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
--- Comment #2 from Richard Biener ---
This is new behavior for warnings in GCC 10 and now how all other optimization
options behave - the option state is fixed per function at compile-time and
carried over to link-time.
Indeed warning options
This documents new GCC 10 behavior on diagnostic options and -flto.
Looks OK?
Thanks,
Richard.
2020-05-19 Richard Biener
PR lto/95190
* doc/invoke.texi (flto): Document behavior of diagnostic
options.
---
gcc/doc/invoke.texi | 8
1 file changed, 8
While bootstrapping GCC on S/390 the following warning is raised:
gcc/fortran/matchexp.c: In function 'match match_level_5(gfc_expr**)':
gcc/fortran/matchexp.c:401:18: error: 'e' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
401 |gfc_free_expr (e);
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95200
--- Comment #2 from Jonathan Wakely ---
Although the actual cause of the behaviour you see is due to violating a
different requirement. The explicit specialization hash is not
declared in map_obj.h which means it gets implicitly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95200
--- Comment #3 from Jonathan Wakely ---
That's [temp.expl.spec] paragraph 7:
If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that
On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
Martin
>From 5450c99b54131d1942ece3ffb6bbe415b1c85151 Mon Sep 17 00:00:00 2001
Am 19.05.20 um 04:16 schrieb H.J. Lu via Fortran:
Tested on Linux/x86 and Linux/x86-64. OK for master?
Libfortran parts are OK.
Regards
Thomas
Hello, Joseph, Andrew,
Thanks for your feedback.
On Feb 28, 2020, Joseph Myers wrote:
> On Fri, 28 Feb 2020, Alexandre Oliva wrote:
>> I'm not sure it's appropriate for the error to not omit the host
>> platform's executable suffix, just as it omits directory components from
>> argv[0], so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #14 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
commit r11-485-gf6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
Author: Uros Bizjak
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
On Mon, 18 May 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > Hi,
> >
> > I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
> > external and invariant SLP nodes to avoid (re-)computing that
> > in other places.
>
> Nice.
>
> > The responsible entity for specifying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:
https://gcc.gnu.org/g:a7c5803d4e56c6f6c84a9c5b08adffb0cfe1d79f
commit r10-8156-ga7c5803d4e56c6f6c84a9c5b08adffb0cfe1d79f
Author: Tobias Burnus
On 5/15/20 5:06 PM, Martin Sebor wrote:
On 5/15/20 2:59 AM, Martin Liška wrote:
Hi.
Since we moved to git world and we're in the preparation for ChangeLog messages
being in git commit messages, I think it's the right time to also simplify mklog
script.
I'm sending a new version (which should
Hi Thomas,
Thomas Schwinge writes:
> I can't formally approve testsuite patches, but did a review anyway:
Thanks for the review!
> On 2020-05-15T12:31:54+0200, Frederik Harwath
> wrote:
>> The dump
>> scanning procedures are changed to make the test unresolved
>> if globbing matches more
On May 19, 2020, Alexandre Oliva wrote:
> - fix spurious outputs.exp test failures on targets that do not support
> -gsplit-dwarf
cope with -gsplit-dwarf errors
From: Alexandre Oliva
On targets that did not support -gsplit-dwarf, we'd get tons of
spurious failures. This patch tests for
On May 19, 2020, Alexandre Oliva wrote:
> - fix a build problem when targeting platforms with an executable suffix
aux and dump revamp: fix target exec suffix handling
HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
that requires testing whether it's defined, rather than
On May 19, 2020, Alexandre Oliva wrote:
> - fix for outputs.exp for platforms with nonempty ldflags, libs,
> ldscripts, or output_format in the dejagnu board configuration, and
> for link tests with aux dumps in the testsuite when ldflags, libs or
> ldscripts in the board config name files
Martin Sebor writes:
>> By way of a random example from genrecog.c:
>>
>>int_set::iterator end
>> = std::set_union (trans1->labels.begin (), trans1->labels.end
>> (),
>> combined->begin (), combined->end (),
>>
Hello.
We've just installed server git hooks that verify git messages
for a correct ChangeLog format. For a limited time period, please
still apply ChangeLog changes to the corresponding ChangeLog files.
We'll use it for comparison of auto-generated CangeLog entries.
The format is documented
Messed up the e-mail addressed, gcc-patches now added.
Also, I note that I missed the PR fortran/50392 which should be inserted
at the start of the change log entries.
On 19/05/2020 08:49, Mark Eggleston wrote:
Please find attached patch for PR50392.
This patch was extracted from the
Am 18.05.20 um 09:35 schrieb Mark Eggleston:
> Please find attached a patch for PR39695 (this time it is attached).
>
> Commit message:
>
> Fortran : ProcPtr function results: 'ppr@' in error message PR39695
>
> The value 'ppr@' is set in the name of result symbol, the actual
> name of the symbol
Hi!
This patch adds very basic allocator support (omp_{init,destroy}_allocator,
omp_{alloc,free}, omp_[sg]et_default_allocator).
The plan is to use memkind (likely dlopened) for high bandwidth memory, but
that part isn't implemented yet, probably mlock for pinned memory and see
what other options
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > I find this format more helpful for the reasons below so unless your
> > script can be tweaked to do something similar I'd like to be able to
> > continue to use mine going forward with the new infrastructure.
>
> Let's extend the
I've refreshed the patch, approved back on Jan 22 for gcc-11, in
refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
patches on top of it, that I hope to get approved for folding and joint
installation:
- fix a build problem when targeting platforms with an executable suffix
-
On Tue, May 19, 2020 at 05:13:39PM +0800, Kito Cheng wrote:
> Run gcc testsuite with qemu will print out ascii color code like that:
>
> ^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error:
> ^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid
> argument^[[1m^[[0m^M
>
>
On Tue, 19 May 2020, Alexandre Oliva wrote:
> On May 19, 2020, Alexandre Oliva wrote:
>
> > - fix spurious outputs.exp test failures on targets that do not support
> > -gsplit-dwarf
>
> cope with -gsplit-dwarf errors
>
> From: Alexandre Oliva
>
> On targets that did not support
Hello!
Attached patch adds missing vector zero/sign_extend expanders to allow
vectorization of operations between different vector sizes.
The patch regresses (progresses?):
FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
"vec_unpack_lo" 3
but eyeballing the asm code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95200
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
On Sun, May 17, 2020 at 7:06 PM H.J. Lu wrote:
>
> Duplicate the cmpstrn pattern for cmpmem. The only difference is that
> the length argument of cmpmem is guaranteed to be less than or equal to
> lengths of 2 memory areas. Since "repz cmpsb" can be much slower than
> memcmp function
On Tue, 19 May 2020, Uros Bizjak wrote:
> Hello!
>
> Attached patch adds missing vector zero/sign_extend expanders to allow
> vectorization of operations between different vector sizes.
>
> The patch regresses (progresses?):
>
> FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
On Tue, May 19, 2020 at 10:48 AM Richard Biener wrote:
>
> On Tue, 19 May 2020, Uros Bizjak wrote:
>
> > Hello!
> >
> > Attached patch adds missing vector zero/sign_extend expanders to allow
> > vectorization of operations between different vector sizes.
> >
> > The patch regresses (progresses?):
On 5/19/20 10:23 AM, Jakub Jelinek wrote:
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
I find this format more helpful for the reasons below so unless your
script can be tweaked to do something similar I'd like to be able to
continue to use mine going forward with the new
On Tue, 19 May 2020, Alexandre Oliva wrote:
> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
> patches on top of it, that I hope to get approved for folding and joint
> installation:
Thanks again for doing
Run gcc testsuite with qemu will print out ascii color code like that:
^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error:
^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid argument^[[1m^[[0m^M
But the match logic in some testcase e.g c-c++-common/ubsan/builtin-1.c,
On 19/05/2020 09:08, Manfred Schwarb wrote:
Am 18.05.20 um 09:35 schrieb Mark Eggleston:
Please find attached a patch for PR39695 (this time it is attached).
Commit message:
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #3 from Antony Lewis ---
On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
does not (but 9.2.0 does)... so not exactly sure what this means about when it
was introduced.
On Tue, 19 May 2020, Alexandre Oliva wrote:
> On May 19, 2020, Alexandre Oliva wrote:
>
> > - fix a build problem when targeting platforms with an executable suffix
>
> aux and dump revamp: fix target exec suffix handling
>
> HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Uroš Bizjak changed:
What|Removed |Added
Keywords||easyhack
Assignee|ubizjak at
On 5/18/20 6:51 PM, Martin Sebor via Gcc-patches wrote:
On 5/18/20 12:02 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 5/16/20 4:43 AM, Richard Sandiford wrote:
Sorry for the empty subject line earlier...
Jason Merrill writes:
On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201
Bug ID: 95201
Summary: Some x86 vector-extend patterns are not exercised.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
BPF considers that every call to a function allocates a fresh set of
registers that are available to the callee, of which the first five
may have bee initialized with the function arguments. This is
implemented by both interpreter and JIT in the Linux kernel.
This is enforced by the kernel BPF
This patch adds support for a new option -mxbpf. This tells GCC to
generate code for an expanded version of BPF that relaxes some of the
restrictions imposed by BPF.
2020-05-19 Jose E. Marchesi
gcc/
* config/bpf/bpf.opt (mxbpf): New option.
* doc/invoke.texi (Option Summary):
Richard Biener writes:
> So I came up with this, yet another overload of vect_is_simple_use (ick).
> But at least for the two functions I tackled it seems to be straight-forward.
>
> I'll see to enforce a type on all invariants in vect_get_constant_vectors
> and thus try to adjust all other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82261
--- Comment #3 from Uroš Bizjak ---
(In reply to Michael Clark from comment #2)
> Just refreshing this issue. I found it while testing some code-gen on
> Godbolt:
The combiner creates:
Failed to match this instruction:
(parallel [
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #11 from Iain Sandoe ---
perhaps I have some invalid sharing of trees that only causes an issue for
ubsan - will try build independent dtor trees for the two cases.
On 5/19/20 10:53 AM, Martin Liška wrote:
On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
Martin
Ok, I'm going to install the
Hi,
the new contrib/gcc-changelog/git_check_commit.py script
(which, by the way, is very useful!) does not handle "Reviewed-by" and
"Reviewed-on" lines yet and hence it expects those lines to be indented
by a tab although those lines are usually not indented. The script
already knows about
Hi Jakub:
> s/Ditoo/Ditto/g
Thank for catching that.
> I think I'd prefer instead exporting some env var for all the ubsan
> tests in ubsan.exp that would disable the colorization.
Sounds like it's a better solution, it seems like it can be disable by
UBSAN_OPTIONS=color=never,
I'll try and
So I came up with this, yet another overload of vect_is_simple_use (ick).
But at least for the two functions I tackled it seems to be straight-forward.
I'll see to enforce a type on all invariants in vect_get_constant_vectors
and thus try to adjust all other vectorizable_* (but I'm sure I'll
Hi.
Older entries should be added first.
Installed.
contrib/ChangeLog:
* gcc-changelog/git_update_version.py:
Fill up entries in reverse order.
---
contrib/gcc-changelog/git_update_version.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, 19 May 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > So I came up with this, yet another overload of vect_is_simple_use (ick).
> > But at least for the two functions I tackled it seems to be
> > straight-forward.
> >
> > I'll see to enforce a type on all invariants in
Hi.
It's a small tweak to the newly added script.
Installed.
Martin
* mklog.py: Skip GTY for struct names. Make flake8 happy.
* test_mklog.py: Add test for GTY.
---
contrib/ChangeLog | 5 +
contrib/mklog.py | 12
contrib/test_mklog.py | 29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89386
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
1 - 100 of 311 matches
Mail list logo
