https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
--- Comment #4 from rguenther at suse dot de ---
On December 12, 2020 8:36:07 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
>
>--- Comment #3 from Jakub Jelinek ---
>(In reply to
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
seen with 20201212 with a profiled bootstrap on arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
Bug ID: 98258
Summary: Can't compile programs for both OpenMP (CPU) + OpenACC
(GPU)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150
Chinoune changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150
Chinoune changed:
What|Removed |Added
Known to fail|10.1.0 |10.2.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98257
Bug ID: 98257
Summary: Replace Donald B. Johnson's cycle enumeration with
iterative loop finding
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #9 from Steve Kargl ---
On Sat, Dec 12, 2020 at 11:55:41PM +, damian at sourceryinstitute dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
>
> Damian Rouson changed:
>
>What|Removed
Piotr is the one spending most times on ensuring FreeBSD ports work
fine on POWER, so personally I'm happy to follow his recommendation
on such matters.
Okay for trunk and backports (GCC 10 at least)?
Gerald
gcc/ChangeLog:
2020-12-13 Piotr Kubaj
Gerald Pfeifer
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
Damian Rouson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227
--- Comment #5 from Jim Wilson ---
My bootstrap with ada succeeded. I used the same configure options except for
--prefix. make check is still running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #7 from Damian Rouson ---
I agree that it would have been better for image_distinct to be optional. I
co-hosted the 2018 WG5 meeting at which there were lengthy discussions around
random number generation. I don't recall whether
Snapshot gcc-10-20201212 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20201212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98256
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #4)
> Invalid expectation?
Not sure. This long response was composed before I saw Damian's reply.
At the risk of starting an existential argument,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #5 from Damian Rouson ---
Steve, thanks for all the time you put into implementing random_init and
responding to this PR. My confusion stemmed from the first sentence that I
quoted from the standard. It states that the provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
--- Comment #5 from Thomas Koenig ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561720.html
allows debugging of the generated variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150
Chinoune changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
11.0.0 20201212 (experimental) [master revision
ff2dfdef2f2:87144b47033:815eb852a2d293331eba2e241a986b8641d4da1f] (GCC)
[548] %
[548] % gcctk -O1 -c small.c
[549] %
[549] % gcctk -Os -c small.c
small.c: In function ‘g’:
small.c:3:6: error: definition in block 2 follows the use
3 | void g() { f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
--- Comment #3 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #2)
> Should already be handled by vectorizing the CTOR.
I've tried:
typedef int __attribute__((vector_size(16))) V;
V
foo (short *a)
{
return (V){a[0], a[1],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98252
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
compression algorithms: zlib
gcc version 11.0.0 20201212 (experimental) [master revision
ff2dfdef2f2:87144b47033:815eb852a2d293331eba2e241a986b8641d4da1f] (GCC)
[511] %
[511] % gcctk -Os small.c; ./a.out
[512] %
[512] % gcctk -Os -fPIC small.c
[513] % ./a.out
Segmentation fault
[514] %
[514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97455
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-12-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98252
--- Comment #2 from Azat ---
>If you compile your testcase with -fsanitize=undefined, you'll see that it
>invokes UB.
Jakub, Indeed I saw them, but is there any explanation (except "UB") why it
does copy by 16 if the memory overlaps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
--- Comment #5 from Dominique d'Humieres ---
The ICE is gone for GCC10.2.1 and 11.0.
Hello world,
I have struggled with debugging the GENERIC generated by the
Fortran front end because it is only possible to look at the
code via -fdump-tree-original, but it is not possible to
inspect the values; additionally, the D.3456 form makes it
hard to read which variable is which.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-12-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
--- Comment #2 from rguenther at suse dot de ---
On December 12, 2020 7:27:01 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
>
>Jakub Jelinek changed:
>
> What|Removed
On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool
wrote:
> On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> > seg...@kernel.crashing.org> έγραψε:
> > > > Ok, to speed things up, is it ok if I simply pick the patch that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98252
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #9 from Steve Kargl ---
On Sat, Dec 12, 2020 at 05:54:43PM +, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
>
> --- Comment #8 from Paul Thomas ---
> The example that you give shows that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #43 from abebeos at lazaridis dot com ---
The patch is now (after further validation zero regressions within gcc/g++
testsuite in 2 different test-setups) "out there":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #3 from kargl at gcc dot gnu.org ---
Third thought. Here are the programs you meant to write (without error
checking such as how_to_use_random_init must be run before
how_to_seed_with_random_seed_like_random_init).
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #8 from Paul Thomas ---
The example that you give shows that setting the undefined part to zero
certainly is not correct. I updated my tree for the commit and am only just now
rebuilding. It'll be tomorrow before I put this right.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #2 from kargl at gcc dot gnu.org ---
On 2nd thought.
Of course, the results are different.
In your first example, you have
call random_init(repeatable=.true., image_distinct=.true.)
which gets you processor-dependent seeds. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
Bug ID: 98254
Summary: Failure to optimize simple pattern for
__builtin_convertvector
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98003
--- Comment #5 from dave.anglin at bell dot net ---
There is no --as-needed support.
I think either approach would simplify things as most targets don't need to
link against libatomic.
On Sat, Dec 12, 2020 at 08:55:01AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Actually, seems we diagnose goto out of it, so perhaps for trunk
> the best thing forward is to add the noexcept block around target data
> body, but I think we still don't really need the omp return, omp-expand
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #7 from Steve Kargl ---
On Sat, Dec 12, 2020 at 04:02:54PM +, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
>
> --- Comment #6 from Paul Thomas ---
> (In reply to kargl from comment #4)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #3 from Matthias Klose ---
I still see this with 20201212,
54f75d8fb3f:a415eda93e0:cc9b9c0b68233d38a26f7acd68cc5f9a8fc4d994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
Bug ID: 98253
Summary: Conflicting random_seed/random_init results
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #6 from Paul Thomas ---
(In reply to kargl from comment #4)
> (In reply to Paul Thomas from comment #3)
>
> > function kn1() result(hm2)
> > complex :: hm(1:2), hm2(1:2)
> > data (hm(md)%re, md=1,2)/1.0, 2.0/
> > hm2 =
Hi!
On Sat, Dec 12, 2020 at 12:17:19PM +0100, John Paul Adrian Glaubitz wrote:
> >> I'd ask the original author, but it seems he's busy with other work, so to
> >> avoid delays...
> >
> > Please try to ask him first? That is always nice, but you all also need
> > to figure out what to do with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #5 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:ff2dfdef2f2e01c579dd280daa1d81fbeb4d7ac5
commit r11-5959-gff2dfdef2f2e01c579dd280daa1d81fbeb4d7ac5
Author: Paul Thomas
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
Hi Paul,
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Looks good. Thanks a lot for the patch!
Best regards
Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0bd675183d94e6bca100c3aaaf87ee9676fb3c26
commit r11-5958-g0bd675183d94e6bca100c3aaaf87ee9676fb3c26
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fe78528c05fdd562f21e12675781473b0fbe892e
commit r11-5957-gfe78528c05fdd562f21e12675781473b0fbe892e
Author: Jakub Jelinek
Date:
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Paul
2020-12-12 Paul Thomas
gcc/fortran
PR fortran/98022
* data.c (gfc_assign_data_value): Handle inquiry references in
the data statement object list.
On Sat, Dec 12, 2020 at 02:00:49PM +0100, Marc Glisse wrote:
> > Extending it to non-constants is what I wanted to avoid.
> > For ~(X + Y), because + is commutative, it wouldn't be a canonicalization
> > as it would pick more-less randomly whether to do ~X + Y or X + ~Y.
>
> ~X - Y or ~Y - X I
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
On Sat, Dec 12, 2020 at 01:25:39PM +0100, Marc Glisse wrote:
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for
On Sat, Dec 12, 2020 at 01:25:39PM +0100, Marc Glisse wrote:
> On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
>
> > This patch adds the ~(X - Y) -> ~X + Y simplification requested
> > in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
> > be safely negated.
>
> Would
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
be safely negated.
Would it have been wrong to produce ~X - C without caring about negating
(and then
Avoid the possibility of code discrepancies like one fixed with the
previous change and improve the structure of code by selecting between
push and non-push operations in a single place in `vax_output_int_move'.
The PUSHAB/MOVAB address moves are never actually produced from this
code as the
Check the output operand for representing pushing a value onto the stack
rather than the constant 0 input in determining whether to use the PUSHL
or the CLRL instruction for a SImode move. The latter actually works by
means of using the predecrement addressing mode with the SP register and
Hi,
While working on QMATH DImode add/sub fixes I have spotted an issue with
the push operation. Here's a small patch series that addresses it.
Lightly-verified with the `vax-netbsdelf' target and the C frontend test
suite only as I need to have hardware available for a Linux kernel project
Hello!
>> I'd ask the original author, but it seems he's busy with other work, so to
>> avoid delays...
>
> Please try to ask him first? That is always nice, but you all also need
> to figure out what to do with the bounty.
Going through the messages in this thread, my suggestion would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98252
Bug ID: 98252
Summary: gcc 10 unaligned copy (with tree-loop-vectorize)
produce wrong result
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
On December 12, 2020 9:01:50 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following patch recognizes another form of hand written
>__builtin_add_overflow (this time _p), in particular when
>the code does unsigned
>if (x > ~0U - y)
>or
>if (x <= ~0U - y)
>it can be optimized (if the subtraction
On December 12, 2020 9:10:41 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>This patch adds the ~(X - Y) -> ~X + Y simplification requested
>in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
>be safely negated.
>
>The first two simplify blocks is what has been requested in the PR
Fortran: Fix some select rank issues [PR97694 and 97723].
Hi All,
Unlike select type, select rank selectors retain the allocatable attribute.
This is corrected by the chunk in check.c. Note the trailing whitespace
corrections. Resolution of select rank construct must be done in the same
way as
Hi!
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
be safely negated.
The first two simplify blocks is what has been requested in the PR
and that makes the first testcase pass.
Unfortunately, that change also
Hi!
The following patch recognizes another form of hand written
__builtin_add_overflow (this time _p), in particular when
the code does unsigned
if (x > ~0U - y)
or
if (x <= ~0U - y)
it can be optimized (if the subtraction turned into ~y is single use)
into
if (__builtin_add_overflow_p (x, y,
65 matches
Mail list logo
