https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Thu Dec 13 07:58:42 2018
New Revision: 267076
URL: https://gcc.gnu.org/viewcvs?rev=267076=gcc=rev
Log:
PR target/88461
* config/i386/i386.md (*zero_extendsidi2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #2 from Anders Granlund ---
To what part of the standard are you refering to?
This is what I found and it allows the given program:
C11 standard 6.7.7: https://port70.net/~nsz/c/c11/n1570.html#6.7p7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #2 from Bence Szabó ---
Bisected, problem starts at r266345 ([PATCH][PR84877]Dynamically align the
address for local parameter copy on the stack when required alignment is larger
than MAX_SUPPORTED_STACK_ALIGNMEN).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
krux changed:
What|Removed |Added
CC||hoganmeier at gmail dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44313
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #1 from joseph at codesourcery dot com ---
I'd argue that the constraint "The type of the entity to be initialized
shall be an array of unknown size or a complete object type that is not a
variable length array type." must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
nik changed:
What|Removed |Added
CC||xerofoify at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #2 from Stefan Ring ---
Created attachment 45222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45222=edit
Preprocessed sample
g++ -c -O2 -x c++ prep
produces the shown code.
$ g++ -v
Using built-in specs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
Martin Sebor changed:
What|Removed |Added
Keywords||patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> See pr88116 for a description of what appears to be happening.
So, in array.c (gfc_match_array_constructor), we have this
bit of code
/* Walk the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
Bug ID: 88477
Summary: Variable with type completed in initializer not
allowed.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
--- Comment #2 from Daniel Fruzynski ---
I was playing with Compiler Explorer, to see how compilers optimize various
pieces of code. I found that next clang version (currently trunk) will be able
to analyze expressions which spans over vectors,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456
--- Comment #3 from Patrick Oppenlander ---
(In reply to jos...@codesourcery.com from comment #2)
> If the call is one GCC can't expand on its own (atomic operations on large
> objects needing locks, architecture lacks required atomic operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88213
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-linux-gnu |powerpc*-*-*
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88463
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 12 22:49:35 2018
New Revision: 267069
URL: https://gcc.gnu.org/viewcvs?rev=267069=gcc=rev
Log:
PR fortran/88463
* trans-openmp.c (gfc_omp_predetermined_sharing):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #17 from Marek Polacek ---
(In reply to denin from comment #16)
> (In reply to Marek Polacek from comment #14)
> > This is actually another problem, one that is tracked in PR86476.
>
> Hmm.
>
> $ cat wat.cpp
> struct Omg {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88476
Bug ID: 88476
Summary: Optimize expressions which uses vector, mask and
general purpose registers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #16 from denin at mail dot ru ---
(In reply to Marek Polacek from comment #14)
> This is actually another problem, one that is tracked in PR86476.
Hmm.
$ cat wat.cpp
struct Omg {
void f() {}
void g()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
Bug ID: 88475
Summary: -E -fdirectives-only clashes with raw strings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #15 from denin at mail dot ru ---
(In reply to Marek Polacek from comment #14)
> This is actually another problem, one that is tracked in PR86476.
So context closure is unduly greedy: members defined above are available while
those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87764
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88474
Bug ID: 88474
Summary: Inline built-in hypot for -ffast-math
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
--- Comment #4 from Harald Anlauf ---
(In reply to Stephan Kramer from comment #0)
Workaround:
> function make_list(i)
> integer, intent(in) :: i
> type(ilist), dimension(2) :: make_list
make_list = ilist()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88471
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88463
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
Bug ID: 88473
Summary: AVX512: constant folding on mask does not remove
unnecessary instructions
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88472
Bug ID: 88472
Summary: attribute documentation poorly structured, lots of
duplication
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725
--- Comment #10 from Daniel Richard G. ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>
> it would be helpful to know a bit more about that system: Solaris 10
> update release (e.g. from /etc/release), versions of as (as -V)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001
--- Comment #7 from Segher Boessenkool ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00865.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #14 from Marek Polacek ---
This is actually another problem, one that is tracked in PR86476.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80676
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #10 from Rich Felker ---
Indeed, I think the POSIX requirement is both in conflict with the requirements
of the C language and a bad requirement in itself.
As for what GCC should do, since there room for debate about which behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #4 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #3)
> The code in comment 2 compiles for me with -fdefault-integer-8 (I get the
> error without it).
Oh, now I see that the issue is -O1 and/or -Os,
whereas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88318
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Component|other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #9 from Martin Sebor ---
(In reply to jos...@codesourcery.com from comment #7)
Thanks, that has some useful background.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88318
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Wed Dec 12 19:45:45 2018
New Revision: 267063
URL: https://gcc.gnu.org/viewcvs?rev=267063=gcc=rev
Log:
Fix independent-cloneids-1.c testcase (PR88318)
The testcase uses REs like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #8 from Martin Sebor ---
The POSIX requirement prevents buffer overflow when the size of the destination
is incorrectly computed. I realize it's common practice to ignore snprintf
return value, but defensively written code should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88471
Bug ID: 88471
Summary: GCC suggests variables that are not of the right type
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
--- Comment #12 from trashyankes at wp dot pl ---
(In reply to H.J. Lu from comment #11)
> (In reply to trashyankes from comment #10)
>
> Which GCC are you using? GCC 8.2 generates:
GCC Explorer :D
g++ (GCC-Explorer-Build) 9.0.0 20181211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
--- Comment #3 from Daniel Fruzynski ---
This "null" ia an icc bug. Matt Godbolt from Compiler Explorer filed a bug with
Intel: ref 03997020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #7 from Jakub Jelinek ---
Created attachment 45220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45220=edit
gcc9-pr88464.patch
Completely untested patch for the AVX512F conditional gather vectorization
support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467
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=88116
--- Comment #7 from Steve Kargl ---
On Wed, Dec 12, 2018 at 04:59:21PM +, gs...@t-online.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116
>
> --- Comment #6 from G. Steinmetz ---
>
> (In reply to kargl from comment #5)
> > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #3 from Dominique d'Humieres ---
The code in comment 2 compiles for me with -fdefault-integer-8 (I get the error
without it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #4 from Iain Buclaw ---
Stepping through the backtrace, I see the following at Thread.initLocks
(core/thread.d around line 1719).
---
__gshared align(Mutex.alignof) void[__traits(classInstanceSize, Mutex)][2]
_locks;
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
--- Comment #10 from Jakub Jelinek ---
GCC 9 has omp_pause_resource and omp_pause_resource_all APIs as required by
OpenMP 5.0 for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #6 from Jakub Jelinek ---
See PR59617 for the masked gathers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #5 from Jakub Jelinek ---
We have:
else if (memory_access_type == VMAT_GATHER_SCATTER && gs_info.decl)
{
tree arglist = TYPE_ARG_TYPES (TREE_TYPE (gs_info.decl));
tree masktype
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 12 Dec 2018, msebor at gcc dot gnu.org wrote:
> I find the POSIX requirement to fail when n is greater than INT_MAX to be in
> conflict with C. I've submitted a defect to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88420
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #6 from Rich Felker ---
I don't see how the POSIX requirement makes the function safer. On the
contrary, it makes it less safe by introducing failure cases (that an
application might fail to check for, assuming it knows it has a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #5 from Martin Sebor ---
I find the POSIX requirement to fail when n is greater than INT_MAX to be in
conflict with C. I've submitted a defect to the Austin Group:
http://austingroupbugs.net/view.php?id=1219
At the same time, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
Peter Bergner changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88470
Bug ID: 88470
Summary: [9 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2354
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #4 from Jakub Jelinek ---
So, let's use a more complete testcase:
void
f1 (double * __restrict__ a, double const * __restrict__ b,
int const * __restrict__ off1, int const * __restrict__ off2, int n)
{
#pragma GCC ivdep
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456
--- Comment #2 from joseph at codesourcery dot com ---
If the implementation were not in this source file at all and no LTO were
used, it would be unambiguous that such an out-of-line implementation
would not be used when GCC knows how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
--- Comment #5 from Jonathan Wakely ---
(In reply to Duarte from comment #2)
> One option could be to just use whatever values linux uses :)
The linux kernel allows the cache line sizes to be set at boot (for some h/w)
which doesn't really map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88336, which changed state.
Bug 88336 Summary: Implement P0595R2, C++20 std::is_constant_evaluated
(compiler magic library tool).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88336
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88336
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
--- Comment #12 from Peter Bergner ---
Author: bergner
Date: Wed Dec 12 17:20:41 2018
New Revision: 267062
URL: https://gcc.gnu.org/viewcvs?rev=267062=gcc=rev
Log:
gcc/
Backport from mainline
2018-12-07 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
--- Comment #11 from Peter Bergner ---
Author: bergner
Date: Wed Dec 12 17:14:13 2018
New Revision: 267061
URL: https://gcc.gnu.org/viewcvs?rev=267061=gcc=rev
Log:
gcc/
Backport from mainline
2018-12-07 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88463
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
--- Comment #4 from Duarte ---
Oh, I see; thanks for pointing that out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762
--- Comment #3 from Jonathan Wakely ---
Fixed on trunk for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
--- Comment #2 from Daniel Fruzynski ---
I have logged issue for CompileExplorer to clarify this null instruction:
https://github.com/mattgodbolt/compiler-explorer/issues/1220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
--- Comment #3 from Jonathan Wakely ---
(In reply to Duarte from comment #0)
> It seems, however, that neither std::hardware_destructive_interference_size
> nor std::hardware_constructive_interference_size have been included in
> libstdc++.
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Bug ID: 88469
Summary: Unaligned stack access on arm (in particular armv5)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116
--- Comment #6 from G. Steinmetz ---
(In reply to kargl from comment #5)
> I don't know if you like to keep track of issues that you submit or not.
Maybe I could do better. But for the next couple of weeks,
I'm gonna take an absence from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88468
Bug ID: 88468
Summary: Arduino: 1.8.8 (Windows 10) internal compiler error ,
segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467
--- Comment #1 from G. Steinmetz ---
Detected, as noted in pr88116 comment 5 :
$ cat z4.f90
program p
print *, [integer :: 1, [integer(4) :: 2, '3']]
end
$ gfortran-9-20181209 -c z4.f90
z4.f90:2:44:
2 |print *, [integer :: 1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467
Bug ID: 88467
Summary: Silently accepts wrong array constructor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
--- Comment #5 from G. Steinmetz ---
A related test case, also changed between 20180909 and 20180916 :
$ cat z2.f90
program p
type t
integer :: n
end type
class(t) :: a, x
x = a
end
$ gfortran-9-20180909 -c z2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
--- Comment #2 from Duarte ---
I don't think it should be the min size. For example, architectures with 64bit
cache lines can have prefetchers that immediately fetch adjacent cache lines,
in which case the value should be 128.
One option could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
--- Comment #1 from Andrew Pinski ---
Hmm, these are interesting defined on some architures. On AARCH64, there are
at least two different values that can be defined here (I suspect it should be
the min of the two), 128 and 64 but architurially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88454
--- Comment #4 from samtebbs at gcc dot gnu.org ---
The split-path-11.c failure isn't happening on aarch64 and arm as of r267031
but the split-path-11.c failure still is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88454
samtebbs at gcc dot gnu.org changed:
What|Removed |Added
CC||samtebbs at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Wed Dec 12 16:13:49 2018
New Revision: 267057
URL: https://gcc.gnu.org/viewcvs?rev=267057=gcc=rev
Log:
Overload std::distance and std::advance for path::iterator
Although
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Dec 12 16:13:43 2018
New Revision: 267056
URL: https://gcc.gnu.org/viewcvs?rev=267056=gcc=rev
Log:
PR libstdc++/80762 avoid ambiguous __constructible_from
Ensure we don't try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
--- Comment #6 from Jakub Jelinek ---
Created attachment 45219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45219=edit
gcc9-pr88461-2.patch
Patch that seems to work for me (though, it adjusts just the vptest{,n}m
patterns and nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > pragma(msg, pthread_mutex_t.alignof);
> > pragma(msg, Mutex.alignof);
> > pragma(msg, Mutex.m_hndl.offsetof);
>
> I get
>
> 8u
> 4u
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
Bug ID: 88466
Summary: Support std::hardware_destructive_interference_size
and std:: hardware_constructive_interference_size
Product: gcc
Version: 9.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #4 from Thomas De Schampheleire
---
I am suffering from this same problem using gcc 7.3.0 on a Broadcom SDK.
Due to this, compiled object files increase from 90 KiB (using gcc 4.9.2) to 15
MiB (gcc 7.3.0). This size increase is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
--- Comment #5 from Jakub Jelinek ---
Created attachment 45218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45218=edit
gcc9-pr88461.patch
Patch I've tried, but it doesn't change anything on this testcase (not even if
I remove all those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
Bug ID: 88465
Summary: AVX512: optimize loading of constant values to kN
registers
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88356
Dominique d'Humieres changed:
What|Removed |Added
Keywords||error-recovery
1 - 100 of 167 matches
Mail list logo
