[Bug c/94573] New: Optimizer produces suboptimal code related to -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94573
Bug ID: 94573
Summary: Optimizer produces suboptimal code related to
-fstore-merging
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known init the array C16DD is always
consecutive, so we can use the more bigger mode size.
test base on the x86-64 gcc 9.2 on https://gcc.godbolt.org/, now it is still
handled DWORD by DWORD, and we except optimize it with QWORD or more bigger
size.
extern signed int C16DD[43][12];
void C1F93(int index)
{
C16DD[index][0] = 0;
C16DD[index][1] = 0;
C16DD[index][2] = 0;
C16DD[index][3] = 0;
C16DD[index][4] = 0;
C16DD[index][5] = 0;
C16DD[index][6] = 0;
C16DD[index][7] = 0;
return;
}
= related assemble =
C1F93(int):
movsx rdi, edi
lea rax, [rdi+rdi*2]
sal rax, 4
mov DWORD PTR C16DD[rax], 0
mov DWORD PTR C16DD[rax+4], 0
mov DWORD PTR C16DD[rax+8], 0
mov DWORD PTR C16DD[rax+12], 0
mov DWORD PTR C16DD[rax+16], 0
mov DWORD PTR C16DD[rax+20], 0
mov DWORD PTR C16DD[rax+24], 0
mov DWORD PTR C16DD[rax+28], 0
ret
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE and PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 Alan Modra changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Summary|On powerpc, |On powerpc, |-ffunction-sections |-ffunction-sections |-fdata-sections is not as |-fdata-sections is not as |effective as expected for |effective as expected for |non-PIE executables.|PIE and PIC --- Comment #6 from Alan Modra --- For -fPIC or -fPIE on ppc32 gcc uses a per-object file compiler managed GOT (.got2). Fixed position code doesn't use a GOT. -fpic/-fpie uses a linker managed GOT but with limited size. So, correcting the summary. The problem reported here is due to the per-object file nature of .got2. (.got2 is similar to the per-object file ppc64 .toc, where compiling the testcase with -mcmodel=large gives the same link failure.) To handle -gc-sections properly, ld needs to treat .got2 specially so that a relocation reference to .got2 does not mark .got2 but rather the section referenced by the relevant .got2 entry, and then remove unneeded .got2 entries. No one has cared enough to write such linker support for ppc32 or for large code model ppc64 .toc. Alternatively gcc code generated for -fPIC/-fPIE could be changed, but again no one has cared enough to do that. Since it is very unlikely that a bugzilla entry for gcc or binutils will prompt anyone to write the necessary linker support or change gcc, I'm closing this as won't fix.
[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569 --- Comment #2 from Inbal Levi --- Yes, you're probably right, got the wrong one. Thanks!
[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569 Richard Smith changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #1 from Richard Smith --- I believe the particular rule that is violated by this example is [dcl.align]p5: "The combined effect of all alignment-specifiers in a declaration shall not specify an alignment that is less strict than the alignment that would be required for the entity being declared if all alignment-specifiers appertaining to that entity were omitted."
[Bug c++/94564] C++20: Three-way comparison between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94564 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-13 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/94572] Expunge references to direct-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94572 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2020-04-13 Status|UNCONFIRMED |ASSIGNED Keywords||internal-improvement
[Bug c++/94572] New: Expunge references to direct-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94572 Bug ID: 94572 Summary: Expunge references to direct-declarator Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- The direct-declarator production was removed in CWG 681 but we still have many references to it in the codebase. This makes it harder to navigate. $ grep -n direct.declarator cp/*.c cp/cxx-pretty-print.c:1614:/* direct-declarator: cp/cxx-pretty-print.c:1616: direct-declarator ( parameter-declaration-clause ) cv-qualifier-seq(opt) cp/cxx-pretty-print.c:1622:cxx_pretty_printer::direct_declarator (tree t) cp/cxx-pretty-print.c:1667: c_pretty_printer::direct_declarator (t); cp/cxx-pretty-print.c:1673: direct-declarator cp/cxx-pretty-print.c:1679: direct_declarator (t); cp/parser.c:2238:static cp_declarator *cp_parser_direct_declarator cp/parser.c:2681:static cp_declarator * cp_parser_make_indirect_declarator cp/parser.c:3944:cp_parser_make_indirect_declarator (enum tree_code code, tree class_type, cp/parser.c:8963: declarator = cp_parser_make_indirect_declarator cp/parser.c:15128: declarator = cp_parser_make_indirect_declarator cp/parser.c:20947: direct-declarator cp/parser.c:20957: attributes [opt] direct-declarator cp/parser.c:20981: the declarator is a direct-declarator of the form "(...)". cp/parser.c:21045: declarator = cp_parser_make_indirect_declarator cp/parser.c:21048: /* Everything else is a direct-declarator. */ cp/parser.c:21054: declarator = cp_parser_direct_declarator (parser, dcl_kind, cp/parser.c:21064:/* Parse a direct-declarator or direct-abstract-declarator. cp/parser.c:21066: direct-declarator: cp/parser.c:21068: direct-declarator ( parameter-declaration-clause ) cp/parser.c:21072: direct-declarator [ constant-expression [opt] ] cp/parser.c:21087: we are parsing a direct-declarator. It is cp/parser.c:21096:cp_parser_direct_declarator (cp_parser* parser, cp/parser.c:41908:/* Finalize #pragma omp declare simd clauses after direct declarator has cp/parser.c:42965:/* Finalize #pragma acc routine clauses after direct declarator has
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
--- Comment #6 from Marek Polacek ---
See Daniel's testcase for why this is more important than it might seem:
template
bool test(T*)
{
return true;
}
int main()
{
test((int*)(nullptr));
}
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Marek Polacek changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #5 from Marek Polacek --- *** Bug 94563 has been marked as a duplicate of this bug. ***
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Marek Polacek changed: What|Removed |Added Assignee|beliveau0213 at gmail dot com |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Mine, for GCC 11.
[Bug c++/94563] Relational operations between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94563 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Marek Polacek --- Dup, I'll adjust it for GCC 11. *** This bug has been marked as a duplicate of bug 87699 ***
[Bug c++/94571] Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571 --- Comment #1 from Joel Yliluoma --- | ^ (Missing line from the paste) The problem exists since GCC 7. (GCC 6 and earlier did not support structured bindings.)
[Bug c++/94571] New: Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571
Bug ID: 94571
Summary: Error: Expected comma or semicolon, comma found
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
void foo()
{
int test1[2], test2[2];
auto [a,b] = test1, [c,d] = test2;
}
The error message given for this (invalid) C++17 code is a bit confusing.
tmp.cc: In function ‘void foo()’:
tmp.cc:4:23: error: expected ‘,’ or ‘;’ before ‘,’ token
4 | auto [a,b] = test1, [c,d] = test2;
You expected comma, found comma. So what is the problem? The proper error
message would be to only expect a semicolon.
[Bug gcov-profile/94570] New: -fprofile-dir is broken on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
Bug ID: 94570
Summary: -fprofile-dir is broken on Cygwin
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: john at selbie dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The following bug is unique to gcc and g++ running on Cygwin. I can repro this
on both gcc 9.2 and 9.3.
Using almost any source file, execute the following to start the first phase of
a profile guided optimization on Cygwin with a target directory to store .gcda
files:
$ g++ anyprogram.cpp -o anyprogram -fprofile-generate -fprofile-dir=profiledata
Then run the compiled code to start the program:
$ ./anyprogram.exe
After the program completes, the following output is revealed to show that the
coverage code couldn't save the gcda file:
profiling:profiledata/#home#jselbie\anyprogram.gcda:Skip
The .gcda file is not crated.
You can even see the mangled string it in the resulting binary:
$ strings anyprogram.exe | grep jselbie
profiledata/#home#jselbie\anyprogram.gcda
I see two possible issues that's causing this.
First, the anyprogram.gcda string is getting appended with a back slash instead
of a forward slash
A quick cursory glace of GCC sources would suggest the issue is in
\gcc\coverage.c. Looking at the code for coverage_init inside gcc/converage.c
reveals the following:
if (profile_data_prefix)
{
#if HAVE_DOS_BASED_FILE_SYSTEM
const char *separator = "\\";
#else
const char *separator = "/";
#endif
filename = concat (getpwd (), separator, filename, NULL);
filename = mangle_path (filename);
len = strlen (filename);
}
Another cursory search of gcc sources suggest HAVE_DOS_BASED_FILE_SYSTEM is
defined by this preprocessor stuff:
#if defined(__MSDOS__) || defined(_WIN32) || defined(__OS2__) || defined
(__CYGWIN__)
# ifndef HAVE_DOS_BASED_FILE_SYSTEM
#define HAVE_DOS_BASED_FILE_SYSTEM 1
# endif
Because HAVE_DOS_BASED_FILE_SYSTEM is getting defined for Cygwin, then
coverage_init is going to use a backslash separator as well. Whether CYGWIN
should be considered a DOS based file system or a special exception needs to be
made in coverage_init, well, I'm not sure.
The second issue is with the way the path gets mangled with # chars. That's
not consistent with the Linux build (at least with g++ 7.5 that I have going).
The workaround for now is to skip using the -fprofile-dir flag and allow
default save behavior for the gcda flag.
[Bug c++/94569] New: alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569
Bug ID: 94569
Summary: alignas(object) with a weaker (smaller) alignment than
the alignas(type) of it's type compiles, inconsistent
with the C++ standard
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sinbal2l at gmail dot com
Target Milestone: ---
The standard specifies:
>From the standard: [9.12.2 Alignment specifier, section 6, pg 226]
If the defining declaration of an entity has an alignment-specifier, any
non-defining declaration of that entity shall either specify equivalent
alignment or have no alignment-specifier. Conversely, if any declaration of an
entity has an alignment-specifier, every defining declaration of that entity
shall specify an equivalent alignment.
But on the latest revision, this compiles:
typedef struct alignas(32){
int i;
}U;
int main() {
alignas(16) U my_u; // alignas(obj) of a weaker alignment than the
type.
cout << "alignof(my_u): " << alignof(my_u) << endl;
cout << "alignof (decltype(my_u))" << alignof (decltype(my_u)) << endl;
}
https://godbolt.org/z/2uNAag
P.S. thank you very much for doing such a great job!
[Bug c++/94568] New: template specialization of equivalent nontype template argument involving member pointer considered distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94568
Bug ID: 94568
Summary: template specialization of equivalent nontype template
argument involving member pointer considered distinct
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I believe the two definitions of XB below are the same and should be accepted.
GCC for some reason not evident from the error message treats them as distinct.
$ cat t.C && gcc -O2 -S -Wall -std=c++2a t.C
struct A;
typedef int A::*MemPtr;
struct B { MemPtr p; };
static constexpr MemPtr mp { };
template struct X { };
typedef X XB;
typedef XXB;
t.C:11:27: error: conflicting declaration ‘typedef struct X XB’
11 | typedef XXB;
| ^~
t.C:10:27: note: previous declaration as ‘typedef struct X XB’
10 | typedef X XB;
| ^~
[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556 H.J. Lu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #6 from H.J. Lu --- Created attachment 48258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48258=edit A patch I am testing this.
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Thomas Koenig --- Easy enough to fix.
[Bug fortran/53077] replace "Illegal preprocessor directive" message with "Ignoring preprocessor directive at %C. Use -cpp to enable the C preprocessor" (a patch by Tobias included)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org --- Comment #9 from Dominique d'Humieres --- Unassigning myself.
[Bug fortran/89938] inconsistent wording regarding assumed shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938 Dominique d'Humieres changed: What|Removed |Added Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #6 from Dominique d'Humieres --- Unassigning myself.
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org --- Comment #19 from Dominique d'Humieres --- Unassigning myself.
[Bug fortran/58200] Option fcheck is misleadingly located in option descriptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org --- Comment #7 from Dominique d'Humieres --- Unassigning myself.
[Bug fortran/58200] Option fcheck is misleadingly located in option descriptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200 Dominique d'Humieres changed: What|Removed |Added Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres --- Unassigning myself.
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 --- Comment #2 from Dominique d'Humieres --- > Confirmed at least down to gfortran 7. Down to gfortran 5.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #16 from Piotr Kubaj --- 634afa05a8cbff010480088811fe1f39eca70c1d is the first bad commit commit 634afa05a8cbff010480088811fe1f39eca70c1d Author: Richard Sandiford Date: Tue Aug 20 08:53:52 2019 + Make function.c use function_arg_info internally This patch adds a function_arg_info field to assign_parm_data_one, so that: - passed_type -> arg.type - promoted_mode -> arg.mode - named_arg -> arg.named We can then pass this function_arg_info directly to the converted hooks. Between the initialisation of the assign_parm_data_one and the application of promotion rules (which is a state internal to assign_parm_find_data_types), arg.mode is equivalent to passed_mode (i.e. to TYPE_MODE). 2019-08-20 Richard Sandiford gcc/ * function.c (assign_parm_data_one): Replace passed_type, promoted_mode and named_arg with a function_arg_info field. (assign_parm_find_data_types): Remove local variables and assign directly to "data". Make data->passed_mode shadow data->arg.mode until promotion, then assign the promoted mode to data->arg.mode. (assign_parms_setup_varargs, assign_parm_find_entry_rtl) (assign_parm_find_stack_rtl, assign_parm_adjust_entry_rtl) (assign_parm_remove_parallels, assign_parm_setup_block_p) (assign_parm_setup_block, assign_parm_setup_reg) (assign_parm_setup_stack, assign_parms, gimplify_parameters): Use arg.mode instead of promoted_mode, arg.type instead of passed_type and arg.named instead of named_arg. Use data->arg for function_arg_info structures that had the field values passed_type, promoted_mode and named_arg. Base other function_arg_infos on data->arg, changing the necessary properties. From-SVN: r274705 gcc/ChangeLog | 19 +++ gcc/function.c | 168 + 2 files changed, 92 insertions(+), 95 deletions(-)
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-12 Ever confirmed|0 |1 Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW --- Comment #1 from Thomas Koenig --- Confirmed at least down to gfortran 7. It does indeed issue a warning: /usr/bin/gfortran interface_46.f90 interface_46.f90:17:4: function cntf(a) result(s) 1 Warning: Interface mismatch in global procedure ‘cntf’ at (1): Rank mismatch in function result (0/1) [-Wargument-mismatch] interface_46.f90:30:0: s = cntf(arr) internal compiler error: in fold_convert_loc, at fold-const.c:2275 It might make more sense to issue an error in case of a function result.
[Bug c++/86859] error: expansion pattern contains no parameter pack when a pack from introduced in a capture is used in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86859
Baptiste Parsy changed:
What|Removed |Added
CC||baptiste.parsy at epita dot fr
--- Comment #1 from Baptiste Parsy ---
I get a similar issue.
The following code compiles with clang 9.0.1 but fails with gcc 9.3.0:
#include
#include
template >
struct needs_unapply : std::true_type {
};
template
struct needs_unapply()())>> :
std::false_type {
};
template
auto curry(F&& f) {
if constexpr (needs_unapply::value) {
return [=](auto&& ...x) {
return curry(
[=](auto&& ...xs) -> decltype(f(x..., xs...)) {
return f(x..., xs...);
}
);
};
} else {
return f();
}
}
int main() {
auto f = [](auto a, auto b, auto c, auto d, auto e) {
return a * b * c * d * e;
};
std::cout << curry(f)(1, 2)(3)(4, 5);
}
[Bug fortran/94091] Erroneous __builtin_memcpy warning for character assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- So, fixed, and if it recurs, we'll see it. Thanks a lot for reporting the issue!
[Bug fortran/94091] Erroneous __builtin_memcpy warning for character assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:87be4cecfc6e42390303be1ca92bc8bc587b0bd6 commit r10-7691-g87be4cecfc6e42390303be1ca92bc8bc587b0bd6 Author: Thomas König Date: Sun Apr 12 17:02:08 2020 +0200 Added a test case from a PR that was fixed by something else. 2020-04-12 Thomas Koenig PR fortran/94091 * gfortran.dg/char_length_22.f90: New test. Committed ChangeLog entry.
[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556 --- Comment #5 from H.J. Lu --- The code looks like: vmovq %xmm2, %r15 vmovq %xmm3, %rbp .LEHB0: callpthread_exit .LEHE0: .L15: movl%eax, %ebx .L14: vmovq %rbp, %xmm0 movl$4, %edi vzeroupper call_Z11check_magicid 101 vmovq %xmm3, %rbp (gdb) next 103 callpthread_exit (gdb) p/x $rbp $3 = 0x3f853f3c88fc5280 (gdb) next 106 movl%eax, %ebx (gdb) p/x $rbp $4 = 0x88fc5280 < Only lower 32-bits are restored. (gdb)
[Bug testsuite/92550] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 --- Comment #10 from John David Anglin --- Created attachment 48257 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48257=edit Patch to fix argument alignment
[Bug target/94561] [10 Regression] ICE in ix86_get_ssemov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94561 H.J. Lu changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||43746.html Keywords||patch --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543746.html
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Piotr Kubaj changed: What|Removed |Added CC||richard.sandiford at arm dot com --- Comment #15 from Piotr Kubaj --- CC'ing richard.sandif...@arm.com, whose one of commits broke building of GCC 10 with GCC 4.2. I'm still bisecting, but it was one of those commits, all by richard.sandif...@arm.com: pkubaj@talos:$/usr/home/pkubaj/gcc$ git bisect view | grep commit commit cf0d189eb989906d17010ca7c0b07f1763d5fde5 commit 634afa05a8cbff010480088811fe1f39eca70c1d commit b12cdd6e8e8dd1f39a941b731ba1056d656a094f commit 0ffef2005fd7536efbc9c3a572701998c8a8080c commit 7256c7194e186fce6ff866a124a77b08196c2a5f commit 6930c98c69ad695469ee7daa74b3b6d578afdd0d commit 6783fdb7057d559aa1da8afa2c15a702c532a03e commit e7056ca417326a70eca05defb6a8b20b737d3417 commit 52090e4dbd064f486af606e3f8a283dbddc7c18a commit a7c81bc1fb43366ca1b4332d8a6042b648a84cdc commit 4f53599cb5b822cd7f95997861c2e064977ecb6a
