[Bug target/114224] popcount RTL cost seems wrong with cssc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is a matter of rtl costs. .POPCOUNT expansion in expand_POPCOUNT expands the sequence both ways and asks the backend what is cheaper: /* If .POPCOUNT call has 2 arguments, match_single_bit_test marked it because the result is only used in an equality comparison against 1. Use rtx costs in that case to determine if .POPCOUNT (arg) == 1 or (arg ^ (arg - 1)) > arg - 1 is cheaper. If .POPCOUNT second argument is 0, we additionally know that arg is non-zero, so use arg & (arg - 1) == 0 instead. */
[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
--- Comment #10 from Jakub Jelinek ---
BTW, with compilers from the last decade or so, it would be much better idea to
just use standard memcpy for get_unaligned/put_unaligned rather than messing
around with pointers to packed types. The compiler should optimize it
correctly to unaligned loads or stores itself when one operand is cast from
pointer to certain integral type and the size is the size of that type. Sure,
you'd need to still use the GNU ({ ... }) extension
#define __get_unaligned_t(type, ptr) ({
\
type __get_unaligned_t_x;
\
memcpy(&__get_unaligned_t_x, (ptr), sizeof (__get_unaligned_t_x));
\
__get_unaligned_t_x;
\
})
For the get_unaligned from structure element you'd then have something like
get_unaligned_member(type, member, ptr) macro where it would use
typeof (((type *)0)->member) and offsetof (type, member) and memcpy.
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #8 from Richard Biener ---
(In reply to Andrew Macleod from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to Andrew Macleod from comment #5)
> > > (In reply to rguent...@suse.de from comment #4)
> > >
> > > >
> > > > What was definitely missing is consideration of POLY_INT_CSTs (and
> > > > variable polys, as I think there's no range info for those).
> > > >
> > > Ranger doesn't do anything with POLY_INTs, mostly because I didn't
> > > understand them.
> > >
> > > > We do eventually want to improve how ranger behaves here. I'm not sure
> > > > why when we do not provide a context 'stmt' it can't see to compute
> > > > a range valid at the SSA names point of definition? (so basically
> > > > compute the global range)
> > >
> > > The call looks like it doesn't provide the stmt. Without the stmt, all
> > > ranger will ever provide is global ranges.
> > >
> > > I think you are asking why, If there is no global range, it doesn't try to
> > > compute one from the ssa_name_def_stmt? Ranger does when it is active.
> >
> > I tried with an active ranger but that doesn't make a difference. Basically
> > I added enable_ranger () / disable_ranger () around the pass and thought
> > that would "activate" it. But looking at range_for_expr I don't see how
> > that would make a difference without a provided stmt.
> >
>
> It wouldn't. why isn't a context stmt being provided?
I don't have one in this context. There supposedly is one, but it's not
passed down, I'm also not sure we can use that since it would taint SCEV
info with possibly context sensitive info that's re-used (by cache) in
other context.
> range_of_expr with no context stmt makes no attempt to calculate anything.
> This is because one can get into a lot of trouble as it doesn't know whether
> the expression you are calculating is even in the IL or just some detached
> tree expression.
>
> If you have an SSA NAME and want to actually calculate the value, you can
> use range_of_stmt (range, SSA_NAME_DEF_STMT (name)) instead of
> range_of_expr ().
Yes, the issue is that I might have a GENERIC expression like _1 + 2, or
even _1 + _2.
> If you pass in a stmt as context, and the SSA_NAME you are asking about is
> the LHS of the stmt, then range_of_expr will call range_of_stmt itself...
> but again, it needs a context stmt in order to know its safe to do so.
But for an SSA name it should be always safe to assume its definition as
context because that's effectively what it's global range is computed from.
If it's not in the IL then gimple_bb should be NULL, so this could be
guarded against ...
> In general, range_of_expr with no context will not calculate anything...
> When a stmt for location context is provided, then its free to go an do
> whatever calculations are required.
So I'd like to see global ranges computed on-demand here since I can't
easily pass in the definition stmt for a GENERIC expression. Sth like
(untested)
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index c16b776c1e3..2f481695c22 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -98,33 +98,35 @@ gimple_ranger::range_of_expr (vrange , tree expr, gimple
*stmt)
fputs ("\n", dump_file);
}
- // If there is no statement, just get the global value.
- if (!stmt)
-{
- Value_Range tmp (TREE_TYPE (expr));
- m_cache.get_global_range (r, expr);
- // Pick up implied context information from the on-entry cache
- // if current_bb is set. Do not attempt any new calculations.
- if (current_bb && m_cache.block_range (tmp, current_bb, expr, false))
- {
- r.intersect (tmp);
- char str[80];
- sprintf (str, "picked up range from bb %d\n",current_bb->index);
- if (idx)
- tracer.print (idx, str);
- }
-}
// For a debug stmt, pick the best value currently available, do not
// trigger new value calculations. PR 100781.
- else if (is_gimple_debug (stmt))
+ if (stmt && is_gimple_debug (stmt))
m_cache.range_of_expr (r, expr, stmt);
else
{
- basic_block bb = gimple_bb (stmt);
+ basic_block bb = stmt ? gimple_bb (stmt) : NULL;
gimple *def_stmt = SSA_NAME_DEF_STMT (expr);
+ // If the definition is not in the IL or this is a default def and
+ // there's no context, just get the global value.
+ if ((!stmt && SSA_NAME_IS_DEFAULT_DEF (expr))
+ || (!SSA_NAME_IS_DEFAULT_DEF (expr) && !gimple_bb (def_stmt)))
+ {
+ Value_Range tmp (TREE_TYPE (expr));
+ m_cache.get_global_range (r, expr);
+ // Pick up implied context information from the on-entry cache
+ // if current_bb is set. Do not attempt any new calculations.
+ if (current_bb && m_cache.block_range (tmp, current_bb, expr, false))
+ {
+ r.intersect (tmp);
+ char str[80];
+ sprintf (str,
[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
(In reply to Akihiko Odaki from comment #8)
> It would certainly workaround the issue, but it's only dirtier and brings no
> benefit except suppressed UBSan errors. Why not allow
> get_unaligned(>offset) when UBSan does not complain about that hack?
The purpose of the sanitizer is to find undefined behavior, and it found one.
If you don't want it to find undefined behavior, don't use it.
> > If you want something that will be valid even in C, don't pass struct
> > dir_entry *entry
> > argument, but void *entry instead, and use e.g.
> > __get_unaligned_t(__typeof(((struct dir_entry *)0)->offset), ((char
> > *)entry)+offsetof(struct dir_entry, offset)))
> > You can surely hide that all under some macro.
>
> The definition still involves UB for ((struct dir_entry *)0)->offset.
> Perhaps __typeof() may be considered as an exception, but what if offsetof()
> is defined as follows?
>
> #define offsetof(T, x) ((uintptr_t)&(((T *)0)->x))
typeof nor sizeof operators don't evaluate their arguments unless the
expressions have VLA type. So, if there would be undefined behavior if they
were evaluated, it doesn't matter because they aren't. So, e.g.
void
foo (int n, int *p)
{
typedef int A[n];
A b[4];
typedef int C[10];
C d[4];
int i = 0;
int j = 0;
typeof (b[++i]) e;
typeof (d[++j]) f;
typeof (d[100][4]) g;
p[0] = i;
p[1] = j;
}
doesn't invoke undefined behavior and sets p[0] to 1 and p[1] to 0, b[++i] had
VLA type, so it got evaluated, the other 2 didn't, so ++j wasn't evaluated and
the d[100]
UB wasn't triggered, as if the program did if (n == 54) d[100][4]; and n at
runtime was
never 54. __typeof is a GNU extension but behaves the same way.
offsetof is a standard C macro. It is not defined in the standard as
dereferencing NULL pointer, but as if there was an object of the T type and it
computed the difference between the address of the x member of it and the start
of the object.
If offsetof is defined as
#define offsetof(T, x) ((size_t)(uintptr_t)&(((T *)0)->x))
by the implementation (and yes, e.g. GCC < 4 used to define it similarly), then
obviously the compiler can't assume there is undefined behavior on such
expressions,
but it didn't at that point, there was no UBSAN, such expressions evaluated to
a constant expression early before anything could have considered there might
be UB and after it was just the resulting constant.
If the implementation doesn't have some exception that considers expressions
like
&(((T *)0)->x) valid, then it can't use such offsetof definition and needs to
use something else, like GCC uses __builtin_offsetof. That said, GCC AFAIK
still treats expressions like the above as offsetof-like (because there has
been a lot of such code in the wild for decades), folds them to constant right
away and doesn't complain about it with ubsan; clang does complain about it
though and doesn't treat it that way.
Anyway, if you use something like ((size_t)(uintptr_t)&(((T *)0)->x)), per C
rules you are invoking UB, while if you use offsetof(T, x), it is well defined.
[Bug middle-end/94787] Failure to detect single bit popcount pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Andrew Pinski --- Note the expansion part is handled by r14-5612, r14-5613, and r14-6940 . So now we just need the match part which I will handle for 15.
[Bug tree-optimization/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693
--- Comment #12 from Andrew Pinski ---
(In reply to Piotr Siupa from comment #11)
> However, I've noticed that:
> bool foo(unsigned x)
> {
> if (x == 0)
> return true;
> else
> return std::has_single_bit(x);
> }
Oh that is because expand does not use flow sensitive ranges/non-zero bits
there. There is talk about adding the ability for that but nothing has been
done yet.
[Bug target/114224] New: popcount RTL cost seems wrong with cssc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114224
Bug ID: 114224
Summary: popcount RTL cost seems wrong with cssc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
I noticed this with:
```
#include
bool is_power_of_2_1(uint64_t value)
{
return __builtin_popcountg(value) == 1;
}
```
Which I had expected to produce:
```
cnt x0, x0
cmp x0, 1
csetw0, eq
```
But instead we get:
```
sub x1, x0, #1
eor x0, x0, x1
cmp x0, x1
csetw0, hi
ret
```
[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
--- Comment #8 from Akihiko Odaki ---
(In reply to Jakub Jelinek from comment #7)
> GCC actually doesn't diagnose on mere pointer assignment, but what triggers
> the alignment check is
> >offset
> even when the code later on just takes its address, entry must be
> sufficiently aligned, otherwise entry->offset is invalid.
> Under standard C rules, already forming the pointer would be UB, so
> somewhere in the caller when you prepare what to pass to the f function.
>
> If you want something that will still be invalid C,
> but will not trigger UBSAN errors, then e.g.
> unsigned long long h(struct dir_entry *entry)
> {
> return get_unaligned((unsigned long long *) (((char *) entry) + offsetof
> (struct dir_entry, offset)));
> }
> will do.
It would certainly workaround the issue, but it's only dirtier and brings no
benefit except suppressed UBSan errors. Why not allow
get_unaligned(>offset) when UBSan does not complain about that hack?
> If you want something that will be valid even in C, don't pass struct
> dir_entry *entry
> argument, but void *entry instead, and use e.g.
> __get_unaligned_t(__typeof(((struct dir_entry *)0)->offset), ((char
> *)entry)+offsetof(struct dir_entry, offset)))
> You can surely hide that all under some macro.
The definition still involves UB for ((struct dir_entry *)0)->offset. Perhaps
__typeof() may be considered as an exception, but what if offsetof() is defined
as follows?
#define offsetof(T, x) ((uintptr_t)&(((T *)0)->x))
GCC does provide __builtin_offsetof(), but I think definitions of offsetof()
like this are still prevalent, and expected to work although it's UB. If GCC
tolerates this kind of trick, why not tolerate get_unaligned(>offset)?
[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110369 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug rtl-optimization/110390] [13/14 regression] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609 since r13-3596-ge7310e24b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110725 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at gcc dot gnu.org --- Comment #10 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/110841] [14 Regression] Dead Code Elimination Regression since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110841 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jeffrey A. Law --- Per comment #2 and #3.
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jeffrey A. Law --- Per c#5
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug other/113575] [14 Regression] memory hog building insn-opinit.o (i686-linux-gnu -> riscv64-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Jeffrey A. Law --- Forgot to change state. Fixed on the trunk.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Bug 84402 depends on bug 113575, which changed state. Bug 113575 Summary: [14 Regression] memory hog building insn-opinit.o (i686-linux-gnu -> riscv64-linux-gnu) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/112301] [12/13/14 regression] Double destruction of returned object when exiting the scope causes an exception which gets rethrown since r12-6333-gb10e031458d541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112301 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jeffrey A. Law --- Jason fixed this and backported the fix to the gcc-12 and gcc-13 branches.
[Bug target/112871] [14 Regression] RISCV ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -01 rv32gc_zicond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112871 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug rust/113461] [14 Regression] rust-proc-macro.cc:174:15: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113461 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Should be fixed on the trunk now.
[Bug target/113001] [14 Regression] RISCV Zicond ICE: in extract_insn, at recog.cc:2812 with -O2 rv64gcv_zicond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113001 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug middle-end/113179] [11/12/13/14 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug target/113226] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug target/113346] [14 Regression] epiphany-elf build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P5 CC||law at gcc dot gnu.org
[Bug fortran/113384] [14 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113384 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug other/113575] [14 Regression] memory hog building insn-opinit.o (i686-linux-gnu -> riscv64-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #16 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Last reconfirmed||2024-03-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #14 from Jiang An --- (In reply to g.peterhoff from comment #11) > constexpr > * The hypot3 functions can thus be defined as _GLIBCXX_CONSTEXPR. I think it should be marked _GLIBCXX26_CONSTEXPR. (and we may also need to change bits/c++config)
[Bug target/114000] [11/12/13/14 Regression] ICE: in force_nonfallthru_and_redirect, at cfgrtl.cc:1556 with -O2 -freorder-blocks-and-partition -fPIC -mexplicit-relocs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114000 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/114000] [11/12/13/14 Regression] ICE: in force_nonfallthru_and_redirect, at cfgrtl.cc:1556 with -O2 -freorder-blocks-and-partition -fPIC -mexplicit-relocs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114000 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-03-04
[Bug web/114223] Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- /etc/gitconfig now sports: [uploadpack] allowFilter = true
[Bug debug/100523] [11/12/13/14 Regression] armv8.1-m.main -fcompare-debug failure with -O -fmodulo-sched -mtune=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100523 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug rtl-optimization/110317] [12/13/14 Regression] ICE at -O2 and -O3 with "-fno-tree-pre -fno-tree-dce -fno-tree-dse -fselective-scheduling2": in move_exprs_to_boundary, at sel-sched.cc:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110317 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug rtl-optimization/110391] [12/13/14 Regression] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224 --- Comment #9 from Andrew Pinski --- (In reply to Nathaniel Shead from comment #7) > Created attachment 57586 [details] > Untested patch to implement POLY_INT_CST in modules > > Here's a potential fix for this issue. But I only have access to an x86_64 > machine currently, so this is completely untested. I can test it but it won't be until the middle of this up comming week.
[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182
--- Comment #4 from Andrew Pinski ---
(In reply to Jan Dubiec from comment #3)
> Wait a minute, shouldn't the conditions be opposite? I.e.:
>
> /* { dg-final { scan-tree-dump "__(?:gnu_)?divdc3" "optimized" { target {
> large_double } } } } */
>
> /* { dg-final { scan-tree-dump "__(?:gnu_)?divsc3" "optimized" { target { !
> { large_double } } } } } */
Yes sorry about that mistake.
[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182
--- Comment #3 from Jan Dubiec ---
Wait a minute, shouldn't the conditions be opposite? I.e.:
/* { dg-final { scan-tree-dump "__(?:gnu_)?divdc3" "optimized" { target {
large_double } } } } */
/* { dg-final { scan-tree-dump "__(?:gnu_)?divsc3" "optimized" { target { ! {
large_double } } } } } */
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #19 from Jeffrey A. Law --- Fixed by Jakub's patch on the trunk.
[Bug target/114187] [14 regression] bizarre register dance on x86_64 for pass-by-value struct since r14-2526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114187
--- Comment #5 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:d35b5b0e0a0727cfdaba5f859e44116c33648639
commit r14-9287-gd35b5b0e0a0727cfdaba5f859e44116c33648639
Author: Roger Sayle
Date: Mon Mar 4 00:47:08 2024 +
PR target/114187: Fix ?Fmode SUBREG simplification in simplify_subreg.
This patch fixes PR target/114187 a typo/missed-optimization in
simplify-rtx
that's exposed by (my) changes to x86_64's parameter passing. The context
is that construction of double word (TImode) values now uses the idiom:
(ior:TI (ashift:TI (zero_extend:TI (reg:DI x)) (const_int 64 [0x40]))
(zero_extend:TI (reg:DI y)))
Extracting the DImode highpart and lowpart halves of this complex
expression
is supported by simplications in simplify_subreg. The problem is when the
doubleword TImode value represents two DFmode fields, there isn't a direct
simplification to extract the highpart or lowpart SUBREGs, but instead GCC
uses two steps, extract the DImode {high,low} part and then cast the result
back to a floating point mode, DFmode.
The (buggy) code to do this is:
/* If the outer mode is not integral, try taking a subreg with the
equivalent
integer outer mode and then bitcasting the result.
Other simplifications rely on integer to integer subregs and we'd
potentially miss out on optimizations otherwise. */
if (known_gt (GET_MODE_SIZE (innermode),
GET_MODE_SIZE (outermode))
&& SCALAR_INT_MODE_P (innermode)
&& !SCALAR_INT_MODE_P (outermode)
&& int_mode_for_size (GET_MODE_BITSIZE (outermode),
0).exists (_outermode))
{
rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
if (tem)
return simplify_gen_subreg (outermode, tem, int_outermode, byte);
}
The issue/mistake is that the second call, to simplify_subreg, shouldn't
use "byte" as the final argument; the offset has already been handled by
the first call, to simplify_subreg, and this second call is just a type
conversion from an integer mode to floating point (from DImode to DFmode).
Interestingly, this mistake was already spotted by Richard Sandiford when
the optimization was originally contributed in January 2023.
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610920.html
>> Richard Sandiford writes:
>> Also, the final line should pass 0 rather than byte.
Unfortunately a miscommunication/misunderstanding in a later thread
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612898.html
resulted in this correction being undone. Using lowpart_subreg should
avoid/reduce confusion in future.
2024-03-03 Roger Sayle
gcc/ChangeLog
PR target/114187
* simplify-rtx.cc (simplify_context::simplify_subreg): Call
lowpart_subreg to perform type conversion, to avoid confusion
over the offset to use in the call to simplify_reg_subreg.
gcc/testsuite/ChangeLog
PR target/114187
* g++.target/i386/pr114187.C: New test case.
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 --- Comment #9 from Sam James --- (In reply to Jeevitha from comment #8) > Created attachment 57584 [details] > Removed -many from the options passed by default to the assembler. > > Sam James, can you do a practice distro build using this patch? Hi Jeevitha, I've added this to our patchset tonight and asked some people to give it a spin on top of that too.
[Bug target/101893] There is no vgbbd on p7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Segher Boessenkool --- Yeah. You could have done that yourself :-) The bug can always be reopened, if it turns out not to be fixed.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #13 from Iain Sandoe --- fixed on trunk, intending to backport it.
[Bug target/113010] [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113010 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed by Greg's patch on the trunk. No current plans to backport.
[Bug target/113010] [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113010 --- Comment #10 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:24975a9195743e8eb4ca213f35b9221d4eeb6b59 commit r14-9284-g24975a9195743e8eb4ca213f35b9221d4eeb6b59 Author: Greg McGary Date: Sun Mar 3 14:49:49 2024 -0700 [PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010] The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM load. See the fix for PR112758. gcc/ PR rtl-optimization/113010 * combine.cc (simplify_comparison): Simplify a SUBREG on WORD_REGISTER_OPERATIONS targets only if it is a zero-extending MEM load. gcc/testsuite * gcc.c-torture/execute/pr113010.c: New test.
[Bug target/101893] There is no vgbbd on p7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #3 from Peter Bergner --- So this looks fixed and we can mark it RESOLVED / FIXED?
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #12 from Peter Bergner --- (In reply to Sergey Fedorov from comment #11) > (In reply to GCC Commits from comment #10) > > The master branch has been updated by Iain D Sandoe : > > Iain, thank you very much for addressing this! If this is fixed for you, can you please move this to RESOLVED / FIXED?
[Bug web/114223] Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- I believe this is enabled by setting the following settings described at https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackallowFilter uploadpack.allowFilter If this option is set, upload-pack will support partial clone and partial fetch object filtering. uploadpackfilter.allow Provides a default value for unspecified object filters (see: the below configuration variable). If set to true, this will also enable all filters which get added in the future. Defaults to true. uploadpackfilter..allow Explicitly allow or ban the object filter corresponding to , where may be one of: blob:none, blob:limit, object:type, tree, sparse:oid, or combine. If using combined filters, both combine and all of the nested filter kinds must be allowed. Defaults to uploadpackfilter.allow. uploadpackfilter.tree.maxDepth Only allow --filter=tree: when is no more than the value of uploadpackfilter.tree.maxDepth. If set, this also implies uploadpackfilter.tree.allow=true, unless this configuration variable had already been set. Has no effect if unset.
[Bug web/114223] New: Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Bug ID: 114223 Summary: Utilize filtering for git://gcc.gnu.org/git/gcc.git Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I want to create a treeless-copy of the git://gcc.gnu.org/git/gcc.git . https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ explains what treeless is. > $ git clone --filter=tree:0 git://gcc.gnu.org/git/gcc.git > Cloning into 'gcc'... > warning: filtering not recognized by server, ignoring … When I utilize https://github.com/HaleTom/git-bloblessify/ to strip the unneeded git blobs, eventually it reports … Fetching tags and HEAD's trees... warning: filtering not recognized by server, ignoring remote: Enumerating objects: 2342589, done. remote: Counting objects: 100% (316017/316017), done. remote: Compressing objects: 100% (20610/20610), done. remote: Total 2342589 (delta 307150), reused 295435 (delta 295402), pack-reused 2026572 Receiving objects: 100% (2342589/2342589), 929.71 MiB | 6.40 MiB/s, done. Resolving deltas: 100% (1915402/1915402), done. warning: filtering not recognized by server, ignoring remote: Enumerating objects: 2622955, done. remote: Counting objects: 100% (301209/301209), done. remote: Compressing objects: 100% (21051/21051), done. remote: Total 2622955 (delta 293664), reused 280316 (delta 280149), pack-reused 2321746 Receiving objects: 100% (2622955/2622955), 1.01 GiB | 5.50 MiB/s, done. Resolving deltas: 100% (2148507/2148507), done. fatal: bad object 31ff5e249df46ff122b115c86af04022307fafa4 error: git://gcc.gnu.org/git/gcc.git did not send all necessary objects git-bloblessify: clean-up: previous git objects have been restored git-bloblessify: check remote origin config remains correct remote.origin.url=git://gcc.gnu.org/git/gcc.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.promisor=true remote.origin.partialclonefilter=blob:none git-bloblessify: exiting with error code: 1 I guess the fatal: bad object 31ff5e249df46ff122b115c86af04022307fafa4 error: git://gcc.gnu.org/git/gcc.git did not send all necessary objects means some network error and retrying might help. However retrying takes very long, and might also not work, because of some other network error. Please utilize server-side filtering on git://gcc.gnu.org/git/gcc.git , so that > $ git clone --filter=tree:0 git://gcc.gnu.org/git/gcc.git does not print > warning: filtering not recognized by server, ignoring
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |RESOLVED --- Comment #8 from Uroš Bizjak --- Assuming fixed, please reopen if not.
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 --- Comment #7 from GCC Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:318e0d44fe66ade59edb16a94565b3bfdc1883c6 commit r14-9282-g318e0d44fe66ade59edb16a94565b3bfdc1883c6 Author: Uros Bizjak Date: Sun Mar 3 20:40:45 2024 +0100 alpha: Introduce UMUL_HIGHPART rtx_code [PR113720] umuldi3_highpart expander does: if (REG_P (operands[2])) operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]); on register_operand predicate, which also allows SUBREG RTX. So, subregs were emitted without ZERO_EXTEND RTX. But nowadays we have UMUL_HIGHPART that allows us to fix this issue while also simplifying the instruction RTX. PR target/113720 gcc/ChangeLog: * config/alpha/alpha.md (umuldi3_highpart): Remove expander. (*umuldi3_highpart_reg): Rename to umuldi3_highpart and simplify insn RTX using UMUL_HIGHPART rtx_code. (*umuldi3_highpart_const): Remove.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #9 from Segher Boessenkool --- Yeah. Without a testcase we do not know what is going on. Likely it is a testcase with some very big basic block, which naturally gives very many combination opportunities: the problem by nature is at least quadratic. There are various ways to limit the work done for this, all amounting to "just give up if the problem is too big", just like we do in many other places. It also is interesting to see when this started happening. One of the external PRs indicated this has happened for some years already -- so notably this is not a regression -- but what change caused this then? It can even be the 2-2 thing, if it started far enough back. Or, the real reason why we need to know when it started: possibly a bug was introduced. In all cases, we need the testcase. (The reason this does not happen on x86 is that so many things on x86 are stored in memory, and on less register-poor archs like 390 not. Combine never does dependencies via memory).
[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
--- Comment #7 from Jakub Jelinek ---
GCC actually doesn't diagnose on mere pointer assignment, but what triggers the
alignment check is
>offset
even when the code later on just takes its address, entry must be sufficiently
aligned, otherwise entry->offset is invalid.
Under standard C rules, already forming the pointer would be UB, so somewhere
in the caller when you prepare what to pass to the f function.
If you want something that will still be invalid C,
but will not trigger UBSAN errors, then e.g.
unsigned long long h(struct dir_entry *entry)
{
return get_unaligned((unsigned long long *) (((char *) entry) + offsetof
(struct dir_entry, offset)));
}
will do.
If you want something that will be valid even in C, don't pass struct dir_entry
*entry
argument, but void *entry instead, and use e.g.
__get_unaligned_t(__typeof(((struct dir_entry *)0)->offset), ((char
*)entry)+offsetof(struct dir_entry, offset)))
You can surely hide that all under some macro.
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
--- Comment #4 from Andrew Pinski ---
(In reply to Дилян Палаузов from comment #3)
> > The warning is designed this way explictly because you are returning a
> > reference and taking a reference as an argument and in the case of b2, the
> > tempory is `std::string("u")` .
>
> > In GCC 14+ (since r14-9263-gc7607c4cf18986), you can add
> > [[gnu::no_dangling]] to the z2 function definition to mark it as not
> > returning a dangling reference (from the arguments). and the warning goes
> > away.
>
> If the declaration and definitions are in different files, do I have to add
> [[gnu::no_dangling]] only to the function declaration ?
Yes only on the declaration is needed.
>
> That said, is the warning triggered only based on the function declaration
> (accepting as parameter a reference to temporary and returning a reference),
> when on the function invocation the parameter is indeed a reference to a
> temporary?
Yes that is correct, it is based on the function declaration only and the
warning does not look into the function to see it does not return the a
referenced based on the reference being passed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 114219, which changed state. Bug 114219 Summary: [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Jan Schultke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jan Schultke --- Looks like the existing comments were right. Lvalue-to-rvalue conversion very rarely takes place for class types, and if it does, that may be a wording bug. Instead of lvalue-to-rvalue conversion, this case calls the implicitly-defined copy constructor, which can be used in constant expressions.
[Bug testsuite/114222] New: gcc.c-torture/execute/builtin-bitops-1.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114222 Bug ID: 114222 Summary: gcc.c-torture/execute/builtin-bitops-1.c fails for H8/300 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Host: x86_64-pc-linux-gnu Target: h8300-elf Excerpt from gcc.log: [...] Executing on host: /home/jdx/testgcc/builddir/gcc/xgcc -B/home/jdx/testgcc/builddir/gcc/ /home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c -fdiagnostics-plain-output-O0 -w -isystem /home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem /home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld -B/home/jdx/testgcc/builddir/h8300-elf/./newlib/ -L/home/jdx/testgcc/builddir/h8300-elf/./newlib -lm -o ./builtin-bitops-1.exe (timeout = 300) spawn -ignore SIGHUP /home/jdx/testgcc/builddir/gcc/xgcc -B/home/jdx/testgcc/builddir/gcc/ /home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c -fdiagnostics-plain-output -O0 -w -isystem /home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem /home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld -B/home/jdx/testgcc/builddir/h8300-elf/./newlib/ -L/home/jdx/testgcc/builddir/h8300-elf/./newlib -lm -o ./builtin-bitops-1.exe PASS: gcc.c-torture/execute/builtin-bitops-1.c -O0 (test for excess errors) spawn /home/jdx/testgcc/builddir/sim/h8300/run ./builtin-bitops-1.exe program stopped with signal 4 (Illegal instruction). FAIL: gcc.c-torture/execute/builtin-bitops-1.c -O0 execution test [...] Further investigation showed that: a) the test case fails at line 181, (most likely) inside __builtin_ffs(); other __builtins work as expected, b) it happens when the test case is compiled with default options, i.e. when ints are 16 bit wide; when -mint32 is added to the options (i.e. ints are 32 bit wide), the test passes.
[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182 --- Comment #2 from Jan Dubiec --- Unfortunately, large_double does not work.
[Bug testsuite/114221] New: gcc.c-torture/execute/20101011-1.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114221 Bug ID: 114221 Summary: gcc.c-torture/execute/20101011-1.c fails for H8/300 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Host: x86_64-pc-linux-gnu Target: h8300-elf Excerpt from gcc.sum: [...] PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test PASS: gcc.c-torture/execute/20101011-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution test PASS: gcc.c-torture/execute/20101011-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O2 execution test PASS: gcc.c-torture/execute/20101011-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O3 -g execution test PASS: gcc.c-torture/execute/20101011-1.c -Os (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -Os execution test PASS: gcc.c-torture/execute/20101011-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test PASS: gcc.c-torture/execute/20101011-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test [...] Excerpt from gcc.log: [...] spawn -ignore SIGHUP /home/jdx/testgcc/builddir/gcc/xgcc -B/home/jdx/testgcc/builddir/gcc/ /home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/20101011-1.c -fdiagnostics-plain-output -O0 -fnon-call-exceptions -isystem /home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem /home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld -B/home/jdx/testgcc/builddir/h8300-elf/./newlib/ -L/home/jdx/testgcc/builddir/h8300-elf/./newlib -lm -o ./20101011-1.exe PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors) spawn /home/jdx/testgcc/builddir/sim/h8300/run ./20101011-1.exe program stopped with signal 5 (Trace/breakpoint trap). FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test [...] This is because H8 MCUs do not throw a "divide by zero" exception. Proposed solution: diff --git a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c index d2c0f9ab7ec..9fa10309612 100644 --- a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c +++ b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c @@ -26,6 +26,9 @@ #elif defined (__RX__) /* On RX division by zero does not trap. */ # define DO_TEST 0 +#elif defined (__H8300H__) || defined (__H8300S__) || defined (__H8300SX__) + /* On H8/300H, H8S and H8SX division by zero does not trap. */ +# define DO_TEST 0 #elif defined (__aarch64__) /* On AArch64 integer division by zero does not trap. */ # define DO_TEST 0
[Bug target/114100] [avr] Inefficient indirect addressing on Reduced Tiny
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100 --- Comment #5 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:c0f5b6caff669037444506cb6008a378356ec209 commit r14-9281-gc0f5b6caff669037444506cb6008a378356ec209 Author: Georg-Johann Lay Date: Sun Mar 3 18:15:58 2024 +0100 AVR: ad target/114100 - Don't print unused frame pointer adjustments. Without -mfuse-add, when fake reg+offset addressing is used, the output routines are saving some instructions when the base reg is unused after. This patch adds that optimization for the case when the base is the frame pointer and the frame pointer adjustments are split away from the move insn by -mfuse-add in .split2. Direct usage of reg_unused_after is not possible because that function looks at the destination of the current insn, which won't work for offsetting the frame pointer in printing PLUS code. It can use an extended version of _reg_unused_after though. gcc/ PR target/114100 * config/avr/avr-protos.h (_reg_unused_after): Remove proto. * config/avr/avr.cc (_reg_unused_after): Make static. And add 3rd argument to skip the current insn. (reg_unused_after): Adjust call of reg_unused_after. (avr_out_plus_1) [AVR_TINY && -mfuse-add >= 2]: Don't output unneeded frame pointer adjustments.
[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 Ken Matsui changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kmatsui at gcc dot gnu.org CC||kmatsui at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/114207] [12/13/14 Regression] modref gets confused by vecotorized code ` -O3 -fno-tree-forwprop` since r12-5439
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- mine. The summary is: loads: Base 0: alias set 1 Ref 0: alias set 1 access: Parm 0 param offset:4 offset:0 size:64 max_size:64 stores: Base 0: alias set 1 Ref 0: alias set 1 access: Parm 0 param offset:0 offset:0 size:64 max_size:64 while with fwprop we get: loads: Base 0: alias set 1 Ref 0: alias set 1 access: Parm 0 param offset:0 offset:0 size:64 max_size:64 stores: Base 0: alias set 1 Ref 0: alias set 1 access: Parm 0 param offset:0 offset:0 size:64 max_size:64 So it seems that offset is misaccounted.
[Bug lto/85432] Wodr can be more verbose for C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85432 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jan Hubicka --- This should be solved for a long time. We recognize ODR types by mangled names produced only by C++ frontend. I checked that GCC 12, 13 and trunk does not produce the warning.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #65 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:dae3456965064c9664c097c785ae9bf9fa203fa0 commit r14-9280-gdae3456965064c9664c097c785ae9bf9fa203fa0 Author: Georg-Johann Lay Date: Sun Mar 3 13:01:24 2024 +0100 AVR: ad target/92792 - Remove insn attribute "cc" and its (dead) uses. The backend has remains of cc0 condition code. Unfortunately, all that information is useless with CCmode, and their use was removed with the removal of NOTICE_UPDATE_CC in PR92729 with r12-226 and r12-327. gcc/ PR target/92729 * config/avr/avr.md (define_attr "cc"): Remove. * config/avr/avr-protos.h (avr_out_plus): Remove pcc argument from prototype. * config/avr/avr.cc (avr_out_plus_1): Remove pcc argument and its uses. Add insn argument. (avr_out_plus_symbol): Remove pcc argument and its uses. (avr_out_plus): Remove pcc argument and its uses. Adjust calls of avr_out_plus_symbol and avr_out_plus_1. (avr_out_round): Adjust call of avr_out_plus.
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
--- Comment #3 from Дилян Палаузов ---
> The warning is designed this way explictly because you are returning a
> reference and taking a reference as an argument and in the case of b2, the
> tempory is `std::string("u")` .
> In GCC 14+ (since r14-9263-gc7607c4cf18986), you can add [[gnu::no_dangling]]
> to the z2 function definition to mark it as not returning a dangling
> reference (from the arguments). and the warning goes away.
If the declaration and definitions are in different files, do I have to add
[[gnu::no_dangling]] only to the function declaration ?
That said, is the warning triggered only based on the function declaration
(accepting as parameter a reference to temporary and returning a reference),
when on the function invocation the parameter is indeed a reference to a
temporary?
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220 --- Comment #2 from Дилян Палаузов --- Is my reading correct, that the warning is triggered, when a function receives as parameter a reference to a temporary and returns a reference? If this is the only criterion, then it is a wrong assumption, that both references are somehow related.
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
const std::string& z2(const std::string& m);
const std::string& z2(const std::string& m) { return hashTable2.at(m); }
const std::string& b2 { z2("u") };
The warning is designed this way explictly because you are returning a
reference and taking a reference as an argument and in the case of b2, the
tempory is `std::string("u")` .
In GCC 14+ (since r14-9263-gc7607c4cf18986), you can add [[gnu::no_dangling]]
to the z2 function definition to mark it as not returning a dangling reference
(from the arguments). and the warning goes away.
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 --- Comment #4 from Jan Schultke --- I don't see how lvalue-to-rvalue conversion would be bypassed here. https://eel.is/c++draft/conv.lval#:conversion,lvalue-to-rvalue has no special provision for empty classes. https://eel.is/c++draft/dcl.init.general#16.9 would necessitate lvalue-to-rvalue conversion because the initializer has to be converted to a prvalue. I couldn't find any special rule for empty classes.
[Bug c++/114220] New: False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
Bug ID: 114220
Summary: False positive warning: possibly dangling reference to
a temporary [-Wdangling-reference]
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
Created attachment 57598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57598=edit
The inlined programme
This code
#include
#include
static const std::unordered_map hashTable1 = {{2, "u"}};
static const std::unordered_map hashTable2 = {{"u",
"u"}};
const std::string& z1(int m);
const std::string& z1(int m) { return hashTable1.at(m); }
const std::string& z2(const std::string& m);
const std::string& z2(const std::string& m) { return hashTable2.at(m); }
const std::string& z3();
const std::string& z3() { return hashTable2.at("u"); }
int main() {
const std::string& b1 { z1(2) };
const std::string& b2 { z2("u") };
const std::string& b3 { z3() };
const std::string& f1 = hashTable1.at(2);
const std::string& f2 = hashTable2.at("u");
printf("%s %s %s %s %s\n", b1.c_str(), b2.c_str(), f1.c_str(), f2.c_str(),
b3.c_str());
}
produces with g++ (GCC) 13.2.1 20240302:
$ g++ -Wall -Wextra -o a a.cpp
a.c: In function ‘int main()’:
a.c:16:22: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
16 | const std::string& b2 { z2("u") };
| ^~
a.c:16:29: note: the temporary was destroyed at the end of the full expression
‘z2(std::__cxx11::basic_string(((const char*)"u"),
std::allocator()))’
16 | const std::string& b2 { z2("u") };
| ~~^
So std::string as first template parameter is problematic (b2), when only the
second template parameter is relevant (b3), but int as first template parameter
is fine (b1).
I think this is a bug.
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91953 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539673.html hmm reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953#c3 implies there is no lvalue-to-rvalue conversion happening ...
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 --- Comment #2 from Jan Schultke --- Corresponding LLVM bug: https://github.com/llvm/llvm-project/issues/83712
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Hmm, clang also accepts this ...
[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Andrew Pinski changed: What|Removed |Added Summary|[expr.const]|[11/12/13/14 Regression] |lvalue-to-rvalue conversion |[expr.const] |is not diagnosed to |lvalue-to-rvalue conversion |disqualify constant |is not diagnosed to |expressions for empty |disqualify constant |classes |expressions for empty ||classes Known to work||5.1.0, 6.1.0 Target Milestone|--- |11.5 Known to fail||7.1.0
[Bug c++/114219] New: [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219
Bug ID: 114219
Summary: [expr.const] lvalue-to-rvalue conversion is not
diagnosed to disqualify constant expressions for empty
classes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
https://godbolt.org/z/jhcP8WPn8
Code to reproduce
=
struct S {};
constexpr int f(S s) {
constexpr S _ = s;
return 0;
}
S s;
constexpr int _ = f(s);
Issue description
=
This code compiles, but should produce errors for both constexpr
initializations.
According to [expr.const] p5.9, the initializers of _ cannot be constant
expression because they contain lvalue-to-rvalue conversion of s, whose
lifetime did not begin within the evaluation of the constant expression, and
which is not usable in constant expressions.
It shouldn't matter whether S is an empty class or has members; the
lvalue-to-rvalue conversion in itself disqualifies expressions from being
constant expressions.
