[Bug tree-optimization/102155] LIM fill_always_executed_in handles contains_call incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102155 --- Comment #1 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f482bf2af86990329b4df660f8c1eb9e094de9f9 commit r12-3307-gf482bf2af86990329b4df660f8c1eb9e094de9f9 Author: Richard Biener Date: Wed Sep 1 09:51:45 2021 +0200 tree-optimization/102155 - fix LIM fill_always_executed_in CFG walk This fixes the CFG walk order of fill_always_executed_in to use RPO oder rather than the dominator based order computed by get_loop_body_in_dom_order. That fixes correctness issues with unordered dominator children. The RPO order computed by rev_post_order_and_mark_dfs_back_seme in its for-iteration mode is a good match for the algorithm. 2021-09-01 Richard Biener PR tree-optimization/102155 * tree-ssa-loop-im.c (fill_always_executed_in_1): Iterate over a part of the RPO array and do not recurse here. Dump blocks marked as always executed. (fill_always_executed_in): Walk over the RPO array and process loops whose header we run into. (loop_invariant_motion_in_fun): Compute the first RPO using rev_post_order_and_mark_dfs_back_seme in iteration order and pass that to fill_always_executed_in.
[Bug c/97831] Lack of disable_tail_calls attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831 --- Comment #4 from Andrew Pinski --- In the case of glibc, the callee needs to be marked as not a tail callable and not the caller.
[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826 Andrew Pinski changed: What|Removed |Added URL|https://gist.github.com/dau | |rnimator/a468e01800752d11cd | |15 | Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-02 Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski --- https://gist.github.com/daurnimator/a468e01800752d11cd15 Confirmed.
[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95969 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95969 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org --- Comment #1 from Richard Biener --- I guess a data dependence is indeed the only viable thing here, but that will also hinder optimization (on that data). If you're merely delaying some static checking to RTL expansion by this builtin that's of course quite stupid. --- Comment #2 from Andrew Pinski --- Confirmed. Shouldn't be too hard to add a few attributes to it or fold it when the arguments are constant. Let me look into doing the second thing.
[Bug c/48110] "fast" and "g" should be aliases of "Ofast" and "Og" inside optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110 Andrew Pinski changed: What|Removed |Added Component|middle-end |c --- Comment #4 from Andrew Pinski --- The code is in c-family/c-common: /* Assume that Ox is -Ox, a numeric value is -Ox, a s by itself is -Os, and any other switch begins with a -f. */ if ((*p >= '0' && *p <= '9') || (p[0] == 's' && p[1] == '\0')) *r++ = 'O'; else if (*p != 'O') *r++ = 'f'; as you can see 's' is support by that but 'g' or "fast" is not.
[Bug middle-end/48110] "fast" and "g" should be aliases of "Ofast" and "Og" inside optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2021-09-02 Summary|__attribute__ |"fast" and "g" should be |((optimize(...))) version |aliases of "Ofast" and "Og" |of -Ofast |inside optimize attribute Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed. "g" has the same issue too.
[Bug middle-end/49699] Aligned load on unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2011-07-11 09:24:48 |2021-9-1 Keywords||wrong-code --- Comment #6 from Andrew Pinski --- What is interesting is clang gets it wrong too.
[Bug middle-end/39575] after build_sese_loop_nests, loops still unordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39575 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Keywords||internal-improvement --- Comment #1 from Andrew Pinski --- Fixed by r6-6431 https://gcc.gnu.org/pipermail/gcc-patches/2016-January/440101.html
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #10 from Hongtao.liu --- > > Anyway, I suggest at a minimum removing the #define check. There's little > harm in having no diagnostic on misuse: misuses are probably going to be > seen when testing. Until GCC is able to generate AMX code on its own, the > missing __attribute__ is superfluous anyway. Agree, i'll post a patch for that.
[Bug ipa/95781] Missing dead code elimination when a recursive function is inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95781 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2020-06-22 00:00:00 |2021-9-1
[Bug ipa/80680] dead code elimination fails to remove unreferenced function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80680 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0 Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- So GCC 10+ can optimize this correctly.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #9 from Thiago Macieira --- > clang defines them as intrinsic because they support AMX register allocation > (a lot of effort), gcc does not support AMX register allocation for now, and > defining them as intrinsic + builtin doesn't seem to do much good except > provide some error messages. If you can implement them as macros, I don't see why you need register allocation in the first place. Just emit the same assembly that is being emitted now by the inline assembly. Anyway, I suggest at a minimum removing the #define check. There's little harm in having no diagnostic on misuse: misuses are probably going to be seen when testing. Until GCC is able to generate AMX code on its own, the missing __attribute__ is superfluous anyway.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #8 from Hongtao.liu --- (In reply to Thiago Macieira from comment #6) > > I suggest doing as Clang did and make it an intrinsic. > > Or even a __builtin_ia32_markamxtile(); intrinsic, which produces the error > if misused and does add the necessary bits to the .note.gnu.property section _tile_loadconfig/_tile_storeconfig/_tile_release are defined as intrinsics should be essential for amx program and can provide some error info.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #7 from Hongtao.liu --- (In reply to Thiago Macieira from comment #5) > (In reply to Hongtao.liu from comment #4) > > Because _tile_loadd is implemented as embedded assembly plus macros, if > > __AMX_TILE__ is removed, no error will be reported if the user does not use > > the -mamx option, So this macro is added here, but obviously this is not > > convenient for target_attribute. I think we'd better remove __AMX_TILE__, > > (not sure why c doesn't report the error). > > I suggest doing as Clang did and make it an intrinsic. clang defines them as intrinsic because they support AMX register allocation (a lot of effort), gcc does not support AMX register allocation for now, and defining them as intrinsic + builtin doesn't seem to do much good except provide some error messages.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #6 from Thiago Macieira --- > I suggest doing as Clang did and make it an intrinsic. Or even a __builtin_ia32_markamxtile(); intrinsic, which produces the error if misused and does add the necessary bits to the .note.gnu.property section
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 Andrew Pinski changed: What|Removed |Added CC||andrew.bennett at imgtec dot com --- Comment #9 from Andrew Pinski --- *** Bug 71106 has been marked as a duplicate of this bug. ***
[Bug target/71106] MIPS: Unaligned load/store instructions are not used to access a variable with an aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71106 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- this is actually a dup of bug 88085. The problem is aligned attribute is (incorrectly) ignored partly when used on variable definitions/declarations. *** This bug has been marked as a duplicate of bug 88085 ***
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 --- Comment #8 from Andrew Pinski --- An obvious workaround is to have a type which is also aligned to what you want the global to be aligned to and that will work. typedef int __attribute__((vector_size(16))) v4si; typedef v4si __attribute__((aligned(4))) v4sia4; v4sia4 a4 __attribute__((aligned(4))); or: typedef int __attribute__((aligned(1))) inta1; inta1 __attribute__((aligned(1))) var; or for the case in PR 102162 : typedef unsigned int u32a1 __attribute__((__aligned__(1))); extern u32a1 output_len __attribute__((__aligned__(1)));
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 Andrew Pinski changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 102162 has been marked as a duplicate of this bug. ***
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #26 from Andrew Pinski --- Just marking this as a dup of bug 88085. The workaround is do this: typedef unsigned int u32a1 __attribute__((__aligned__(1))); extern u32a1 output_len __attribute__((__aligned__(1))); *** This bug has been marked as a duplicate of bug 88085 ***
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
--- Comment #6 from Andrew Pinski ---
A simpler testcase is:
int __attribute__((aligned(1))) var;
int foo(void)
{
return var;
}
- CUT ---
Compile this on a strict alignment target and you get the wrong code.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #5 from Thiago Macieira --- (In reply to Hongtao.liu from comment #4) > Because _tile_loadd is implemented as embedded assembly plus macros, if > __AMX_TILE__ is removed, no error will be reported if the user does not use > the -mamx option, So this macro is added here, but obviously this is not > convenient for target_attribute. I think we'd better remove __AMX_TILE__, > (not sure why c doesn't report the error). I suggest doing as Clang did and make it an intrinsic.
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 Andrew Pinski changed: What|Removed |Added CC||petro.karashchenko at gmail dot co ||m --- Comment #5 from Andrew Pinski --- *** Bug 94662 has been marked as a duplicate of this bug. ***
[Bug middle-end/94662] __attribute__ aligned is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94662 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 88085. *** This bug has been marked as a duplicate of bug 88085 ***
[Bug c++/102157] floating-integral conversions is not permitted in the user-defined conversion sequence in converted constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102157 --- Comment #2 from jim x --- bind the temporary is permitted here to me. Since the template parameter is not a reference type, there is no restriction on whether a temporary object is generated in the implicit conversion.
[Bug preprocessor/42014] Inconsistent column number display for "In file incuded from"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014
--- Comment #7 from Andrew Pinski ---
Since r11-2092 we don't print the columns at all if the column was 0.
So mostly we get:
In file included from /usr/include/c++/4.9.1/iostream:39,
from test.cxx:1:
The code looks like:
const char *line_col = maybe_line_and_column (s.line, col);
static const char *const msgs[] =
{
NULL,
N_(" from"),
N_("In file included from"), /* 2 */
N_("included from"),
N_("In module"), /* 4 */
N_("of module"),
N_("In module imported at"), /* 6 */
N_("imported at"),
};
unsigned index = (was_module ? 6 : is_module ? 4
: need_inc ? 2 : 0) + !first;
pp_verbatim (context->printer, "%s%s %r%s%s%R",
first ? "" : was_module ? ", " : ",\n",
_(msgs[index]),
"locus", s.file, line_col);
Where maybe_line_and_column does:
static const char *
maybe_line_and_column (int line, int col)
{
static char result[32];
if (line)
{
size_t l
= snprintf (result, sizeof (result),
col >= 0 ? ":%d:%d" : ":%d", line, col);
gcc_checking_assert (l < sizeof (result));
}
else
result[0] = 0;
return result;
}
[Bug preprocessor/77487] gcc reports "file shorter than expected" for regular files on stdin when the offset of fd 0 isn't 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77487 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-02 Keywords||diagnostic Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c/102169] New: powerpc64 int memory operations using FP instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Bug ID: 102169
Summary: powerpc64 int memory operations using FP instructions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: npiggin at gmail dot com
CC: bergner at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux-gnu
--- test.c ---
int foo, bar;
void test(void)
{
foo = bar;
}
---
Using Debian gcc 10.2 with -O2 flag, this compiles to:
addis r2,r12,0
addir2,r2,0
addis r9,r2,0
addir9,r9,0
lfiwzx f0,0,r9
addis r9,r2,0
addir9,r9,0
stfiwx f0,0,r9
blr
Peter confirmed it also uses FP registers with trunk (but I don't have the asm
output at hand).
This can be suboptimal on some processors, e.g., on POWER9 lfiwzx is "Tuple
Restricted (R)" which reduces dispatch throughput on the cycle it is
dispatched. And generally just seems like a surprising thing to do with no
shortage of GPRs.
[Bug preprocessor/61386] inaccurate location for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |7.0 --- Comment #5 from Andrew Pinski --- Fixed by r7-1651.
[Bug preprocessor/61386] inaccurate location for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386 Andrew Pinski changed: What|Removed |Added Known to work||7.1.0 Known to fail||4.9.0 --- Comment #4 from Andrew Pinski --- GCC 7 produces: :1:11: fatal error: stexcept: No such file or directory #include ^~
[Bug preprocessor/58939] Cannot Cross-Build Android Native GCC 4.8 libcpp build conversion errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58939 --- Comment #2 from Andrew Pinski --- Interesting POSIX requires st_size to be off_t. I see it is long long on some platforms of bionic. https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/include/sys/stat.h I don't know if there is a way to support this correctly. because using off_t will cause a truncatation. Likewise for st_mtime too. I don't know the right away to fix this without major changes to the sources. So the question becomes do we want to support non-POSIX targets for these structs here?
[Bug tree-optimization/102151] Spurious warning by -Warray-bounds when allocating with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151 --- Comment #4 from Niibe Yutaka --- Thank you for the explanation. I understand how (current version of) GCC warns. >From the viewpoint of use of structure with flexible array member, still, this could be considered as a bug of GCC, because the warning itself is irrelevant. My point is that: (1) In the test case, use of offsetof(struct arg_and_data_s, arg) is valid (I mean, no violation of language/feature). In other words, (2) Allocated space for an object of the structure may be smaller than sizeof(). There are such cases, for structure with flexible array member, because of structure alignment. (3) It seems for me that by (current version of) GCC, the fact (2) is ignored.
[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59782 --- Comment #7 from Andrew Pinski --- #if (GCC_VERSION >= 4005) && (__GNUC__ >= 5 || !defined(__PIC__)) && (defined(__i386__) || defined(__x86_64__)) && !(defined(__sun__) && defined(__svr4__)) I don't know if this is not that important with the requirement of C++11 compiler now.
[Bug preprocessor/44652] Column numbers in error messages are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
--- Comment #7 from Andrew Pinski ---
where = linemap_included_from (map);
map = linemap_included_from_linemap (line_table, map);
bool is_module = MAP_MODULE_P (map);
s.file = LINEMAP_FILE (map);
s.line = SOURCE_LINE (map, where);
int col = -1;
if (first && context->show_column)
{
s.column = SOURCE_COLUMN (map, where);
col = diagnostic_converted_column (context, s);
}
first is true so the column info must be missing from the preprocessor.
[Bug bootstrap/46981] multilib LD_LIBRARY_PATH prevents configuration of target libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46981 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- This is more than just an AIX problem. Use of LD_LIBRARY_PATH prevents bootstrapping with any tools that happen to use libstdc++.so, for example, ld.gold on Linux. If the new libstdc++.so is incompatible with the version ld.gold was linked against the result is typically a segfault on ld.gold startup, when attempting to build gcc stage3 target libraries. A workaround is to install a statically compiled ld.gold.
[Bug middle-end/25186] (short)(((int)short_var) <<1) should be folded so that the shift is done in the short type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #8 from Gabriel Ravier --- So, is there still an optimization problem on that kind of basic thing ? Or have some things in GCC have changed since this time to make this irrelevant ? Looking at these same examples at .optimized even in latest trunk still shows the same conversions to int... 樂
[Bug target/102143] ABI incompatibility with clang when passing 32bit vectors on 32bit i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
--- Comment #6 from H.J. Lu ---
I think psABIs should specify how to pass and return 8-bit, 16-bit and 32-bit
vectors. We can treat them as
struct vectorN
{
intN
};
[Bug preprocessor/44652] Column numbers in error messages are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #6 from Andrew Pinski --- We removed the column of 0 by r11-2092.
[Bug preprocessor/44652] Column numbers in error messages are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 --- Comment #5 from Andrew Pinski --- So we don't display the column any more: In file included from t.c:2: structdef.h:5:3: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘unsigned’ 5 | unsigned int b:5; | ^~~~ Let me figure out when it happened.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #4 from Hongtao.liu --- Because _tile_loadd is implemented as embedded assembly plus macros, if __AMX_TILE__ is removed, no error will be reported if the user does not use the -mamx option, So this macro is added here, but obviously this is not convenient for target_attribute. I think we'd better remove __AMX_TILE__, (not sure why c doesn't report the error).
[Bug c++/95127] Self-calling lambda with auto return type gives misleading error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95127
--- Comment #4 from Andrew Pinski ---
Literally all of the same error message even:
clang:
:2:47: error: function 'operator()<(lambda at :2:12), int>'
with deduced return type cannot be used before it is defined
auto f = [](const auto , auto x) { return g(g, x); };
^
:3:4: note: in instantiation of function template specialization
'main()::(anonymous class)::operator()<(lambda at :2:12), int>'
requested here
f(f, 0);
^
:2:12: note: 'operator()<(lambda at :2:12), int>' declared here
auto f = [](const auto , auto x) { return g(g, x); };
^
ICC:
(2): error: cannot deduce the return type of function "lambda [](const
auto &, auto)->auto [with =lambda [](const auto &, auto)->auto,
=int]" (declared at line 2); it has not been defined
auto f = [](const auto , auto x) { return g(g, x); };
^
detected during instantiation of function "lambda [](const auto &,
auto)->auto [with =lambda [](const auto &, auto)->auto, =int]"
at line 3
compilation aborted for (code 2)
MSVC:
(2): error C3779: 'mainoperator ()': a function that
returns 'auto' cannot be used before it is defined
(2): note: see declaration of 'mainoperator ()'
(3): note: see reference to function template instantiation 'auto
mainoperator (),int>(const _T1 &,_T2) const'
being compiled
with
[
_T1=main::,
_T2=int
]
[Bug c++/95127] Self-calling lambda with auto return type gives misleading error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95127 --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > All 4 compilers (GCC, ICC, clang and MSVC) I have access to reject this code. Could you post their error messages for comparison?
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Eric Gallager changed: What|Removed |Added Alias||cxxfriends CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- alias cxxfriends
[Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359 --- Comment #6 from Larkin Nickle --- (In reply to Larkin Nickle from comment #5) > I am also running into this on HP-UX 11.23 on PA-RISC. I've started with > HP's distribution of GCC 4.7.1 and have attempted to build 4.7.4, 4.8.5, and > 4.9.4 and have gotten this same error. I can build 4.9.4 successfully if I > disable libquadmath, but trying to build 4.9.4 with it enabled with the > no-quadmath 4.9.4 build results in the same error. I'm configuring GCC as follows: ../../sources/gcc-4.9.4/configure --prefix=/usr/util/gcc/gcc-4.9.4 --disable -nls --enable-languages=c,c++ --with-gmp=/usr/util/gcc/gmp-6.1.0 --with-mpfr=/us r/util/gcc/mpfr-3.1.6 --with-mpc=/usr/util/gcc/mpc-1.0.3 --without-gnu-ld --with -gnu-as --with-as=/usr/util/gcc/binutils-2.25/bin/as CONFIG_SHELL=/usr/util/bin/ bash AWK=/usr/util/bin/awk SED=/usr/util/bin/sed
[Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359 Larkin Nickle changed: What|Removed |Added CC||me at larbob dot org --- Comment #5 from Larkin Nickle --- I am also running into this on HP-UX 11.23 on PA-RISC. I've started with HP's distribution of GCC 4.7.1 and have attempted to build 4.7.4, 4.8.5, and 4.9.4 and have gotten this same error. I can build 4.9.4 successfully if I disable libquadmath, but trying to build 4.9.4 with it enabled with the no-quadmath 4.9.4 build results in the same error.
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew Pinski --- PR 102162 just ran into this same problem on hppa-linux-gnu even inside the Linux kernel.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 Andrew Pinski changed: What|Removed |Added Depends on||88085 --- Comment #25 from Andrew Pinski --- PR 88085 is the same bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 [Bug 88085] User alignments on var decls not respected if smaller than type alignment
[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-02 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #24 from dave.anglin at bell dot net --- On 2021-09-01 8:23 p.m., pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 > > --- Comment #23 from Andrew Pinski --- > (In reply to Andrew Pinski from comment #22) >> The problem is in emit-rtl.c in set_mem_attributes_minus_bitpos: >> >> /* We can set the alignment from the type if we are making an object or if >> this is an INDIRECT_REF. */ >> if (objectp || TREE_CODE (t) == INDIRECT_REF) >> attrs.align = MAX (attrs.align, TYPE_ALIGN (type)); >> >> >> The type here is not the correct thing to do. > This has been a bug since r0-38512 (2001). Excellent work! I assume attrs.align should only be set from type when it is not set.
[Bug tree-optimization/24333] missed div optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24333 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #8 from Gabriel Ravier --- Seems to be fixed since GCC 7
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #23 from Andrew Pinski --- (In reply to Andrew Pinski from comment #22) > The problem is in emit-rtl.c in set_mem_attributes_minus_bitpos: > > /* We can set the alignment from the type if we are making an object or if > this is an INDIRECT_REF. */ > if (objectp || TREE_CODE (t) == INDIRECT_REF) > attrs.align = MAX (attrs.align, TYPE_ALIGN (type)); > > > The type here is not the correct thing to do. This has been a bug since r0-38512 (2001).
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #22 from Andrew Pinski --- The problem is in emit-rtl.c in set_mem_attributes_minus_bitpos: /* We can set the alignment from the type if we are making an object or if this is an INDIRECT_REF. */ if (objectp || TREE_CODE (t) == INDIRECT_REF) attrs.align = MAX (attrs.align, TYPE_ALIGN (type)); The type here is not the correct thing to do.
[Bug c++/102168] New: -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
Bug ID: 102168
Summary: -Wnon-virtual-dtor shouldn't fire for protected dtor
in a class with a friend declaration
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
class base;
class b {
public:
void del(base *x);
};
class base {
friend b;
public:
virtual void anchor();
protected:
virtual // why is this needed?
~base() = default;
};
class derived final : public base {
public:
~derived() {}
};
void b::del(base *x) {
delete x;
}
% g++ -c -Wnon-virtual-dtor a.cc
a.cc:8:7: warning: ‘class base’ has virtual functions and accessible
non-virtual destructor [-Wnon-virtual-dtor]
8 | class base {
| ^~~~
a.cc:17:7: warning: base class ‘class base’ has accessible non-virtual
destructor [-Wnon-virtual-dtor]
17 | class derived final : public base {
| ^~~
This diagnostic is due to a friend declaration because technically the friend
can invoke the dtor.
However, this seems a bit dumb (https://reviews.llvm.org/rG4852c770fe87)
It just checks the existence of friend, not actually checking whether the dtor
is actually used.
Checking whether the dtor is actually needed requires dataflow analysis (like
frontend devirtualization), which is apparently too heavy and may not fit into
a compiler diagnostic.
In addition, if the friend class ever uses the dtor, it'd trigger
-Wdelete-non-virtual-dtor.
Now to suppress the diagnostic, we have to add a `virtual`, wasting 2 entries
in the vtable and emitting unneeded D0/D2.
[Bug target/95427] Failure to avoid emitting rbp initialization when doing 256-bit memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95427 --- Comment #1 from Gabriel Ravier --- Seems to be fixed in trunk.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #21 from dave.anglin at bell dot net --- On 2021-09-01 7:21 p.m., pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 > > --- Comment #17 from Andrew Pinski --- > (In reply to dave.anglin from comment #14) >> On 2021-09-01 6:35 p.m., dave.anglin at bell dot net wrote: >>> We only get correct code at -O0. >> Maybe cpymemsi expander is problem. > It can't be as that is only used for !TARGET_64BIT and this is a TARGET_64BIT > as obvious by "LEVEL 2.0w". I changed expanders for both !TARGET_64BIT and TARGET_64BIT. Didn't help. Same error with trunk. Dave
[Bug rtl-optimization/95787] Complete lack of optimization on assignment to some types when followed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787 --- Comment #3 from Gabriel Ravier --- nvm that's only if I use `-march=znver3`. Seems like it might be a tuning issue, then ? Unless znver3 triggers patterns that specifically solve this...
[Bug rtl-optimization/95787] Complete lack of optimization on assignment to some types when followed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787 --- Comment #2 from Gabriel Ravier --- Seems to be fixed on trunk
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #20 from Andrew Pinski --- tem was the var_decl /* If TEM's type is a union of variable size, pass TARGET to the inner computation, since it will need a temporary and TARGET is known to have to do. This occurs in unchecked conversion in Ada. */ orig_op0 = op0 = expand_expr_real (tem, (TREE_CODE (TREE_TYPE (tem)) == UNION_TYPE && COMPLETE_TYPE_P (TREE_TYPE (tem)) && (TREE_CODE (TYPE_SIZE (TREE_TYPE (tem))) != INTEGER_CST) && modifier != EXPAND_STACK_PARM ? target : NULL_RTX), VOIDmode, modifier == EXPAND_SUM ? EXPAND_NORMAL : modifier, NULL, true); produces: (gdb) p debug_rtx(op0) (mem/c:SI (reg/f:DI 71) [1 output_len+0 S4 A32]) Note the A32 here. So it is a bug in the expansion of the var_decl.
[Bug other/101711] Error when gcc cross compile libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711 --- Comment #10 from ctice at gcc dot gnu.org --- I have been trying off-and-on for the last 3 weeks to build a ming64 GCC cross-compiler, on my x86_64 linux ELF system, and I have not been able to do it. This is without enabling libvtv. The instructions referenced on https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ are at least 8 years out of date, and I have not been able to make them work. Until I can get a set of instructions that works, I cannot reproduce the problem, and without reproducing it I cannot debug/fix it. I am sorry about this, but I really have tried.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #19 from Andrew Pinski --- Gimple level does look correct: unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77315bd0 precision:32 min max context > readonly arg:0 unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x773159d8 attributes > fields context pointer_to_this > arg:0 constant arg:0 t.c:17:9 start: t.c:17:9 finish: t.c:17:39> arg:1 > arg:1 unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77251690 precision:32 min max context pointer_to_this > unsigned packed SI t.c:12:33 size unit-size align:8 warn_if_not_align:0 offset_align 128 offset bit-offset context > t.c:12:103 start: t.c:12:97 finish: t.c:12:105> The var_decl too: (gdb) p debug_tree(0x77ff6120) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77251690 precision:32 min max context pointer_to_this > addressable used public unsigned external read SI t.c:6:14 size unit-size user align:8 warn_if_not_align:0 context attributes value >> chain >
[Bug tree-optimization/95845] Failure to optimize vector load made in separate operations to single load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95845 --- Comment #2 from Gabriel Ravier --- This appears to be fixed in trunk, GCC seems to use a movq now instead of a movlps on x86.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-01 Ever confirmed|0 |1 --- Comment #18 from Andrew Pinski --- I used noticed the original testcase had the wrong line commented out :) It should have been: extern u32 output_len __attribute__((__aligned__(1))); Anyways confirmed on aarch64-linux-gnu with -O1 -mstrict-align too.
[Bug tree-optimization/102152] [12 Regression] ICE: tree check: expected ssa_name, have integer_cst in cprop_operand, at tree-ssa-dom.c:1715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Should be fixed on the trunk now.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #17 from Andrew Pinski --- (In reply to dave.anglin from comment #14) > On 2021-09-01 6:35 p.m., dave.anglin at bell dot net wrote: > > We only get correct code at -O0. > Maybe cpymemsi expander is problem. It can't be as that is only used for !TARGET_64BIT and this is a TARGET_64BIT as obvious by "LEVEL 2.0w".
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #16 from Andrew Pinski --- I cannot even reproduce the original issue on released gcc 10.3.0 sources. What configure options is being used? I used none except for --target: Configured with: ../configure --target=hppa-linux-gnu I even tried with -march=2.0 and it still works. Looks like the target really is hppa*64-linux-gnu :)
[Bug tree-optimization/102152] [12 Regression] ICE: tree check: expected ssa_name, have integer_cst in cprop_operand, at tree-ssa-dom.c:1715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152 --- Comment #4 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:165446a1e81f5bb9597289e783af9ee67e1fe5ba commit r12-3304-g165446a1e81f5bb9597289e783af9ee67e1fe5ba Author: Jeff Law Date: Wed Sep 1 19:13:58 2021 -0400 Call reduce_vector_comparison_to_scalar_comparison earlier As noted in the PR, we can get an ICE after the introduction of code to reduce a vector comparison to a scalar. The problem is we left the operand cache in an inconsistent state because we called the new function too late. This is trivially fixed by making the transformation before we call update_stmt_if_modified. The irony here is the whole point of calling reduce_vector_comparison_to_scalar_comparison when we did was to expose these kinds of secondary opportunities. In this particular case we collapsed the test to a comparison of constants (thus no SSA operands). Anyway, this fixes the problem in the obvious way. This may all end up being moot if I can twiddle Richi's match.pd pattern to work. It doesn't work as-written due to a couple issues that I haven't worked totally through yet. Installed on the trunk after bootstrap & regression testing on x86 and verifying it addresses the aarch64 issue. gcc/ PR tree-optimization/102152 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Reduce a vector comparison to a scalar comparison before calling update_stmt_if_modified. gcc/testsuite/ PR tree-optimization/102152 * gcc.dg/pr102152.c: New test
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 --- Comment #3 from Thiago Macieira --- There appears to be some preprocessor magic behind the scenes because the preprocessed output can't be compiled either: $ gcc -no-integrated-cpp -Werror=implicit-function-declaration -c -xc test.cpp test.cpp: In function ‘amx’: test.cpp:10:5: error: implicit declaration of function ‘_tile_loadd’ [-Werror=implicit-function-declaration] 10 | _tile_loadd(0, 0, 0); | ^~~ test.cpp:11:5: error: implicit declaration of function ‘_tile_release’ [-Werror=implicit-function-declaration] 11 | _tile_release(); | ^ cc1: some warnings being treated as errors
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #15 from Andrew Pinski --- The trunk works: .LEVEL 1.1 .text .align 4 .globl test .type test, @function test: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY addil LR'output_len-$global$,%r27 ldo RR'output_len-$global$(%r1),%r20 ldb RR'output_len-$global$(%r1),%r28 zdep %r28,7,8,%r28 ldb 1(%r20),%r19 zdep %r19,15,16,%r19 or %r19,%r28,%r19 ldb 2(%r20),%r28 zdep %r28,23,24,%r28 or %r28,%r19,%r28 ldb 3(%r20),%r19 bv %r0(%r2) or %r19,%r28,%r28 .EXIT .PROCEND .size test, .-test .ident "GCC: (GNU) 12.0.0 20210901 (experimental)"
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #14 from dave.anglin at bell dot net --- On 2021-09-01 6:35 p.m., dave.anglin at bell dot net wrote: > We only get correct code at -O0. Maybe cpymemsi expander is problem.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166
--- Comment #2 from Thiago Macieira ---
FYI:
$ cat test.cpp
#include
__attribute__((target("avx"))) void avx()
{
_mm256_zeroall();
}
#ifndef __INTEL_COMPILER
__attribute__((target("amx-tile")))
#endif
void amx()
{
_tile_loadd(0, 0, 0);
_tile_release();
}
$ icc -c test.cpp && echo success
success
$ icc -c -xc test.cpp && echo success
success
$ clang -c -xc test.cpp && echo success
success
$ clang -c test.cpp && echo success
success
$ clang --version
clang version 11.1.0
Target: x86_64-generic-linux
Thread model: posix
InstalledDir: /usr/bin
$ icc --version
icc (ICC) 19.1.3.304 20200925
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 Andrew Pinski changed: What|Removed |Added CC||friedkeenan at protonmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 102167 has been marked as a duplicate of this bug. ***
[Bug c++/102167] Constexpr virtual destructors confuse memory leak detection during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102167 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 100495. *** This bug has been marked as a duplicate of bug 100495 ***
[Bug c++/102167] New: Constexpr virtual destructors confuse memory leak detection during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102167
Bug ID: 102167
Summary: Constexpr virtual destructors confuse memory leak
detection during constant evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
Minimal example:
struct S {
virtual constexpr ~S() { }
};
consteval bool test() {
const auto ptr = new S;
delete ptr;
return true;
}
static_assert(test());
Godbolt link: https://godbolt.org/z/6jszvsxGE
Clang handles the code correctly.
Possibly related to Bug 93413, which is the reason why the virtual destructor
is not defaulted, as doing so raises the error from that report.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #13 from dave.anglin at bell dot net --- On 2021-09-01 5:52 p.m., pinskia at gcc dot gnu.org wrote: > This is doing the correct thing in splitting up the load into bytes loads. We only get correct code at -O0. STRICT_ALIGNMENT is defined to 1.
[Bug target/102166] [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166 Thiago Macieira changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Thiago Macieira --- I don't understand how this compiles in C mode: $ gcc -O2 -Werror=implicit-function-declaration -c -xc test.cpp $ gcc -O2 -fno-asynchronous-unwind-tables -S -o - -xc test.cpp .file "test.cpp" .text .p2align 4 .globl avx .type avx, @function avx: vzeroall ret .size avx, .-avx .p2align 4 .globl amx .type amx, @function amx: xorl%eax, %eax #APP # 10 "test.cpp" 1 tileloadd (%rax,%rax,1), %tmm0 # 0 "" 2 # 56 "/usr/lib64/gcc/x86_64-generic-linux/11/include/amxtileintrin.h" 1 tilerelease # 0 "" 2 #NO_APP ret .size amx, .-amx The comments in the assembly output indicate that _tile_loadd is a macro that was expanded from test.cpp and that _tile_release is a function in amxtileintrin.h. But neither is defined. $ gcc -E -xc test.cpp | grep -e _tile_loadd -e _tile_release _tile_loadd(0, 0, 0); _tile_release(); Whatever they are, they are not visible to the preprocessor.
[Bug target/102166] New: [i386] AMX intrinsics and macros not defined in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102166
Bug ID: 102166
Summary: [i386] AMX intrinsics and macros not defined in C++
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
$ cat test.cpp
#include
__attribute__((target("avx"))) void avx()
{
_mm256_zeroall();
}
__attribute__((target("amx-tile"))) void amx()
{
_tile_loadd(0, 0, 0);
_tile_release();
}
$ gcc -c test.cpp
test.cpp: In function ‘void amx()’:
test.cpp:10:5: error: ‘_tile_loadd’ was not declared in this scope
10 | _tile_loadd(0, 0, 0);
| ^~~
test.cpp:11:5: error: ‘_tile_release’ was not declared in this scope
11 | _tile_release();
| ^
That's because the macros and intrinsics in amxtileintrin.h are only defined
behind:
#if defined(__x86_64__) && defined(__AMX_TILE__)
The __AMX_TILE__ macro isn't defined and doesn't need to be. None of the other
itnrinsics require compiling with -m options. In fact, code shouldn't use -m
options for things that are detected at runtime, like AMX inevitably has to be.
[Bug driver/89249] mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249 Andrew Pinski changed: What|Removed |Added CC||marcoxa at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 98175 has been marked as a duplicate of this bug. ***
[Bug driver/98175] Problem with gcc front end and ld on vanilla Windows 10 installation (spaces in path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98175 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 89249. *** This bug has been marked as a duplicate of bug 89249 ***
[Bug driver/32528] -save-temps when compiling standard input fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32528
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2018-03-16 00:00:00 |2021-9-1
--- Comment #10 from Andrew Pinski ---
Still fails on the trunk:
apinski@xeond:~/src/upstream-gcc$ echo "int main(void){}" |
~/upstream-gcc/bin/gcc -xc -save-temps - -c
cc1: error: unrecognized command-line option ‘-.i’
Note without the -c, it works as the output is based on a.out so it is a--.i
now.
[Bug driver/66657] Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 --- Comment #6 from Andrew Pinski --- (In reply to Kenneth Almquist from comment #3) > (In reply to Andrew Pinski from comment #2) > > What are you trying to do with the assembly after the fact? > > In this particular case, I wanted to look at it for two reasons: > > 1) To determine which functions were being inlined. For recent compilers you can use -fopt-info option which should supply this; if it does not then we should improve it to supply what you need. > > 2) To identify errant calls to printf and puts. When compiled to run in > background mode, my program should send all messages to the log rather than > stdout/stderr, so calls to printf/puts that the compiler doesn't discard as > unreachable represent program bugs. For this, as mentioned you can use post tools like objdump/nm/etc. and even the you can use a GNU linker option to warn at link time.
[Bug c++/102157] floating-integral conversions is not permitted in the user-defined conversion sequence in converted constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102157
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-09-01
--- Comment #1 from Andrew Pinski ---
There are two issues here really (both accepts invalid).
First is binding to a temp is invalid:
struct A{
constexpr A(double const ){}
};
template
struct C{};
int main() {
C b;
}
- CUT
Second is the conversion is also invalid:
struct A{
constexpr A(double rf){}
};
template
struct C{};
int main() {
C b;
}
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #12 from Andrew Pinski --- Here is what the first testcase looks like at -O1 -mstrict-align on aarch64-linux-gnu for GCC 10.3.0: test: .LFB1: .cfi_startproc adrpx0, output_len add x1, x0, :lo12:output_len ldrbw2, [x0, #:lo12:output_len] ldrbw0, [x1, 1] orr x2, x2, x0, lsl 8 ldrbw0, [x1, 2] orr x0, x2, x0, lsl 16 ldrbw1, [x1, 3] orr w0, w0, w1, lsl 24 ret .cfi_endproc .LFE1: .size test, .-test .ident "GCC: (GNU) 10.3.0" .section.note.GNU-stack,"",@progbits This is doing the correct thing in splitting up the load into bytes loads.
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |middle-end Keywords||wrong-code --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #10) > Does hppa*-*-linux* have STRICT_ALIGNMENT set to true or false? config/pa/pa.h:#define STRICT_ALIGNMENT 1 Hmm, so it should work. It is definitely something in the expansion between gimple and rtl which is messing up.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #10 from Andrew Pinski --- So I looked into this a little bit and it works on aarch64 with -O1 -mstrict-align but if you remove -mstrict-align we get an unaligned access which I think it is expected. The gimple level is the same in both cases, it is expand which changes. Does hppa*-*-linux* have STRICT_ALIGNMENT set to true or false?
[Bug c++/101592] ICE in wide_int_to_tree, at tree.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101592 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/101592] ICE in wide_int_to_tree, at tree.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101592 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:adee9b8a80cc985c7a0ede592fe07b131303343a commit r11-8949-gadee9b8a80cc985c7a0ede592fe07b131303343a Author: Marek Polacek Date: Wed Sep 1 16:47:44 2021 -0400 c++: Fix ICE with nullptr comparison (GCC 11) [PR101592] On trunk, PR101592 was fixed by r12-2537, but that change shouldn't be backported to GCC 11. In the PR Jakub suggested this fix, so here it is, after the usual testing. PR c++/101592 gcc/ChangeLog: * fold-const.c (make_range_step): Return NULL_TREE for NULLPTR_TYPE. gcc/testsuite/ChangeLog: * g++.dg/warn/Wlogical-op-3.C: New test. Co-authored-by: Jakub Jelinek
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
--- Comment #9 from deller at gmx dot de ---
On 9/1/21 11:25 PM, deller at gmx dot de wrote:
> The "ldh" loads only the first two bytes, and extends it into the upper 32bits
> with "extrw,s".
> So, only 16bits instead of 32bits are loaded from the address where "evil"
> is...
Forget this!
My testcase was wrong. Here is the correct testcase which then loads 32bits:
short evil;
int f_unaligned2(void)
{ return get_unaligned((unsigned long *)); }
:
0: 2b 60 00 00 addil L%0,dp,r1
4: 34 33 00 00 ldo 0(r1),r19
8: 44 3c 00 00 ldh 0(r1),ret0
c: d7 9c 0a 10 depw,z ret0,15,16,ret0
10: 0e 64 10 53 ldh 2(r19),r19
14: e8 40 c0 00 bv r0(rp)
18: 0b 93 02 5c or r19,ret0,ret0
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
--- Comment #8 from deller at gmx dot de ---
On 9/1/21 11:19 PM, dave.anglin at bell dot net wrote:
>> I think the problem with your testcase is, that the compiler doesn't know the
>> alignment of the parameter "p" in your f_unaligned() function.
>> So it will generate byte-accesses.
> I think it's the type rather than the alignment. If type is char, one gets
> byte accesses. If type is short, one gets 16-bit accesses.
>
> The alignment is being ignored.
You are right.
It's even worse!
short evil;
int f_unaligned2(void)
{ return get_unaligned(); }
gives:
:
0: 2b 60 00 00 addil L%0,dp,r1
4: 44 3c 00 00 ldh 0(r1),ret0
8: e8 40 c0 00 bv r0(rp)
c: d3 9c 1f f0 extrw,s ret0,31,16,ret0
The "ldh" loads only the first two bytes, and extends it into the upper 32bits
with "extrw,s".
So, only 16bits instead of 32bits are loaded from the address where "evil"
is...
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #7 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned() function. > So it will generate byte-accesses. I think it's the type rather than the alignment. If type is char, one gets byte accesses. If type is short, one gets 16-bit accesses. The alignment is being ignored.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #6 from deller at gmx dot de --- > So, it seems the __aligned__ attribute is ignored: > extern u32 output_len __attribute__((__aligned__(1))); I think the aligned attribute is not relevant here. Even u32 output_len; will generate word-accesses. I'd say that the "forcement-to-packed" is ignored when the compiler knows that the source is aligned. The "__attribute__((__packed__))" should *always* trigger byte-accesses.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #9 from Andrew Pinski ---
The array is not needed to reproduce this though:
struct Foo {
constexpr Foo() {}
};
union U {
// struct {} monostate = {};
Foo foo;
constexpr U() {}
};
constexpr U s;
[Bug c++/102163] [10/11/12 Regression] std::variant rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102163
--- Comment #3 from Andrew Pinski ---
Note this works:
struct O {
constexpr O() {}
};
union _Variadic_union
{
constexpr _Variadic_union() : _M_rest() { }
O _M_rest;
};
constexpr _Variadic_union w;
- CUT ---
But this fails:
struct O {
constexpr O() {}
};
union _Variadic_union
{
constexpr _Variadic_union() : _M_rest{} { }
O _M_rest;
};
constexpr _Variadic_union w;
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #5 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned() function. > So it will generate byte-accesses. So, it seems the __aligned__ attribute is ignored: extern u32 output_len __attribute__((__aligned__(1)));
[Bug c++/102163] [10/11/12 Regression] std::variant rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102163 --- Comment #2 from Andrew Pinski --- PR 97665 is related but it does not have an intializer for _M_rest.
[Bug middle-end/101934] [11 Regression] aarch64 memset code creates unaligned stores for -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934 Andrew Pinski changed: What|Removed |Added Summary|[11/12 Regression] aarch64 |[11 Regression] aarch64 |memset code creates |memset code creates |unaligned stores for|unaligned stores for |-mstrict-align |-mstrict-align Known to work||12.0 --- Comment #7 from Andrew Pinski --- Fixed on the trunk so far. Will let sit on the trunk for at least a week before backporting it.
[Bug middle-end/101934] [11/12 Regression] aarch64 memset code creates unaligned stores for -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:a45786e9a31f995087d8cb42bc3a4fe06911e588 commit r12-3303-ga45786e9a31f995087d8cb42bc3a4fe06911e588 Author: Andrew Pinski Date: Tue Aug 31 04:41:14 2021 + Fix target/101934: aarch64 memset code creates unaligned stores for -mstrict-align The problem here is the aarch64_expand_setmem code did not check STRICT_ALIGNMENT if it is creating an overlapping store. This patch adds that check and the testcase works. gcc/ChangeLog: PR target/101934 * config/aarch64/aarch64.c (aarch64_expand_setmem): Check STRICT_ALIGNMENT before creating an overlapping store. gcc/testsuite/ChangeLog: PR target/101934 * gcc.target/aarch64/memset-strict-align-1.c: New test.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #4 from dave.anglin at bell dot net --- On 2021-09-01 4:14 p.m., arnd at linaro dot org wrote: > Any idea what the difference is between the working version and your broken > one? Not really. My original test case worked as well. Helge created the broken one.
[Bug c++/102163] [10/11/12 Regression] std::variant rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102163
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.4
Last reconfirmed||2021-09-01
CC||ppalka at gcc dot gnu.org
Ever confirmed|0 |1
Known to work||9.4.0
Status|UNCONFIRMED |ASSIGNED
Known to fail||10.3.0, 11.2.0, 12.0
Summary|std::variant rejects valid |[10/11/12 Regression]
|constant expression |std::variant rejects valid
||constant expression
--- Comment #1 from Patrick Palka ---
Reduced rejects-valid testcase:
struct O {
constexpr O(int) {}
};
union _Variadic_union
{
constexpr _Variadic_union() : _M_rest(42) { }
O _M_rest;
};
constexpr _Variadic_union w;
Started with r10-7313.
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
--- Comment #3 from deller at gmx dot de ---
Hi Arnd,
I think the problem with your testcase is, that the compiler doesn't know the
alignment of the parameter "p" in your f_unaligned() function.
So it will generate byte-accesses.
If you modify your testcase by adding this and compiling with -O1 (or higher)
you see the problem:
int evil;
int f_unaligned2(void)
{
return get_unaligned();
}
:
0: 2b 60 00 00 addil L%0,dp,r1
4: 34 21 00 00 ldo 0(r1),r1
8: e8 40 c0 00 bv r0(rp)
c: 0c 20 10 9c ldw 0(r1),ret0
