[Bug target/106545] New: peephole.md seems like it should not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545 Bug ID: 106545 Summary: peephole.md seems like it should not exist Product: gcc Version: 12.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: riscv There is one peephole2 in there for: Simplify (unsigned long)(unsigned int)a << const But that should really be handled in generic code in simplify-rtx/combine already. If it is not, then it should be added.
[Bug target/106544] New: riscv_print_operand does not check to see if the operands are valid to do INTVAL on them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106544 Bug ID: 106544 Summary: riscv_print_operand does not check to see if the operands are valid to do INTVAL on them Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-checking, ice-on-invalid-code, inline-asm Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv riscv_print_operand currently does not check to see if CONST_INT_P is true on the operand before calling INTVAL on it. This can cause an ICE with RTL checking and inline-asm with these used. See aarch64_print_operand in config/aarch64/aarch64.cc for an examples on how to fix this.
[Bug target/106543] New: *sge_ uses operand 2 but there is no operand 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106543 Bug ID: 106543 Summary: *sge_ uses operand 2 but there is no operand 2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv This is definitely broken: (define_insn "*sge_" [(set (match_operand:GPR 0 "register_operand" "=r") (any_ge:GPR (match_operand:X 1 "register_operand" " r") (const_int 1)))] "" "slt%i2\t%0,zero,%1" [(set_attr "type" "slt") (set_attr "mode" "")]) %i2 is not valid here as there is no operand[2] .
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- The code is undefined as the subtraction is done in the int type. You either need to use -fwrapv or cast to an unsigned type before doing the subtraction.
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 wuz73 at hotmail dot com changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from wuz73 at hotmail dot com --- (In reply to Andrew Pinski from comment #1) > The code is undefined and can be detected with -fsanitize=undefined: > > /app/example.cpp:15:14: runtime error: signed integer overflow: 2086724600 - > -1610499096 cannot be represented in type 'int' I'm only interested in the lower 32 bits, hence the unsigned(d).
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The code is undefined and can be detected with -fsanitize=undefined: /app/example.cpp:15:14: runtime error: signed integer overflow: 2086724600 - -1610499096 cannot be represented in type 'int'
[Bug tree-optimization/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 wuz73 at hotmail dot com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from wuz73 at hotmail dot com --- Great. I think this can be closed now.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 99536, which changed state. Bug 99536 Summary: unexplained warning on "uninitialized value" in std::normal_distribution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/106542] New: -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542
Bug ID: 106542
Summary: -O2 sign-extended uint32 to uint64
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wuz73 at hotmail dot com
Target Milestone: ---
#include
unsigned Msb(uint64_t x) { return 63 - __builtin_clzl(x); }
template
void f(T r, T p)
{
if (p > r)
{
auto d = p - r;
unsigned k = Msb(sizeof(T) == 4 ? unsigned(d) : d);
std::cout << sizeof(T) << " k=" << k << "\n";
}
}
int main()
{
int data[] = {-1610499096,2086724600};
f(data[0],data[1]);
}
When compiled with "g++ -O2" the output is "4 k=63". Apparently before calling
Msb(), g++ sign-extended unsigned(d). static_cast(d) yields the same
result. However, "g++ -O0" is correct (k=31), so are earlier versions of g++
such as 4.8.5 and 5.3.1.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||44209 --- Comment #3 from Eric Gallager --- This is an example of bug 44209 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 Bug 105887 depends on bug 105947, which changed state. Bug 105947 Summary: RFE: -fanalyzer should complain about jumps through NULL function pointers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/105947] RFE: -fanalyzer should complain about jumps through NULL function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be implemented for GCC 13 by the above patch.
[committed] New warning: -Wanalyzer-jump-through-null [PR105947]
This patch adds a new warning to -fanalyzer for jumps through NULL
function pointers.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1979-ge1a9168153d2bf.
gcc/analyzer/ChangeLog:
PR analyzer/105947
* analyzer.opt (Wanalyzer-jump-through-null): New option.
* engine.cc (class jump_through_null): New.
(exploded_graph::process_node): Complain about jumps through NULL
function pointers.
gcc/ChangeLog:
PR analyzer/105947
* doc/invoke.texi: Add -Wanalyzer-jump-through-null.
gcc/testsuite/ChangeLog:
PR analyzer/105947
* gcc.dg/analyzer/function-ptr-5.c: New test.
Signed-off-by: David Malcolm
---
gcc/analyzer/analyzer.opt | 4 ++
gcc/analyzer/engine.cc| 49 +++
gcc/doc/invoke.texi | 12 +
.../gcc.dg/analyzer/function-ptr-5.c | 42
4 files changed, 107 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/function-ptr-5.c
diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index 808ff36ac54..c6d9c53d9c3 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -98,6 +98,10 @@ Wanalyzer-free-of-non-heap
Common Var(warn_analyzer_free_of_non_heap) Init(1) Warning
Warn about code paths in which a non-heap pointer is freed.
+Wanalyzer-jump-through-null
+Common Var(warn_analyzer_jump_through_null) Init(1) Warning
+Warn about code paths in which a NULL function pointer is called.
+
Wanalyzer-malloc-leak
Common Var(warn_analyzer_malloc_leak) Init(1) Warning
Warn about code paths in which a heap-allocated pointer leaks.
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 85b7c5e1227..e8db00d7e18 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -3705,6 +3705,46 @@ private:
bool m_terminate_path;
};
+/* A subclass of pending_diagnostic for complaining about jumps through NULL
+ function pointers. */
+
+class jump_through_null : public pending_diagnostic_subclass
+{
+public:
+ jump_through_null (const gcall *call)
+ : m_call (call)
+ {}
+
+ const char *get_kind () const final override
+ {
+return "jump_through_null";
+ }
+
+ bool operator== (const jump_through_null ) const
+ {
+return m_call == other.m_call;
+ }
+
+ int get_controlling_option () const final override
+ {
+return OPT_Wanalyzer_jump_through_null;
+ }
+
+ bool emit (rich_location *rich_loc) final override
+ {
+return warning_at (rich_loc, get_controlling_option (),
+ "jump through null pointer");
+ }
+
+ label_text describe_final_event (const evdesc::final_event ) final
override
+ {
+return ev.formatted_print ("jump through null pointer here");
+ }
+
+private:
+ const gcall *m_call;
+};
+
/* The core of exploded_graph::process_worklist (the main analysis loop),
handling one node in the worklist.
@@ -4046,6 +4086,15 @@ exploded_graph::process_node (exploded_node *node)
logger);
if (!call_discovered)
{
+ /* Check for jump through NULL. */
+ if (tree fn_ptr = gimple_call_fn (call))
+ {
+ const svalue *fn_ptr_sval
+ = model->get_rvalue (fn_ptr, );
+ if (fn_ptr_sval->all_zeroes_p ())
+ ctxt.warn (new jump_through_null (call));
+ }
+
/* An unknown function or a special function was called
at this point, in such case, don't terminate the
analysis of the current function.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e8cd60103e4..c6dac6a1273 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -453,6 +453,7 @@ Objective-C and Objective-C++ Dialects}.
-Wno-analyzer-fd-use-without-check @gol
-Wno-analyzer-file-leak @gol
-Wno-analyzer-free-of-non-heap @gol
+-Wno-analyzer-jump-through-null @gol
-Wno-analyzer-malloc-leak @gol
-Wno-analyzer-mismatching-deallocation @gol
-Wno-analyzer-null-argument @gol
@@ -9756,6 +9757,7 @@ Enabling this option effectively enables the following
warnings:
-Wanalyzer-fd-use-without-check @gol
-Wanalyzer-file-leak @gol
-Wanalyzer-free-of-non-heap @gol
+-Wanalyzer-jump-through-null @gol
-Wanalyzer-malloc-leak @gol
-Wanalyzer-mismatching-deallocation @gol
-Wanalyzer-null-argument @gol
@@ -9942,6 +9944,16 @@ is called on a non-heap pointer (e.g. an on-stack
buffer, or a global).
See @uref{https://cwe.mitre.org/data/definitions/590.html, CWE-590: Free of
Memory not on the Heap}.
+@item -Wno-analyzer-jump-through-null
+@opindex Wanalyzer-jump-through-null
+@opindex Wno-analyzer-jump-through-null
+This warning requires @option{-fanalyzer}, which enables it; use
[Bug analyzer/105947] RFE: -fanalyzer should complain about jumps through NULL function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e1a9168153d2bf12695844a9ca9f9fc1de8d1ddf commit r13-1979-ge1a9168153d2bf12695844a9ca9f9fc1de8d1ddf Author: David Malcolm Date: Fri Aug 5 19:45:41 2022 -0400 New warning: -Wanalyzer-jump-through-null [PR105947] This patch adds a new warning to -fanalyzer for jumps through NULL function pointers. gcc/analyzer/ChangeLog: PR analyzer/105947 * analyzer.opt (Wanalyzer-jump-through-null): New option. * engine.cc (class jump_through_null): New. (exploded_graph::process_node): Complain about jumps through NULL function pointers. gcc/ChangeLog: PR analyzer/105947 * doc/invoke.texi: Add -Wanalyzer-jump-through-null. gcc/testsuite/ChangeLog: PR analyzer/105947 * gcc.dg/analyzer/function-ptr-5.c: New test. Signed-off-by: David Malcolm
RE: [EXTERNAL] [PATCH] contrib: modernize gen_autofdo_event.py
The changes look good to me. Also adding Andi, the author of the script.
Eugene
-Original Message-
From: Gcc-patches On
Behalf Of Xi Ruoyao via Gcc-patches
Sent: Sunday, June 26, 2022 11:15 PM
To: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] [PATCH] contrib: modernize gen_autofdo_event.py
Python 2 has been EOL'ed for two years. egrep has been deprecated for many
years and the next grep release will start to print warning if it is used.
-E option may be unsupported by some non-POSIX grep implementations, but
gcc-auto-profile won't work on non-Linux systems anyway.
contrib/ChangeLog:
* gen_autofdo_event.py: Port to Python 3, and use grep -E
instead of egrep.
gcc/ChangeLog:
* config/i386/gcc-auto-profile: Regenerate.
---
contrib/gen_autofdo_event.py | 80
gcc/config/i386/gcc-auto-profile | 31 +++--
2 files changed, 57 insertions(+), 54 deletions(-)
diff --git a/contrib/gen_autofdo_event.py b/contrib/gen_autofdo_event.py index
1eb6f1d6d85..7da2876530d 100755
--- a/contrib/gen_autofdo_event.py
+++ b/contrib/gen_autofdo_event.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
# Generate Intel taken branches Linux perf event script for autofdo profiling.
# Copyright (C) 2016 Free Software Foundation, Inc.
@@ -26,18 +26,19 @@
# Requires internet (https) access. This may require setting up a proxy #
with export https_proxy=...
#
-import urllib2
+import urllib.request
import sys
import json
import argparse
import collections
+import os
baseurl = "https://download.01.org/perfmon;
-target_events = (u'BR_INST_RETIRED.NEAR_TAKEN',
- u'BR_INST_EXEC.TAKEN',
- u'BR_INST_RETIRED.TAKEN_JCC',
- u'BR_INST_TYPE_RETIRED.COND_TAKEN')
+target_events = ('BR_INST_RETIRED.NEAR_TAKEN',
+ 'BR_INST_EXEC.TAKEN',
+ 'BR_INST_RETIRED.TAKEN_JCC',
+ 'BR_INST_TYPE_RETIRED.COND_TAKEN')
ap = argparse.ArgumentParser()
ap.add_argument('--all', '-a', help='Print for all CPUs', action='store_true')
@@ -71,47 +72,46 @@ def get_cpustr():
return "%s-%d-%X" % tuple(cpu)[:3]
def find_event(eventurl, model):
-print >>sys.stderr, "Downloading", eventurl
-u = urllib2.urlopen(eventurl)
+print("Downloading", eventurl, file = sys.stderr)
+u = urllib.request.urlopen(eventurl)
events = json.loads(u.read())
u.close()
found = 0
for j in events:
-if j[u'EventName'] in target_events:
-event = "cpu/event=%s,umask=%s/" % (j[u'EventCode'], j[u'UMask'])
-if u'PEBS' in j and j[u'PEBS'] > 0:
+if j['EventName'] in target_events:
+event = "cpu/event=%s,umask=%s/" % (j['EventCode'], j['UMask'])
+if 'PEBS' in j and int(j['PEBS']) > 0:
event += "p"
if args.script:
eventmap[event].append(model)
else:
-print j[u'EventName'], "event for model", model, "is", event
+print(j['EventName'], "event for model", model, "is",
+ event)
found += 1
return found
if not args.all:
-cpu = get_cpu_str()
+cpu = get_cpustr()
if not cpu:
sys.exit("Unknown CPU type")
url = baseurl + "/mapfile.csv"
-print >>sys.stderr, "Downloading", url
-u = urllib2.urlopen(url)
+print("Downloading", url, file = sys.stderr) u =
+urllib.request.urlopen(url)
found = 0
cpufound = 0
for j in u:
-n = j.rstrip().split(',')
+n = j.rstrip().decode().split(',')
if len(n) >= 4 and (args.all or n[0] == cpu) and n[3] == "core":
-if args.all:
-components = n[0].split("-")
-model = components[2]
-model = int(model, 16)
+components = n[0].split("-")
+model = components[2]
+model = int(model, 16)
cpufound += 1
found += find_event(baseurl + n[2], model)
u.close()
if args.script:
-print '''#!/bin/sh
+print('''#!/bin/sh
# Profile workload for gcc profile feedback (autofdo) using Linux perf.
# Auto generated. To regenerate for new CPUs run #
contrib/gen_autofdo_event.py --script --all in gcc source @@ -146,27 +146,27 @@
if grep -q hypervisor /proc/cpuinfo ; then
echo >&2 "Warning: branch profiling may not be functional in VMs"
fi
-case `egrep -q "^cpu family\s*: 6" /proc/cpuinfo &&
- egrep "^model\s*:" /proc/cpuinfo | head -n1` in'''
-for event, mod in eventmap.iteritems():
+case `grep -E -q "^cpu family\s*: 6" /proc/cpuinfo &&
+ grep -E "^model\s*:" /proc/cpuinfo | head -n1` in''')
+for event, mod in eventmap.items():
for m in mod[:-1]:
-print "model*:\ %s|\\" % m
-print 'model*:\ %s) E="%s$FLAGS" ;;' % (mod[-1], event)
-print '''*)
+print("model*:\ %s|\\" % m)
+print('model*:\ %s) E="%s$FLAGS" ;;' % (mod[-1], event))
+print('''*)
echo >&2 "Unknown CPU. Run contrib/gen_autofdo_event.py
gcc-11-20220805 is now available
Snapshot gcc-11-20220805 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220805/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision f87be50119c51016a8f791cb39dcb64615826c6b You'll find: gcc-11-20220805.tar.xz Complete GCC SHA256=487250a3a4260090df5f90ab4560d08823be0f40f14fb392fc0c5afcbfd59b0b SHA1=0b0fa2a32182dcaa1ba83ddeeab166f1aca523f8 Diffs from 11-20220729 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug c++/106541] New: Missing -Wuninitialized on self initialization if external code is called earlier in the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106541
Bug ID: 106541
Summary: Missing -Wuninitialized on self initialization if
external code is called earlier in the function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct my_class {
int data[4];
};
void fn1();
void fn2()
{
my_class local = local;
}
void fn3()
{
fn1();
my_class local = local;
}
Compile with g++ -Wall.
Expected: Two warnings. Or maybe zero, if this is not considered a use.
Actual: Former complains, latter does not. That extra function call should not
affect the warning count.
https://godbolt.org/z/vhdnq1Ec1
[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||4.5.3, 4.6.4
Summary|bswap is incorrectly|[10/11/12/13 Regression]
|generated |bswap pass misses that >>56
||for signed types can be
||replicate the sign bit
Known to work||4.4.7
Target Milestone|--- |10.5
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-08-05
--- Comment #3 from Andrew Pinski ---
Confirmed.
Better testcase (without the questionable undefined behavior):
typedef long long int int64_t;
__attribute__((noinline)) int64_t
swap64 (int64_t n)
{
return (((n & (((int64_t) 0xff) )) << 56) |
((n & (((int64_t) 0xff) << 8)) << 40) |
((n & (((int64_t) 0xff) << 16)) << 24) |
((n & (((int64_t) 0xff) << 24)) << 8) |
((n & (((int64_t) 0xff) << 32)) >> 8) |
((n & (((int64_t) 0xff) << 40)) >> 24) |
((n & (((int64_t) 0xff) << 48)) >> 40) |
((n & ((int64_t)(0xffull << 56))) >> 56));
}
int main (void)
{
volatile int64_t n = 0x8000l;
if (swap64(n) != 0xff80l)
__builtin_abort ();
return 0;
}
[Bug c++/106520] 2+ index expressions in build_op_subscript are incorrectly interpreted as comma expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106520 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-05 --- Comment #1 from Andrew Pinski --- clang diagnostic is better: :15:4: error: no viable overloaded operator[] for type 'A' a[b, 2]; ~^ :4:8: note: candidate function not viable: no known conversion from 'B' to 'unsigned int' for 1st argument void operator[](unsigned, unsigned); ^ :3:8: note: candidate function not viable: requires 1 argument, but 2 were provided void operator[](unsigned); ^ Though it does not do the warning except for C++20.
Re: Reason for missing notes for incomplete-type errors in standard headers
Hi Jonathan,
Thanks for the quick answer. No, it doesn't for the simplest possible case:
#include
int main() { std::array arr; };
But admittedly that would have been a surprise to me as I usually
compile with -Wall -Wextra -Werror.
But I tried to replace `` with `` in yet another code
(tiny but real-life, so not as trivial as above) with two appearances of
`std::array` and there, one does yield the note.
I boiled it down to the following: The typename seems to not yield the
note but the constructor does notify, i.e. in
1 std::array f() {
2 return std::array{{1}};
3 }
Line 1 and 2 raise an error but only Line 2 comes with a note.
Best,
Julian
On 05/08/2022 17:55, Jonathan Wakely wrote:
On Fri, 5 Aug 2022 at 17:39, Julian Lenz via Gcc wrote:
Hi everybody,
TL;DR:
What is the reason that `error: '' has incomplete type` does
not give a note about where the forward declaration happened for
standard library classes?
Probably because the declaration happens in a system header.
Does -Wsystem-headers change it?
add more C++ name hints
How about adding a few more names from the std namespace to get appropriate hints? This patch compiles and the appropriate messages are printed. Is there a problem with just adding more or even at some point all the symbols of the standard library? gcc/ChangeLog: * cp/name-lookup.cc (get_std_name_hint): Add more symbols from the , , and headers. d-g++-std-io-syms-hints Description: Binary data
[x86 PATCH] Move V1TI shift/rotate lowering from expand to pre-reload split.
This patch moves the lowering of 128-bit V1TImode shifts and rotations by
constant bit counts to sequences of SSE operations from the RTL expansion
pass to the pre-reload split pass. Postponing this splitting of shifts
and rotates enables (will enable) the TImode equivalents of these
operations/
instructions to be considered as candidates by the (TImode) STV pass.
Technically, this patch changes the existing expanders to continue to
lower shifts by variable amounts, but constant operands become RTL
instructions, specified by define_insn_and_split that are triggered by
x86_pre_reload_split. The one minor complication is that logical shifts
by multiples of eight, don't get split, but are handled by existing insn
patterns, such as sse2_ashlv1ti3 and sse2_lshrv1ti3. There should be no
changes in generated code with this patch, which just adjusts the pass
in which transformations get applied.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}, with
no new failures. Ok for mainline?
2022-08-05 Roger Sayle
gcc/ChangeLog
* config/i386/sse.md (ashlv1ti3): Delay lowering of logical left
shifts by constant bit counts.
(*ashlvti3_internal): New define_insn_and_split that lowers
logical left shifts by constant bit counts, that aren't multiples
of 8, before reload.
(lshrv1ti3): Delay lowering of logical right shifts by constant.
(*lshrv1ti3_internal): New define_insn_and_split that lowers
logical right shifts by constant bit counts, that aren't multiples
of 8, before reload.
(ashrv1ti3):: Delay lowering of arithmetic right shifts by
constant bit counts.
(*ashrv1ti3_internal): New define_insn_and_split that lowers
arithmetic right shifts by constant bit counts before reload.
(rotlv1ti3): Delay lowering of rotate left by constant.
(*rotlv1ti3_internal): New define_insn_and_split that lowers
rotate left by constant bits counts before reload.
(rotrv1ti3): Delay lowering of rotate right by constant.
(*rotrv1ti3_internal): New define_insn_and_split that lowers
rotate right by constant bits counts before reload.
Thanks in advance,
Roger
--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 14d12d1..d3ea52f 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -15995,10 +15995,30 @@
(define_expand "ashlv1ti3"
[(set (match_operand:V1TI 0 "register_operand")
+(ashift:V1TI
+ (match_operand:V1TI 1 "register_operand")
+ (match_operand:QI 2 "general_operand")))]
+ "TARGET_SSE2 && TARGET_64BIT"
+{
+ if (!CONST_INT_P (operands[2]))
+{
+ ix86_expand_v1ti_shift (ASHIFT, operands);
+ DONE;
+}
+})
+
+(define_insn_and_split "*ashlv1ti3_internal"
+ [(set (match_operand:V1TI 0 "register_operand")
(ashift:V1TI
(match_operand:V1TI 1 "register_operand")
-(match_operand:QI 2 "general_operand")))]
- "TARGET_SSE2 && TARGET_64BIT"
+(match_operand:SI 2 "const_0_to_255_operand")))]
+ "TARGET_SSE2
+ && TARGET_64BIT
+ && (INTVAL (operands[2]) & 7) != 0
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(const_int 0)]
{
ix86_expand_v1ti_shift (ASHIFT, operands);
DONE;
@@ -16011,6 +16031,26 @@
(match_operand:QI 2 "general_operand")))]
"TARGET_SSE2 && TARGET_64BIT"
{
+ if (!CONST_INT_P (operands[2]))
+{
+ ix86_expand_v1ti_shift (LSHIFTRT, operands);
+ DONE;
+}
+})
+
+(define_insn_and_split "*lshrv1ti3_internal"
+ [(set (match_operand:V1TI 0 "register_operand")
+ (lshiftrt:V1TI
+(match_operand:V1TI 1 "register_operand")
+(match_operand:SI 2 "const_0_to_255_operand")))]
+ "TARGET_SSE2
+ && TARGET_64BIT
+ && (INTVAL (operands[2]) & 7) != 0
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+{
ix86_expand_v1ti_shift (LSHIFTRT, operands);
DONE;
})
@@ -16022,6 +16062,26 @@
(match_operand:QI 2 "general_operand")))]
"TARGET_SSE2 && TARGET_64BIT"
{
+ if (!CONST_INT_P (operands[2]))
+{
+ ix86_expand_v1ti_ashiftrt (operands);
+ DONE;
+}
+})
+
+
+(define_insn_and_split "*ashrv1ti3_internal"
+ [(set (match_operand:V1TI 0 "register_operand")
+ (ashiftrt:V1TI
+(match_operand:V1TI 1 "register_operand")
+(match_operand:SI 2 "const_0_to_255_operand")))]
+ "TARGET_SSE2
+ && TARGET_64BIT
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+{
ix86_expand_v1ti_ashiftrt (operands);
DONE;
})
@@ -16033,6 +16093,25 @@
(match_operand:QI 2 "general_operand")))]
"TARGET_SSE2 && TARGET_64BIT"
{
+ if (!CONST_INT_P (operands[2]))
+{
+ ix86_expand_v1ti_rotate (ROTATE, operands);
+ DONE;
+}
+})
+
+(define_insn_and_split "*rotlv1ti3_internal"
+ [(set (match_operand:V1TI 0 "register_operand")
+ (rotate:V1TI
+
Re: [PATCH 0/5] IEEE 128-bit built-in overload support.
On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote: > These patches lay the foundation for a set of follow-on patches that will > change the internal handling of 128-bit floating point types in GCC. In the > future patches, I hope to change the compiler to always use KFmode for the > explicit _Float128/__float128 types, to always use TFmode for the long double > type, no matter which 128-bit floating point type is used, and IFmode for the > explicit __ibm128 type. Making TFmode different from KFmode and IFmode is not an improvement. NAK. Segher
[Bug lto/106540] New: [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
Bug ID: 106540
Summary: [13 Regression] lto -g ICE in
dwarf2out_register_external_die at dwarf2out.cc:6076
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
It's a very similar form of https://gcc.gnu.org/PR106334 where nix-2.10.3
package enabled -flto recently and started ICEing gcc.
This time I got the following 3-file reproducer:
// $ cat eval.hh
struct Value {
auto listItems() {
struct ListIterable {
typedef int *iterator;
iterator _begin, _end;
iterator begin() { return _begin; }
iterator end() { return _end; }
};
return ListIterable{};
}
};
// $ cat eval-cache.cc
#include "eval.hh"
void AttrCursorgetListOfStrings(Value & v) {
for (auto elem : v.listItems())
;
}
// $ cat eval.cc
#include "eval.hh"
template auto enumerate(T) {
struct iterator {
int iter;
bool operator!=(iterator) { return iter; }
void operator++() {}
auto operator*() { return 0; }
};
struct iterable_wrapper {
auto begin() { return iterator{}; }
auto end() { return iterator{}; }
};
return iterable_wrapper{};
}
void coerceToString(Value & v) {
for (auto elem : enumerate(v.listItems()))
;
}
Crashing:
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o eval.o -c eval.cc
eval.cc: In function 'void coerceToString(Value&)':
eval.cc:16:13: warning: unused variable 'elem' [-Wunused-variable]
16 | for (auto elem : enumerate(v.listItems()))
| ^~~~
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o eval-cache.o -c
eval-cache.cc
eval-cache.cc: In function 'void AttrCursorgetListOfStrings(Value&)':
eval-cache.cc:4:13: warning: unused variable 'elem' [-Wunused-variable]
4 | for (auto elem : v.listItems())
| ^~~~
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o libbug.so -shared
eval-cache.o eval.o
lto1: internal compiler error: in dwarf2out_register_external_die, at
dwarf2out.cc:6076
0xa093ff dwarf2out_register_external_die
../../gcc-13-20220731/gcc/dwarf2out.cc:6076
0x90743d lto_read_decls
../../gcc-13-20220731/gcc/lto/lto-common.cc:1952
0x908193 lto_file_finalize
../../gcc-13-20220731/gcc/lto/lto-common.cc:2271
0x908193 lto_create_files_from_ids
../../gcc-13-20220731/gcc/lto/lto-common.cc:2281
0x908193 lto_file_read
../../gcc-13-20220731/gcc/lto/lto-common.cc:2336
0x908193 read_cgraph_and_symbols(unsigned int, char const**)
../../gcc-13-20220731/gcc/lto/lto-common.cc:2784
0x8f0132 lto_main()
../../gcc-13-20220731/gcc/lto/lto.cc:626
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
Re: Reason for missing notes for incomplete-type errors in standard headers
On Fri, 5 Aug 2022 at 17:39, Julian Lenz via Gcc wrote: > > Hi everybody, > > TL;DR: > > What is the reason that `error: '' has incomplete type` does > not give a note about where the forward declaration happened for > standard library classes? Probably because the declaration happens in a system header. Does -Wsystem-headers change it?
Reason for missing notes for incomplete-type errors in standard headers
Hi everybody, TL;DR: What is the reason that `error: '' has incomplete type` does not give a note about where the forward declaration happened for standard library classes? Full: Recently, I forgot to include but had included. Due to this recent commit for gcc12 https://github.com/gcc-mirror/gcc/commit/261d5a4a459bd49942e53bc83334ccc7154a09d5 the `error: 'std::array' has incomplete type` felt like a weird regression because all other major gcc versions as well as clang compiled just fine. After many hours of debugging, I finally realised that it was just a missing header and now the error message actually makes sense. But when I experimented with this, I found that gcc does give you another `::: note: declaration of 'class SomeClass'` with line number and everything. Now, I wonder why gcc doesn't do that for standard headers (at least not in my particular case). Is there a compelling argument for that? It feels like it must be intentional. If not, I would suggest adding that because I'm pretty sure it would have spared me a couple of hours just by realising quickly that it takes `std::array` from the wrong header. Thank you in advance and keep up the great work! Julian
Re: [PATCH] Properly honor param_max_fsm_thread_path_insns in backwards threader
On 8/2/2022 7:00 AM, Richard Biener via Gcc-patches wrote:
I am trying to make sense of back_threader_profitability::profitable_path_p
and the first thing I notice is that we do
/* Threading is profitable if the path duplicated is hot but also
in a case we separate cold path from hot path and permit optimization
of the hot path later. Be on the agressive side here. In some testcases,
as in PR 78407 this leads to noticeable improvements. */
if (m_speed_p
&& ((taken_edge && optimize_edge_for_speed_p (taken_edge))
|| contains_hot_bb))
{
if (n_insns >= param_max_fsm_thread_path_insns)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, " FAIL: Jump-thread path not considered: "
"the number of instructions on the path "
"exceeds PARAM_MAX_FSM_THREAD_PATH_INSNS.\n");
return false;
}
...
}
else if (!m_speed_p && n_insns > 1)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, " FAIL: Jump-thread path not considered: "
"duplication of %i insns is needed and optimizing for
size.\n",
n_insns);
return false;
}
...
return true;
thus we apply the n_insns >= param_max_fsm_thread_path_insns only
to "hot paths". The comment above this isn't entirely clear whether
this is by design ("Be on the aggressive side here ...") but I think
this is a mistake. In fact the "hot path" check seems entirely
useless since if the path is not hot we simply continue threading it.
I think the intent here was to allow more insns to be copied if the path
was hot than if it was not not hot. But the logic seems a bit
convoluted here.
jeff
[Bug analyzer/106539] New: -fanalyzer doesn't consider that realloc could shrink the buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106539
Bug ID: 106539
Summary: -fanalyzer doesn't consider that realloc could shrink
the buffer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
realloc's success_with_move::update_model uses the new size of the buffer when
copying the contents of the old buffer, rather the minimum of the old and new
sizes - I hadn't thought of the "shrinks the buffer" case.
Consider:
#include
void *test (void)
{
void **p = (void **)malloc (sizeof (void *) * 2);
if (!p)
return NULL;
p[0] = malloc(10);
p[1] = malloc(20); /* will be leaked if p is shrunk (e.g. during a move) */
void *q = realloc (p, sizeof (void *));
if (!q)
return p;
return q;
}
-fanalyzer probably ought to complain about a leak of p[1] after p is shrunk,
but doesn't at the moment.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230 --- Comment #9 from Ulrich Drepper --- Created attachment 53419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419=edit diff -y of current and proposed output To compare the results more easily.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230 Ulrich Drepper changed: What|Removed |Added Attachment #53410|0 |1 is obsolete|| --- Comment #8 from Ulrich Drepper --- Created attachment 53418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53418=edit Update pretty printers for all? containers I spent some more time on this and should now have covered all the containers. The changes for the other containers are in line with what the previous patch produced. The output should now be as consistent as possible across all containers. Along the line some bugs have been fixed, too. To illustrate the change I'll also attach to this bug a diff -y output of the current and the proposed code.
Re: [PATCH] lower-subreg, expr: Mitigate inefficiencies derived from "(clobber (reg X))" followed by "(set (subreg (reg X)) (...))"
On 8/4/2022 6:35 AM, Takayuki 'January June' Suwa via Gcc-patches wrote: So lots, but almost double might be an overstatement :) BTW after some quick experimentation, I found that turning on -fsplit-wide-types-early would roughly (but not completely) solve the problem. Surely, the output was not so bad in the past... It could have been. Ah, hadn't realised that. If you have time to work on it, it would be really good to move over to LRA. There are plans to remove old reload. Alas you do overestimate me :) I've only been working about the GCC development for a little over a year. Well it's a lie that I'm not interested in it, but too much for me. It may actually be trivial -- change TARGET_LRA_P to be hook_bool_void_true in the xtensa port, then rebuild & test. In the couple conversions I've done it's exposed a very small number of issues that were trivially resolved. Given the what I've seen from you I would expect it's within your capabilities and there's folks here that can help if you do run into problems. jeff
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #8 from Lewis Hyatt --- (In reply to Lewis Hyatt from comment #7) > The wrong location is fixed for GCC 13. Shall I leave the PR open for now, > since there was also the issue of getting a caret pointing to the name of > macro, rather than just a diagnostic for the whole line? I can look into > that too. Patch to improve the range information on the diagnostic submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html I think if that gets applied then we could close this one.
[PATCH] libcpp: Improve location for macro names [PR66290]
When libcpp reports diagnostics whose locus is a macro name (such as for -Wunused-macros), it uses the location in the cpp_macro object that was stored by _cpp_new_macro. This is currently set to pfile->directive_line, which contains the line number only and no column information. This patch changes the stored location to the src_loc for the token defining the macro name, which includes the location and range information. libcpp/ChangeLog: PR c++/66290 * macro.cc (_cpp_create_definition): Add location argument. * internal.h (_cpp_create_definition): Adjust prototype. * directives.cc (do_define): Pass new location argument to _cpp_create_definition. (do_undef): Stop passing inferior location to cpp_warning_with_line; the default from cpp_warning is better. (cpp_pop_definition): Pass new location argument to _cpp_create_definition. * pch.cc (cpp_read_state): Likewise. gcc/testsuite/ChangeLog: PR c++/66290 * c-c++-common/cpp/macro-ranges.c: New test. * c-c++-common/cpp/line-2.c: Adapt to check for column information on macro-related libcpp warnings. * c-c++-common/cpp/line-3.c: Likewise. * c-c++-common/cpp/macro-arg-count-1.c: Likewise. * c-c++-common/cpp/pr58844-1.c: Likewise. * c-c++-common/cpp/pr58844-2.c: Likewise. * c-c++-common/cpp/warning-zero-location.c: Likewise. * c-c++-common/pragma-diag-14.c: Likewise. * c-c++-common/pragma-diag-15.c: Likewise. * g++.dg/modules/macro-2_d.C: Likewise. * g++.dg/modules/macro-4_d.C: Likewise. * g++.dg/modules/macro-4_e.C: Likewise. * g++.dg/spellcheck-macro-ordering.C: Likewise. * gcc.dg/builtin-redefine.c: Likewise. * gcc.dg/cpp/Wunused.c: Likewise. * gcc.dg/cpp/redef2.c: Likewise. * gcc.dg/cpp/redef3.c: Likewise. * gcc.dg/cpp/redef4.c: Likewise. * gcc.dg/cpp/ucnid-11-utf8.c: Likewise. * gcc.dg/cpp/ucnid-11.c: Likewise. * gcc.dg/cpp/undef2.c: Likewise. * gcc.dg/cpp/warn-redefined-2.c: Likewise. * gcc.dg/cpp/warn-redefined.c: Likewise. * gcc.dg/cpp/warn-unused-macros-2.c: Likewise. * gcc.dg/cpp/warn-unused-macros.c: Likewise. --- Notes: Hello- The PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290) was originally about the entirely wrong location for -Wunused-macros in C++ mode, which behavior was fixed by r13-1903, but before closing it out I wanted to also address a second point brought up in the PR comments, namely that we do not include column information when emitting diagnostics for macro names, such as is done for -Wunused-macros. The attached patch updates the location stored in the cpp_macro object so that it includes the column and range information for the token comprising the macro name; previously, the location was just the generic one pointing to the whole line. The change to libcpp is very small, the reason for all the testsuite changes is that I have updated all tests explicitly looking for the columnless diagnostics (with the "-:" syntax to dg-warning et al) so that they expect a column instead. I also added a new test which verifies the expected range information in diagnostics with carets. Bootstrap + regtest on x86-64 Linux looks good. Please let me know if it looks OK? Thanks! -Lewis libcpp/directives.cc | 13 +- libcpp/internal.h | 2 +- libcpp/macro.cc | 12 +- libcpp/pch.cc | 2 +- gcc/testsuite/c-c++-common/cpp/line-2.c | 2 +- gcc/testsuite/c-c++-common/cpp/line-3.c | 2 +- .../c-c++-common/cpp/macro-arg-count-1.c | 4 +- gcc/testsuite/c-c++-common/cpp/macro-ranges.c | 52 ++ gcc/testsuite/c-c++-common/cpp/pr58844-1.c| 4 +- gcc/testsuite/c-c++-common/cpp/pr58844-2.c| 4 +- .../c-c++-common/cpp/warning-zero-location.c | 2 +- gcc/testsuite/c-c++-common/pragma-diag-14.c | 2 +- gcc/testsuite/c-c++-common/pragma-diag-15.c | 2 +- gcc/testsuite/g++.dg/modules/macro-2_d.C | 4 +- gcc/testsuite/g++.dg/modules/macro-4_d.C | 4 +- gcc/testsuite/g++.dg/modules/macro-4_e.C | 2 +- .../g++.dg/spellcheck-macro-ordering.C| 2 +- gcc/testsuite/gcc.dg/builtin-redefine.c | 18 +- gcc/testsuite/gcc.dg/cpp/Wunused.c| 6 +- gcc/testsuite/gcc.dg/cpp/redef2.c | 20 +- gcc/testsuite/gcc.dg/cpp/redef3.c | 14 +- gcc/testsuite/gcc.dg/cpp/redef4.c | 520 +- gcc/testsuite/gcc.dg/cpp/ucnid-11-utf8.c | 12 +- gcc/testsuite/gcc.dg/cpp/ucnid-11.c | 12 +- gcc/testsuite/gcc.dg/cpp/undef2.c | 6 +- gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c | 10 +-
Re: [PATCH] lower-subreg, expr: Mitigate inefficiencies derived from "(clobber (reg X))" followed by "(set (subreg (reg X)) (...))"
On 8/4/2022 3:49 AM, Richard Sandiford via Gcc-patches wrote: TBH I'm surprised we still run init_regs for LRA. I thought there was a plan to stop doing that, but perhaps I misremember. Sorry I am not sure about the status of LRA... because the xtensa port is still using reload. Ah, hadn't realised that. If you have time to work on it, it would be really good to move over to LRA. There are plans to remove old reload. Definitely worth investigating. With the cc0 removal done I think the last blocker for removing the old reload pass is gone. We just need to get the remaining targets converted to LRA. It might be that old reload *does* treat a pseudo clobber as a conflict. I can't remember now. If so, then zeroing the register wouldn't be too bad (for old reload only). No idea anymore either. I'd be a bit surprised since IIRC the main purpose was to tell the old uninit warning code that the entire object was set by the subsequent libcall sequence. But all that code is long-gone. Which I think raises a question. Do we even need those CLOBBERSs anymore? As conclusion, trying to tweak the common code side may have been a bit premature. I'll consider if I can deal with those issues on the side of the target-specific code. It's likely to be at least partly a target-independent issue, so tweaking the common code makes sense in principle. Does adding !HARD_REGISTER_P (x) to: /* Show the output dies here. This is necessary for SUBREGs of pseudos since we cannot track their lifetimes correctly; hard regs shouldn't appear here except as return values. */ if (!reload_completed && !reload_in_progress && REG_P (x) && !reg_overlap_mentioned_p (x, y)) emit_clobber (x); in emit_move_complex_parts help? If so, I think we should do at least that much. If we can't remove the CLOBBERs entirely, then this sounds like a good thing, even if it doesn't help this specific case. jeff
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 --- Comment #2 from Jose E. Marchesi --- (In reply to Andrew Pinski from comment #1) > > This option is used in the kernel source tree for some BPF programs. > > Why not fix the sources? Seems not hard to add a cast or two. That's what I would recommend. But since LLVM supports that switch it becomes difficult to convince people to not use it in case they are already using it. Sent a proposal patch in: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599393.html
Re: [PATCH] Adjust backwards threader costing of PHIs
On 8/5/2022 7:58 AM, Richard Biener wrote: The following adjusts the costing of PHIs to match how I understand the comment and maybe the original intent. The will be no non-degenerate PHI nodes remaining on the threaded path but when there are alternate path exits PHI nodes at their destinations will likely require extra copies on those edges and that's what we want to account for. Jeff added this code long time ago and at least the special-casing of (just) m_name does not make sense anymore. Unfortunately this tweaks heuristics enough to make the threader thread an unfortunate path in libgomp/team.c so that -Walloca-larger-than diagnoses an allocation of -1 elements. I'm not 100% sure this condition is impossible so I've added a guard not allocating zero or "less" stack. There's also an uninit diagnostic in opts.cc about best_math::m_best_candidate_len that looks like a false positive but all but this member are initialized so the patch initializes this one as well to avoid this false positive. I have yet to analyze some fallout as well: FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 20) FAIL: gcc.dg/tree-ssa/phi_on_compare-4.c scan-tree-dump-times dom2 "Removing bas ic block" 1 FAIL: gcc.dg/tree-ssa/pr59597.c scan-tree-dump-times threadfull1 "Registering jump thread" 4 FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "%" 0 FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 % " 0 FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 / " 0 FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "__builtin_abort" 1 the early threading fails are because we now account for the mid-exit PHI copies and early threading has a limit of a single copied insn. But this testcase was never about threading but VRP which seemingly regressed meanwhile... Bootstrapped and tested (with the above FAILs) on x86_64-unknown-linux-gnu. Any comments besides the FAILout? I don't recall adding that code, but I did find it in the archives. https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443452.html But even with that and reviewing the PR, I still don't remember much about this particular chunk of code. I do recall that I was never actually happy with pr69196 state and that's why we've kept it open all these years. It doesn't look like tree-ssa/pr69196 has regressed, so if you're happy with the patch, I've got no objections. jeff
Re: [GCC][PATCH] arm: Add support for Arm Cortex-M85 CPU.
On 05/08/2022 16:20, Srinath Parvathaneni via Gcc-patches wrote: Hi, This patch adds the -mcpu support for the Arm Cortex-M85 CPU which is an Armv8.1-M Mainline CPU supporting MVE and PACBTI by default. -mpcu=cortex-m85 switch by default matches to -march=armv8.1-m.main+pacbti+mve.fp+fp.dp. Also following options are provided to disable default features. +nomve.fp (disables MVE Floating point) +nomve (disables MVE Integer and MVE Floating point) +nodsp (disables dsp, MVE Integer and MVE Floating point) +nopacbti (disables pacbti) +nofp (disables floating point and MVE floating point) Regression tested on arm-none-eabi and bootstrapped on arm-none-linux-gnueabihf. Ok for master? Regards, Srinath. gcc/ChangeLog: 2022-08-05 Srinath Parvathaneni * config/arm/arm-cpus.in (cortex-m85): Define new cpu. CPU is an acronym, so: s/new cpu/new CPU/ * config/arm/arm-tables.opt: Regenerate. * config/arm/arm-tune.md: Likewise. * config/arm/t-rmprofile: Re-use multilibs. * doc/invoke.texi (Arm Options): Document -mcpu=cortex-m85. * (-mfix-cmse-cve-2021-35465): Likewise. gcc/testsuite/ChangeLog: 2022-08-05 Srinath Parvathaneni * gcc.target/arm/multilib.exp: Add tests for cortex-m85. ### Attachment also inlined for ease of reply### diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in index 9502a34fa974744f02ded4f32c03de6169950120..a6f364309f8728d6d2264b4e60feb75d51b87b64 100644 --- a/gcc/config/arm/arm-cpus.in +++ b/gcc/config/arm/arm-cpus.in @@ -1643,6 +1643,21 @@ begin cpu cortex-m55 vendor 41 end cpu cortex-m55 +begin cpu cortex-m85 + cname cortexm85 + tune flags LDSCHED + architecture armv8.1-m.main+pacbti+mve.fp+fp.dp + option nopacbti remove pacbti + option nomve.fp remove mve_float + option nomve remove mve mve_float + option nofp remove ALL_FP mve_float + option nodsp remove MVE mve_float + isa quirk_no_asmcpu quirk_vlldm + costs v7m + part 0xd23 + vendor 41 +end cpu cortex-m85 + # V8 R-profile implementations. begin cpu cortex-r52 cname cortexr52 diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt index ef0cc5ef0c87ce37958fc0ac9b1623078b890187..54f87da7852b3e495da9fd08106d9f6bd7c99716 100644 --- a/gcc/config/arm/arm-tables.opt +++ b/gcc/config/arm/arm-tables.opt @@ -282,6 +282,9 @@ Enum(processor_type) String(cortex-m35p) Value( TARGET_CPU_cortexm35p) EnumValue Enum(processor_type) String(cortex-m55) Value( TARGET_CPU_cortexm55) +EnumValue +Enum(processor_type) String(cortex-m85) Value( TARGET_CPU_cortexm85) + EnumValue Enum(processor_type) String(cortex-r52) Value( TARGET_CPU_cortexr52) diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md index 3422553604245035089e4f52b3feb9db4c51b2b5..27cafe9b4caf9270cb5f537c988d57715495a207 100644 --- a/gcc/config/arm/arm-tune.md +++ b/gcc/config/arm/arm-tune.md @@ -49,6 +49,6 @@ cortexa710,cortexx1,neoversen1, cortexa75cortexa55,cortexa76cortexa55,neoversev1, neoversen2,cortexm23,cortexm33, - cortexm35p,cortexm55,cortexr52, + cortexm35p,cortexm55,cortexm85,cortexr52, cortexr52plus" (const (symbol_ref "((enum attr_tune) arm_tune)"))) diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile index fe46a1efa1a8b212e6f4051283573debfc386ff8..77e248e47feeddb2328a82aec6b485ff0f6fd62e 100644 --- a/gcc/config/arm/t-rmprofile +++ b/gcc/config/arm/t-rmprofile @@ -97,6 +97,13 @@ MULTILIB_MATCHES += $(foreach FP, $(v8_1m_sp_variants), \ MULTILIB_MATCHES += $(foreach FP, $(v8_1m_dp_variants), \ march?armv8-m.main+fp.dp=mlibarch?armv8.1-m.main$(FP)) +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+pacbti+fp.dp+mve.fp +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+pacbti+fp.dp+mve.fp +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+pacbti+fp.dp+mve +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+pacbti+fp.dp+mve +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+dsp+pacbti+fp.dp +MULTILIB_MATCHES += march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+dsp+pacbti+fp.dp + This seems like generic pac/bti support in armv8.1-m.main, so should be a separate patch from the cortex-m85 support. There should also be tests for these cases when -march= is used rather than -mcpu in multilib.exp # Map all mbranch-protection values other than 'none' to 'standard'. MULTILIB_MATCHES += mbranch-protection?standard=mbranch-protection?bti MULTILIB_MATCHES += mbranch-protection?standard=mbranch-protection?pac-ret diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index a2be3446594822f0b13dc7ba92ada4213a3a965c..47988ca6bedccc8efd1801a784d4f313959e8bb4 100644 --- a/gcc/doc/invoke.texi +++
[PATCH] Add warning options -W[no-]compare-distinct-pointer-types
GCC emits pedwarns unconditionally when comparing pointers of
different types, for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
return 0;
return 1;
}
/home/jemarch/foo.c: In function ‘xdp_context’:
/home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types
lacks a cast
15 | if (metadata + 1 > data)
|^
LLVM supports an option -W[no-]compare-distinct-pointer-types that can
be used in order to enable or disable the emission of such warnings.
It is enabled by default.
This patch adds the same options to GCC.
Documentation and testsuite updated included.
Regtested in x86_64-linu-gnu.
No regressions observed.
gcc/ChangeLog:
PR c/106537
* doc/invoke.texi (Option Summary): Mention
-Wcompare-distinct-pointer-types under `Warning Options'.
(Warning Options): Document -Wcompare-distinct-pointer-types.
gcc/c-family/ChangeLog:
PR c/106537
* c.opt (Wcompare-distinct-pointer-types): New option.
gcc/c/ChangeLog:
PR c/106537
* c-typeck.cc (build_binary_op): Warning on comparing distinct
pointer types only when -Wcompare-distinct-pointer-types.
gcc/testsuite/ChangeLog:
PR c/106537
* gcc.c-torture/compile/pr106537-1.c: New test.
* gcc.c-torture/compile/pr106537-2.c: Likewise.
* gcc.c-torture/compile/pr106537-3.c: Likewise.
---
gcc/c-family/c.opt | 4
gcc/c/c-typeck.cc| 8 +---
gcc/doc/invoke.texi | 6 ++
gcc/testsuite/gcc.c-torture/compile/pr106537-1.c | 23 +++
gcc/testsuite/gcc.c-torture/compile/pr106537-2.c | 21 +
gcc/testsuite/gcc.c-torture/compile/pr106537-3.c | 21 +
6 files changed, 80 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr106537-1.c
create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr106537-2.c
create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr106537-3.c
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 44e1a60ce24..54e08e83eb2 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1844,6 +1844,10 @@ Winvalid-imported-macros
C++ ObjC++ Var(warn_imported_macros) Warning
Warn about macros that have conflicting header units definitions.
+Wcompare-distinct-pointer-types
+C C++ Var(warn_compare_distinct_pointer_types) Warning Init(1)
+Warn if pointers of distinct types are compared without a cast.
+
flang-info-include-translate
C++ Var(note_include_translate_yes)
Note #include directives translated to import declarations.
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 8514488b7a5..40a66530586 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -12397,7 +12397,8 @@ build_binary_op (location_t location, enum tree_code
code,
}
else
/* Avoid warning about the volatile ObjC EH puts on decls. */
- if (!objc_ok)
+ if (!objc_ok
+&& warn_compare_distinct_pointer_types)
pedwarn (location, 0,
"comparison of distinct pointer types lacks a cast");
@@ -12517,8 +12518,9 @@ build_binary_op (location_t location, enum tree_code
code,
int qual = ENCODE_QUAL_ADDR_SPACE (as_common);
result_type = build_pointer_type
(build_qualified_type (void_type_node, qual));
- pedwarn (location, 0,
- "comparison of distinct pointer types lacks a cast");
+ if (warn_compare_distinct_pointer_types)
+pedwarn (location, 0,
+ "comparison of distinct pointer types lacks a cast");
}
}
else if (code0 == POINTER_TYPE && null_pointer_constant_p (orig_op1))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 863580b3710..a4a594a336d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -341,6 +341,7 @@ Objective-C and Objective-C++ Dialects}.
-Wcast-align -Wcast-align=strict -Wcast-function-type -Wcast-qual @gol
-Wchar-subscripts @gol
-Wclobbered -Wcomment @gol
+-Wcompare-distinct-pointer-types @gol
-Wconversion -Wno-coverage-mismatch -Wno-cpp @gol
-Wdangling-else -Wdangling-pointer -Wdangling-pointer=@var{n} @gol
-Wdate-time @gol
@@ -8629,6 +8630,11 @@ programs.
Warn for variables that might be changed by @code{longjmp} or
@code{vfork}. This warning is also enabled by @option{-Wextra}.
+@item -Wcompare-distinct-pointer-types
+@opindex Wcompare-distinct-pointer-types
+Warn if pointers of distinct types are compared without a cast. This
+warning is enabled by default.
+
@item -Wconversion
@opindex Wconversion
@opindex
[Bug c++/106538] New: Reject-valid: Substitution failure causes error with unsatisfied constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106538 Bug ID: 106538 Summary: Reject-valid: Substitution failure causes error with unsatisfied constraint Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dv at vollmann dot ch Target Milestone: --- Created attachment 53417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53417=edit Example program that produces the error If in the attached program ADD_CONSTRAINED_OVERLOAD is defined, the tag_invoke for connect_t is instantiated. This instantiation fails for a number of reasons so GCC should continue with the next overload. However in this case GCC rejects the code claiming the contrained is not satisfied (which is correct, but shouldn't cause a reject).
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic --- Comment #1 from Andrew Pinski --- > This option is used in the kernel source tree for some BPF programs. Why not fix the sources? Seems not hard to add a cast or two.
Re: [PATCH] backthreader dump fix
On 8/5/2022 6:31 AM, Richard Biener via Gcc-patches wrote: This fixes odd SUCCEEDED dumps from the backthreader registry that can happen even though register_jump_thread cancelled the thread as invalid. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-ssa-threadbackward.cc (back_threader::maybe_register_path): Check whether the registry register_path rejected the path. (back_threader_registry::register_path): Return whether register_jump_thread succeeded. LGTM. jeff
[GCC][PATCH] arm: Add support for Arm Cortex-M85 CPU.
Hi,
This patch adds the -mcpu support for the Arm Cortex-M85 CPU which is an
Armv8.1-M Mainline CPU supporting MVE and PACBTI by default.
-mpcu=cortex-m85 switch by default matches to
-march=armv8.1-m.main+pacbti+mve.fp+fp.dp.
Also following options are provided to disable default features.
+nomve.fp (disables MVE Floating point)
+nomve (disables MVE Integer and MVE Floating point)
+nodsp (disables dsp, MVE Integer and MVE Floating point)
+nopacbti (disables pacbti)
+nofp (disables floating point and MVE floating point)
Regression tested on arm-none-eabi and bootstrapped on arm-none-linux-gnueabihf.
Ok for master?
Regards,
Srinath.
gcc/ChangeLog:
2022-08-05 Srinath Parvathaneni
* config/arm/arm-cpus.in (cortex-m85): Define new cpu.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Likewise.
* config/arm/t-rmprofile: Re-use multilibs.
* doc/invoke.texi (Arm Options): Document -mcpu=cortex-m85.
* (-mfix-cmse-cve-2021-35465): Likewise.
gcc/testsuite/ChangeLog:
2022-08-05 Srinath Parvathaneni
* gcc.target/arm/multilib.exp: Add tests for cortex-m85.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
index
9502a34fa974744f02ded4f32c03de6169950120..a6f364309f8728d6d2264b4e60feb75d51b87b64
100644
--- a/gcc/config/arm/arm-cpus.in
+++ b/gcc/config/arm/arm-cpus.in
@@ -1643,6 +1643,21 @@ begin cpu cortex-m55
vendor 41
end cpu cortex-m55
+begin cpu cortex-m85
+ cname cortexm85
+ tune flags LDSCHED
+ architecture armv8.1-m.main+pacbti+mve.fp+fp.dp
+ option nopacbti remove pacbti
+ option nomve.fp remove mve_float
+ option nomve remove mve mve_float
+ option nofp remove ALL_FP mve_float
+ option nodsp remove MVE mve_float
+ isa quirk_no_asmcpu quirk_vlldm
+ costs v7m
+ part 0xd23
+ vendor 41
+end cpu cortex-m85
+
# V8 R-profile implementations.
begin cpu cortex-r52
cname cortexr52
diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
index
ef0cc5ef0c87ce37958fc0ac9b1623078b890187..54f87da7852b3e495da9fd08106d9f6bd7c99716
100644
--- a/gcc/config/arm/arm-tables.opt
+++ b/gcc/config/arm/arm-tables.opt
@@ -282,6 +282,9 @@ Enum(processor_type) String(cortex-m35p) Value(
TARGET_CPU_cortexm35p)
EnumValue
Enum(processor_type) String(cortex-m55) Value( TARGET_CPU_cortexm55)
+EnumValue
+Enum(processor_type) String(cortex-m85) Value( TARGET_CPU_cortexm85)
+
EnumValue
Enum(processor_type) String(cortex-r52) Value( TARGET_CPU_cortexr52)
diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md
index
3422553604245035089e4f52b3feb9db4c51b2b5..27cafe9b4caf9270cb5f537c988d57715495a207
100644
--- a/gcc/config/arm/arm-tune.md
+++ b/gcc/config/arm/arm-tune.md
@@ -49,6 +49,6 @@
cortexa710,cortexx1,neoversen1,
cortexa75cortexa55,cortexa76cortexa55,neoversev1,
neoversen2,cortexm23,cortexm33,
- cortexm35p,cortexm55,cortexr52,
+ cortexm35p,cortexm55,cortexm85,cortexr52,
cortexr52plus"
(const (symbol_ref "((enum attr_tune) arm_tune)")))
diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile
index
fe46a1efa1a8b212e6f4051283573debfc386ff8..77e248e47feeddb2328a82aec6b485ff0f6fd62e
100644
--- a/gcc/config/arm/t-rmprofile
+++ b/gcc/config/arm/t-rmprofile
@@ -97,6 +97,13 @@ MULTILIB_MATCHES += $(foreach FP, $(v8_1m_sp_variants), \
MULTILIB_MATCHES += $(foreach FP, $(v8_1m_dp_variants), \
march?armv8-m.main+fp.dp=mlibarch?armv8.1-m.main$(FP))
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+pacbti+fp.dp+mve.fp
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+pacbti+fp.dp+mve.fp
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+pacbti+fp.dp+mve
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+pacbti+fp.dp+mve
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=march?armv8.1-m.main+dsp+pacbti+fp.dp
+MULTILIB_MATCHES +=
march?armv8.1-m.main+pacbti+fp.dp=mlibarch?armv8.1-m.main+dsp+pacbti+fp.dp
+
# Map all mbranch-protection values other than 'none' to 'standard'.
MULTILIB_MATCHES += mbranch-protection?standard=mbranch-protection?bti
MULTILIB_MATCHES +=
mbranch-protection?standard=mbranch-protection?pac-ret
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
a2be3446594822f0b13dc7ba92ada4213a3a965c..47988ca6bedccc8efd1801a784d4f313959e8bb4
100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -21079,7 +21079,7 @@ Permissible names are: @samp{arm7tdmi},
@samp{arm7tdmi-s}, @samp{arm710t},
@samp{cortex-r7}, @samp{cortex-r8}, @samp{cortex-r52}, @samp{cortex-r52plus},
@samp{cortex-m0}, @samp{cortex-m0plus}, @samp{cortex-m1}, @samp{cortex-m3},
@samp{cortex-m4}, @samp{cortex-m7}, @samp{cortex-m23}, @samp{cortex-m33},
Re: [RFA configure parts] aarch64: Make cc1 handle --with options
On 05/08/2022 14:53, Richard Sandiford via Gcc-patches wrote:
Richard Earnshaw writes:
On 13/06/2022 15:33, Richard Sandiford via Gcc-patches wrote:
On aarch64, --with-arch, --with-cpu and --with-tune only have an
effect on the driver, so “./xgcc -B./ -O3” can give significantly
different results from “./cc1 -O3”. --with-arch did have a limited
effect on ./cc1 in previous releases, although it didn't work
entirely correctly.
Being of a lazy persuasion, I've got used to ./cc1 selecting SVE for
--with-arch=armv8.2-a+sve without having to supply an explicit -march,
so this patch makes ./cc1 emulate the relevant OPTION_DEFAULT_SPECS.
It relies on Wilco's earlier clean-ups.
The patch makes config.gcc define WITH_FOO_STRING macros for each
supported --with-foo option. This could be done only in aarch64-
specific code, but I thought it could be useful on other targets
too (and can be safely ignored otherwise). There didn't seem to
be any existing and potentially clashing uses of macros with this
style of name.
Tested on aarch64-linux-gnu & x86_64-linux-gnu. OK for the configure
bits?
Richard
gcc/
* config.gcc: Define WITH_FOO_STRING macros for each supported
--with-foo option.
* config/aarch64/aarch64.cc (aarch64_override_options): Emulate
OPTION_DEFAULT_SPECS.
* config/aarch64/aarch64.h (OPTION_DEFAULT_SPECS): Reference the above.
---
gcc/config.gcc| 14 ++
gcc/config/aarch64/aarch64.cc | 8
gcc/config/aarch64/aarch64.h | 5 -
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index cdbefb5b4f5..e039230431c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5865,6 +5865,20 @@ else
configure_default_options="{ ${t} }"
fi
+for option in $supported_defaults
+do
+ lc_option=`echo $option | sed s/-/_/g`
+ uc_option=`echo $lc_option | tr a-z A-Z`
+ eval "val=\$with_$lc_option"
+ if test -n "$val"
+ then
+ val="\\\"$val\\\""
+ else
+ val=nullptr
+ fi
+ tm_defines="$tm_defines WITH_${uc_option}_STRING=$val"
+done
This bit would really be best reviewed by a non-arm maintainer. It
generally looks OK. My only comment would be why define anything if the
corresponding --with-foo was not specified. They you can use #ifdef to
test if the user specified a default.
Yeah, could do it that way instead, but:
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index d21e041eccb..0bc700b81ad 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -18109,6 +18109,14 @@ aarch64_override_options (void)
if (aarch64_branch_protection_string)
aarch64_validate_mbranch_protection (aarch64_branch_protection_string);
+ /* Emulate OPTION_DEFAULT_SPECS. */
+ if (!aarch64_arch_string && !aarch64_cpu_string)
+aarch64_arch_string = WITH_ARCH_STRING;
+ if (!aarch64_arch_string && !aarch64_cpu_string)
+aarch64_cpu_string = WITH_CPU_STRING;
+ if (!aarch64_cpu_string && !aarch64_tune_string)
+aarch64_tune_string = WITH_TUNE_STRING;
(without the preprocessor stuff) IMO reads better. If a preprocessor
is/isn't present test turns out to be useful, perhaps we should add
macros like HAVE_WITH_TUNE/WITH_TUNE_PRESENT/... too? I guess it
should only be done when something needs it though.
It's relatively easy to add
#ifndef WITH_TUNE_STRING
#define WITH_TUNE_STRING (nulptr)
#endif
in a header, but much harder to go the other way. The case I was
thinking of was something like:
#if !defined(WITH_ARCH_STRING) && !defined(WITH_CPU_STRING)
#define WITH_ARCH_STRING ""
#endif
which saves having to have yet another level of fallback if nothing has
been specified, but this is next to impossible if the macros are
unconditionally defined.
R.
Thanks,
Richard
+
/* -mcpu=CPU is shorthand for -march=ARCH_FOR_CPU, -mtune=CPU.
If either of -march or -mtune is given, they override their
respective component of -mcpu. */
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 80cfe4b7407..3122dbd7098 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1267,7 +1267,10 @@ extern enum aarch64_code_model aarch64_cmodel;
/* Support for configure-time --with-arch, --with-cpu and --with-tune.
--with-arch and --with-cpu are ignored if either -mcpu or -march is used.
--with-tune is ignored if either -mtune or -mcpu is used (but is not
- affected by -march). */
+ affected by -march).
+
+ There is corresponding code in aarch64_override_options that emulates
+ this behavior when cc1 are invoked directly. */
#define OPTION_DEFAULT_SPECS \
{"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" }, \
{"cpu", "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
Re: [PATCH 3/4] match.pd: Teach forwprop to handle VLA VEC_PERM_EXPRs with VLS CONSTRUCTORs as arguments
On Fri, 5 Aug 2022 at 18:26, Andre Vieira (lists) wrote: > > Hi, > > This patch is part of the WIP patch that follows in this series. It's > goal is to teach forwprop to handle VLA VEC_PERM_EXPRs with VLS > CONSTRUCTORs as arguments as preparation for the 'VLA constructor' hook > approach. /* Shuffle of a constructor. */ bool ret = false; - tree res_type = TREE_TYPE (arg0); + tree res_type = TREE_TYPE (gimple_get_lhs (stmt)); tree opt = fold_ternary (VEC_PERM_EXPR, res_type, arg0, arg1, op2); if (!opt || (TREE_CODE (opt) != CONSTRUCTOR && TREE_CODE (opt) != VECTOR_CST)) This has to be TREE_TYPE (arg0). I had changed it to TREE_TYPE (gimple_assign_lhs (stmt)) and it caused several ICE's on ppc64le (PR106360) For details, see: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598611.html I currently have a patch in review that extends fold_vec_perm to handle differing vector lengths: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599126.html Thanks, Prathamesh > > Kind Regards, > Andre
[committed] libstdc++: Add feature test macro for
I forgot to add this macro to the new header.
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/scope (__cpp_lib_experimental_scope):
Define.
* testsuite/experimental/scopeguard/uniqueres.cc: Check macro.
---
libstdc++-v3/include/experimental/scope | 2 ++
libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libstdc++-v3/include/experimental/scope
b/libstdc++-v3/include/experimental/scope
index 37a57b38af7..208fadc513e 100644
--- a/libstdc++-v3/include/experimental/scope
+++ b/libstdc++-v3/include/experimental/scope
@@ -43,6 +43,8 @@ namespace std _GLIBCXX_VISIBILITY(default)
_GLIBCXX_BEGIN_NAMESPACE_VERSION
namespace experimental::inline fundamentals_v3
{
+#define __cpp_lib_experimental_scope 201902
+
template
concept __not_same_as = !same_as<_Tp, _Up>;
diff --git a/libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc
b/libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc
index 7690572ab19..fe9d6ee7cfc 100644
--- a/libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc
+++ b/libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc
@@ -4,6 +4,12 @@
#include
#include
+#ifndef __cpp_lib_experimental_scope
+# error Feature-test macro is not defined.
+#elif __cpp_lib_experimental_scope < 201902
+# error Feature-test macro has bad value.
+#endif
+
using std::experimental::unique_resource;
void
--
2.37.1
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 --- Comment #3 from Gabriel Ravier --- Considering the comment appears to be from 1993 (see commit d9fc6069c69564ce7fecd9ca0ce1bbe0b3c130ef), it having become wrong since then doesn't seem particularly surprising :p
Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]
Ping^2.
On Wed, 20 Jul 2022, Alexander Monakov wrote:
>
> Ping.
>
> On Thu, 7 Jul 2022, Alexander Monakov via Gcc-patches wrote:
>
> > From: Artem Klimov
> >
> > Fix PR99619, which asks to optimize TLS model based on visibility.
> > The fix is implemented as an IPA optimization: this allows to take
> > optimized visibility status into account (as well as avoid modifying
> > all language frontends).
> >
> > 2022-04-17 Artem Klimov
> >
> > gcc/ChangeLog:
> >
> > * ipa-visibility.cc (function_and_variable_visibility): Promote
> > TLS access model afer visibility optimizations.
> > * varasm.cc (have_optimized_refs): New helper.
> > (optimize_dyn_tls_for_decl_p): New helper. Use it ...
> > (decl_default_tls_model): ... here in place of 'optimize' check.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/tls/vis-attr-gd.c: New test.
> > * gcc.dg/tls/vis-attr-hidden-gd.c: New test.
> > * gcc.dg/tls/vis-attr-hidden.c: New test.
> > * gcc.dg/tls/vis-flag-hidden-gd.c: New test.
> > * gcc.dg/tls/vis-flag-hidden.c: New test.
> > * gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
> > * gcc.dg/tls/vis-pragma-hidden.c: New test.
> >
> > Co-Authored-By: Alexander Monakov
> > Signed-off-by: Artem Klimov
> > ---
> >
> > v2: run the new loop in ipa-visibility only in the whole-program IPA pass;
> > in decl_default_tls_model, check if any referring function is optimized
> > when 'optimize == 0' (when running in LTO mode)
> >
> >
> > Note for reviewers: I noticed there's a place which tries to avoid TLS
> > promotion, but the comment seems wrong and I could not find a testcase.
> > I'd suggest we remove it. The compiler can only promote general-dynamic
> > to local-dynamic and initial-exec to local-exec. The comment refers to
> > promoting x-dynamic to y-exec, but that cannot happen AFAICT:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8e1ba78f1b8eedd6c65c6f0e6d6d09a801de5d3d
> >
> >
> > gcc/ipa-visibility.cc | 19 +++
> > gcc/testsuite/gcc.dg/tls/vis-attr-gd.c| 12 +++
> > gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c | 13
> > gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c| 12 +++
> > gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c | 13
> > gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c| 12 +++
> > .../gcc.dg/tls/vis-pragma-hidden-gd.c | 17 ++
> > gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c | 16 ++
> > gcc/varasm.cc | 32 ++-
> > 9 files changed, 145 insertions(+), 1 deletion(-)
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c
> > create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c
> >
> > diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
> > index 8a27e7bcd..3ed2b7cf6 100644
> > --- a/gcc/ipa-visibility.cc
> > +++ b/gcc/ipa-visibility.cc
> > @@ -873,6 +873,25 @@ function_and_variable_visibility (bool whole_program)
> > }
> > }
> >
> > + if (symtab->state >= IPA_SSA)
> > +{
> > + FOR_EACH_VARIABLE (vnode)
> > + {
> > + tree decl = vnode->decl;
> > +
> > + /* Upgrade TLS access model based on optimized visibility status,
> > +unless it was specified explicitly or no references remain. */
> > + if (DECL_THREAD_LOCAL_P (decl)
> > + && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl))
> > + && vnode->ref_list.referring.length ())
> > + {
> > + enum tls_model new_model = decl_default_tls_model (decl);
> > + gcc_checking_assert (new_model >= decl_tls_model (decl));
> > + set_decl_tls_model (decl, new_model);
> > + }
> > + }
> > +}
> > +
> >if (dump_file)
> > {
> >fprintf (dump_file, "\nMarking local functions:");
> > diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> > index 4db8506b1..de149e82c 100644
> > --- a/gcc/varasm.cc
> > +++ b/gcc/varasm.cc
> > @@ -6679,6 +6679,36 @@ init_varasm_once (void)
> > #endif
> > }
> >
> > +/* Determine whether SYMBOL is used in any optimized function. */
> > +
> > +static bool
> > +have_optimized_refs (struct symtab_node *symbol)
> > +{
> > + struct ipa_ref *ref;
> > +
> > + for (int i = 0; symbol->iterate_referring (i, ref); i++)
> > +{
> > + cgraph_node *cnode = dyn_cast (ref->referring);
> > +
> > + if (cnode && opt_for_fn (cnode->decl, optimize))
> > + return true;
> > +}
> > +
> > + return false;
> > +}
> > +
> > +/* Check if promoting general-dynamic TLS access model to local-dynamic is
> > + desirable for DECL. */
> > +
> > +static bool
[committed] libstdc++: Implement from LFTSv3
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/experimental/scope: New file.
* testsuite/experimental/scopeguard/uniqueres.cc: New test.
* testsuite/experimental/scopeguard/exit.cc: New test.
---
libstdc++-v3/include/Makefile.am | 1 +
libstdc++-v3/include/Makefile.in | 1 +
libstdc++-v3/include/experimental/scope | 495 ++
.../testsuite/experimental/scopeguard/exit.cc | 300 +++
.../experimental/scopeguard/uniqueres.cc | 360 +
5 files changed, 1157 insertions(+)
create mode 100644 libstdc++-v3/include/experimental/scope
create mode 100644 libstdc++-v3/testsuite/experimental/scopeguard/exit.cc
create mode 100644 libstdc++-v3/testsuite/experimental/scopeguard/uniqueres.cc
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 069a16ec769..3eeb407a57f 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -757,6 +757,7 @@ experimental_headers = \
${experimental_srcdir}/random \
${experimental_srcdir}/ratio \
${experimental_srcdir}/regex \
+ ${experimental_srcdir}/scope \
${experimental_srcdir}/set \
${experimental_srcdir}/simd \
${experimental_srcdir}/socket \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 36eff73139d..e24563caaed 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1115,6 +1115,7 @@ experimental_headers = \
${experimental_srcdir}/random \
${experimental_srcdir}/ratio \
${experimental_srcdir}/regex \
+ ${experimental_srcdir}/scope \
${experimental_srcdir}/set \
${experimental_srcdir}/simd \
${experimental_srcdir}/socket \
diff --git a/libstdc++-v3/include/experimental/scope
b/libstdc++-v3/include/experimental/scope
new file mode 100644
index 000..37a57b38af7
--- /dev/null
+++ b/libstdc++-v3/include/experimental/scope
@@ -0,0 +1,495 @@
+// -*- C++ -*-
+
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+//
[PATCH] Adjust backwards threader costing of PHIs
The following adjusts the costing of PHIs to match how I understand
the comment and maybe the original intent. The will be no
non-degenerate PHI nodes remaining on the threaded path but when there
are alternate path exits PHI nodes at their destinations will likely
require extra copies on those edges and that's what we want to account
for.
Jeff added this code long time ago and at least the special-casing
of (just) m_name does not make sense anymore.
Unfortunately this tweaks heuristics enough to make the threader
thread an unfortunate path in libgomp/team.c so that
-Walloca-larger-than diagnoses an allocation of -1 elements. I'm
not 100% sure this condition is impossible so I've added a guard
not allocating zero or "less" stack. There's also an uninit
diagnostic in opts.cc about best_math::m_best_candidate_len that
looks like a false positive but all but this member are initialized
so the patch initializes this one as well to avoid this false
positive.
I have yet to analyze some fallout as well:
FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 20)
FAIL: gcc.dg/tree-ssa/phi_on_compare-4.c scan-tree-dump-times dom2 "Removing bas
ic block" 1
FAIL: gcc.dg/tree-ssa/pr59597.c scan-tree-dump-times threadfull1 "Registering
jump thread" 4
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "%" 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 % " 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 / " 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "__builtin_abort" 1
the early threading fails are because we now account for the mid-exit
PHI copies and early threading has a limit of a single copied insn.
But this testcase was never about threading but VRP which seemingly
regressed meanwhile...
Bootstrapped and tested (with the above FAILs) on
x86_64-unknown-linux-gnu.
Any comments besides the FAILout?
Thanks,
Richard.
gcc/
* tree-ssa-threadbackward.cc
(back_threader_profitability::profitable_path_p): Rewrite
the costing of PHIs to instead reflect the cost of alternate
path exits. Remove m_name argument.
(back_threader::find_paths_to_names): Adjust.
(back_threader::maybe_register_path): Likewise.
* spellcheck.h (best_math::m_best_candidate_len): Initialize.
libgomp/
* team.c (gomp_team_start): Guard alloca.
---
gcc/spellcheck.h | 3 +-
gcc/tree-ssa-threadbackward.cc | 65 --
libgomp/team.c | 5 +--
3 files changed, 28 insertions(+), 45 deletions(-)
diff --git a/gcc/spellcheck.h b/gcc/spellcheck.h
index 3706de38a9d..1b76a54b678 100644
--- a/gcc/spellcheck.h
+++ b/gcc/spellcheck.h
@@ -95,7 +95,8 @@ class best_match
: m_goal (goal_traits::get_string (goal)),
m_goal_len (goal_traits::get_length (goal)),
m_best_candidate (NULL),
-m_best_distance (best_distance_so_far)
+m_best_distance (best_distance_so_far),
+m_best_candidate_len (0)
{}
/* Compare the edit distance between CANDIDATE and m_goal,
diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 332a1d2a1dd..3377e648445 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -64,7 +64,7 @@ public:
back_threader_profitability (bool speed_p)
: m_speed_p (speed_p)
{ }
- bool profitable_path_p (const vec &, tree name, edge taken,
+ bool profitable_path_p (const vec &, edge taken,
bool *irreducible_loop = NULL);
private:
const bool m_speed_p;
@@ -241,7 +241,7 @@ back_threader::maybe_register_path ()
else
{
bool irreducible = false;
- if (m_profit.profitable_path_p (m_path, m_name, taken_edge,
+ if (m_profit.profitable_path_p (m_path, taken_edge,
)
&& debug_counter ()
&& m_registry.register_path (m_path, taken_edge))
@@ -348,7 +348,7 @@ back_threader::find_paths_to_names (basic_block bb, bitmap
interesting)
// Try to resolve the path without looking back.
if (m_path.length () > 1
- && (!m_profit.profitable_path_p (m_path, m_name, NULL)
+ && (!m_profit.profitable_path_p (m_path, NULL)
|| maybe_register_path ()))
;
@@ -529,9 +529,6 @@ back_threader::debug ()
/* Examine jump threading path PATH and return TRUE if it is profitable to
thread it, otherwise return FALSE.
- NAME is the SSA_NAME of the variable we found to have a constant
- value on PATH. If unknown, SSA_NAME is NULL.
-
If the taken edge out of the path is known ahead of time it is passed in
TAKEN_EDGE, otherwise it is NULL.
@@ -543,7 +540,6 @@ back_threader::debug ()
bool
back_threader_profitability::profitable_path_p (const vec _path,
- tree name,
edge taken_edge,
☠ Buildbot (GNU Toolchain): gccrust - failed 'grep unexpected ...' (failure) (master)
A new failure has been detected on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/3/builds/290 Build state: failed 'grep unexpected ...' (failure) Revision: f70783d06336dbd94c63f37dd5623d4ffdc2e4a5 Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/4/logs/stdio - warnings (32): https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/4/logs/warnings__32_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/11/logs/stdio - 12: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/12/logs/stdio - 13: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/13/logs/stdio - 14: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/14/logs/stdio - 15: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/15/logs/stdio - 16: make clean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/290/steps/16/logs/stdio A new failure has been detected on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/27/builds/289 Build state: failed 'grep unexpected ...' (failure) Revision: f70783d06336dbd94c63f37dd5623d4ffdc2e4a5 Worker: debian-i386-2 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/4/logs/stdio - warnings (50): https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/4/logs/warnings__50_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/289/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio:
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Tamar Christina --- Fixed now.
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #10 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:1878ab3650d8c646a4db364df388adaec2a29870 commit r13-1975-g1878ab3650d8c646a4db364df388adaec2a29870 Author: Tamar Christina Date: Fri Aug 5 14:53:28 2022 +0100 middle-end: Guard value_replacement and store_elim from seeing diamonds. This excludes value_replacement and store_elim from diamonds as they don't handle the form properly. gcc/ChangeLog: PR middle-end/106534 * tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Guard the value_replacement and store_elim from diamonds.
Re: [RFA configure parts] aarch64: Make cc1 handle --with options
Richard Earnshaw writes:
> On 13/06/2022 15:33, Richard Sandiford via Gcc-patches wrote:
>> On aarch64, --with-arch, --with-cpu and --with-tune only have an
>> effect on the driver, so “./xgcc -B./ -O3” can give significantly
>> different results from “./cc1 -O3”. --with-arch did have a limited
>> effect on ./cc1 in previous releases, although it didn't work
>> entirely correctly.
>>
>> Being of a lazy persuasion, I've got used to ./cc1 selecting SVE for
>> --with-arch=armv8.2-a+sve without having to supply an explicit -march,
>> so this patch makes ./cc1 emulate the relevant OPTION_DEFAULT_SPECS.
>> It relies on Wilco's earlier clean-ups.
>>
>> The patch makes config.gcc define WITH_FOO_STRING macros for each
>> supported --with-foo option. This could be done only in aarch64-
>> specific code, but I thought it could be useful on other targets
>> too (and can be safely ignored otherwise). There didn't seem to
>> be any existing and potentially clashing uses of macros with this
>> style of name.
>>
>> Tested on aarch64-linux-gnu & x86_64-linux-gnu. OK for the configure
>> bits?
>>
>> Richard
>>
>>
>> gcc/
>> * config.gcc: Define WITH_FOO_STRING macros for each supported
>> --with-foo option.
>> * config/aarch64/aarch64.cc (aarch64_override_options): Emulate
>> OPTION_DEFAULT_SPECS.
>> * config/aarch64/aarch64.h (OPTION_DEFAULT_SPECS): Reference the above.
>> ---
>> gcc/config.gcc| 14 ++
>> gcc/config/aarch64/aarch64.cc | 8
>> gcc/config/aarch64/aarch64.h | 5 -
>> 3 files changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index cdbefb5b4f5..e039230431c 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -5865,6 +5865,20 @@ else
>> configure_default_options="{ ${t} }"
>> fi
>>
>> +for option in $supported_defaults
>> +do
>> +lc_option=`echo $option | sed s/-/_/g`
>> +uc_option=`echo $lc_option | tr a-z A-Z`
>> +eval "val=\$with_$lc_option"
>> +if test -n "$val"
>> +then
>> +val="\\\"$val\\\""
>> +else
>> +val=nullptr
>> +fi
>> +tm_defines="$tm_defines WITH_${uc_option}_STRING=$val"
>> +done
>
> This bit would really be best reviewed by a non-arm maintainer. It
> generally looks OK. My only comment would be why define anything if the
> corresponding --with-foo was not specified. They you can use #ifdef to
> test if the user specified a default.
Yeah, could do it that way instead, but:
>> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
>> index d21e041eccb..0bc700b81ad 100644
>> --- a/gcc/config/aarch64/aarch64.cc
>> +++ b/gcc/config/aarch64/aarch64.cc
>> @@ -18109,6 +18109,14 @@ aarch64_override_options (void)
>> if (aarch64_branch_protection_string)
>> aarch64_validate_mbranch_protection (aarch64_branch_protection_string);
>>
>> + /* Emulate OPTION_DEFAULT_SPECS. */
>> + if (!aarch64_arch_string && !aarch64_cpu_string)
>> +aarch64_arch_string = WITH_ARCH_STRING;
>> + if (!aarch64_arch_string && !aarch64_cpu_string)
>> +aarch64_cpu_string = WITH_CPU_STRING;
>> + if (!aarch64_cpu_string && !aarch64_tune_string)
>> +aarch64_tune_string = WITH_TUNE_STRING;
(without the preprocessor stuff) IMO reads better. If a preprocessor
is/isn't present test turns out to be useful, perhaps we should add
macros like HAVE_WITH_TUNE/WITH_TUNE_PRESENT/... too? I guess it
should only be done when something needs it though.
Thanks,
Richard
>> +
>> /* -mcpu=CPU is shorthand for -march=ARCH_FOR_CPU, -mtune=CPU.
>>If either of -march or -mtune is given, they override their
>>respective component of -mcpu. */
>> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
>> index 80cfe4b7407..3122dbd7098 100644
>> --- a/gcc/config/aarch64/aarch64.h
>> +++ b/gcc/config/aarch64/aarch64.h
>> @@ -1267,7 +1267,10 @@ extern enum aarch64_code_model aarch64_cmodel;
>> /* Support for configure-time --with-arch, --with-cpu and --with-tune.
>> --with-arch and --with-cpu are ignored if either -mcpu or -march is
>> used.
>> --with-tune is ignored if either -mtune or -mcpu is used (but is not
>> - affected by -march). */
>> + affected by -march).
>> +
>> + There is corresponding code in aarch64_override_options that emulates
>> + this behavior when cc1 are invoked directly. */
>> #define OPTION_DEFAULT_SPECS \
>> {"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" }, \
>> {"cpu", "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
Re: [PATCH]middle-end Guard value_replacement and store_elim from seeing diamonds.
On Fri, 5 Aug 2022, Tamar Christina wrote:
> Hi All,
>
> This excludes value_replacement and store_elim from diamonds as they don't
> handle the form properly.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
OK
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR middle-end/106534
> * tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Guard the
> value_replacement and store_elim from diamonds.
>
> --- inline copy of patch --
> diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
> index
> bdbf52916b0f88ee4f475e1fa306046d61f13d53..1e002c608591836ffb001724b3f469a8d042ae5e
> 100644
> --- a/gcc/tree-ssa-phiopt.cc
> +++ b/gcc/tree-ssa-phiopt.cc
> @@ -283,7 +283,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
> do_hoist_loads, bool early_p)
> || (e1->flags & EDGE_FALLTHRU) == 0)
> continue;
>
> - if (do_store_elim)
> + if (do_store_elim && !diamond_p)
> {
> /* Also make sure that bb1 only have one predecessor and that it
>is bb. */
> @@ -310,7 +310,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
> do_hoist_loads, bool early_p)
>
> /* Value replacement can work with more than one PHI
>so try that first. */
> - if (!early_p)
> + if (!early_p && !diamond_p)
> for (gsi = gsi_start (phis); !gsi_end_p (gsi); gsi_next ())
> {
> phi = as_a (gsi_stmt (gsi));
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
[PATCH]middle-end Guard value_replacement and store_elim from seeing diamonds.
Hi All,
This excludes value_replacement and store_elim from diamonds as they don't
handle the form properly.
Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR middle-end/106534
* tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Guard the
value_replacement and store_elim from diamonds.
--- inline copy of patch --
diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index
bdbf52916b0f88ee4f475e1fa306046d61f13d53..1e002c608591836ffb001724b3f469a8d042ae5e
100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -283,7 +283,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
do_hoist_loads, bool early_p)
|| (e1->flags & EDGE_FALLTHRU) == 0)
continue;
- if (do_store_elim)
+ if (do_store_elim && !diamond_p)
{
/* Also make sure that bb1 only have one predecessor and that it
is bb. */
@@ -310,7 +310,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
do_hoist_loads, bool early_p)
/* Value replacement can work with more than one PHI
so try that first. */
- if (!early_p)
+ if (!early_p && !diamond_p)
for (gsi = gsi_start (phis); !gsi_end_p (gsi); gsi_next ())
{
phi = as_a (gsi_stmt (gsi));
--
diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index
bdbf52916b0f88ee4f475e1fa306046d61f13d53..1e002c608591836ffb001724b3f469a8d042ae5e
100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -283,7 +283,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
do_hoist_loads, bool early_p)
|| (e1->flags & EDGE_FALLTHRU) == 0)
continue;
- if (do_store_elim)
+ if (do_store_elim && !diamond_p)
{
/* Also make sure that bb1 only have one predecessor and that it
is bb. */
@@ -310,7 +310,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
do_hoist_loads, bool early_p)
/* Value replacement can work with more than one PHI
so try that first. */
- if (!early_p)
+ if (!early_p && !diamond_p)
for (gsi = gsi_start (phis); !gsi_end_p (gsi); gsi_next ())
{
phi = as_a (gsi_stmt (gsi));
[Bug tree-optimization/106322] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 --- Comment #15 from Mathieu Malaterre --- (In reply to Mathieu Malaterre from comment #11) > (In reply to Uroš Bizjak from comment #10) > > The reason the test fails with gcc-12 is that gcc-12 enabled > > auto-vectorisation for -O2. > > I can make the symptoms go away by doing: `-O2 -fno-tree-vectorize`. Since > this affects also arm5 and powerpc, it seems the bug is somewhere in the > shared 32bits code (bug does not affects 64bits arch for some reason). The above is incorrect, since the symptoms are also going away on mips64el and ppc64.
[x86_64 PATCH] Allow any immediate constant in *cmp_doubleword splitter.
This patch tweaks i386.md's *cmp_doubleword splitter's predicate to
allow general_operand, not just x86_64_hilo_general_operand, to improve
code generation. As a general rule, i386.md's _doubleword splitters should
be post-reload splitters that require integer immediate operands to be
x86_64_hilo_int_operand, so that each part is a valid word mode immediate
constant. As an exception to this rule, doubleword patterns that must be
split before reload, because they require additional scratch registers,
can take advantage of this ability to create new pseudos, to accept
any immediate constant, and call force_reg on the high and/or low parts
if they are not suitable immediate operands in word mode.
The benefit is shown in the new cmpti3.c test case below.
__int128 x;
int foo()
{
__int128 t = 0x1234567890abcdefLL;
return x == t;
}
where GCC with -O2 currently generates:
movabsq $1311768467294899695, %rax
xorl%edx, %edx
xorqx(%rip), %rax
xorqx+8(%rip), %rdx
orq %rdx, %rax
sete%al
movzbl %al, %eax
ret
but with this patch now generates:
movabsq $1311768467294899695, %rax
xorqx(%rip), %rax
orq x+8(%rip), %rax
sete%al
movzbl %al, %eax
ret
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures. The first two new test cases aren't affected
by this patch, but as I had them in my directory, it seemed reasonable to
increase the testsuite's coverage of TImode comparison code generation.
Ok for mainline?
2022-08-05 Roger Sayle
gcc/ChangeLog
* config/i386/i386.md (*cmp_doubleword): Change predicate
for x86_64_hilo_general_operand to general operand. Call
force_reg on parts that are not x86_64_immediate_operand.
gcc/testsuite/ChangeLog
* gcc.target/i386/cmpti1.c: New test case.
* gcc.target/i386/cmpti2.c: Likewise.
* gcc.target/i386/cmpti3.c: Likewise.
Thanks in advance,
Roger
--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 298e4b3..fd30c57 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1510,7 +1510,7 @@
(define_insn_and_split "*cmp_doubleword"
[(set (reg:CCZ FLAGS_REG)
(compare:CCZ (match_operand: 0 "nonimmediate_operand")
-(match_operand: 1 "x86_64_hilo_general_operand")))]
+(match_operand: 1 "general_operand")))]
"ix86_pre_reload_split ()"
"#"
"&& 1"
@@ -1544,7 +1544,12 @@
else if (operands[0] == constm1_rtx)
emit_insn (gen_one_cmpl2 (operands[4], operands[1]));
else
-emit_insn (gen_xor3 (operands[4], operands[0], operands[1]));
+{
+ if (CONST_SCALAR_INT_P (operands[1])
+ && !x86_64_immediate_operand (operands[1], mode))
+ operands[1] = force_reg (mode, operands[1]);
+ emit_insn (gen_xor3 (operands[4], operands[0], operands[1]));
+}
if (operands[3] == const0_rtx)
operands[5] = operands[2];
@@ -1558,7 +1563,12 @@
else if (operands[2] == constm1_rtx)
emit_insn (gen_one_cmpl2 (operands[5], operands[3]));
else
- emit_insn (gen_xor3 (operands[5], operands[2], operands[3]));
+ {
+ if (CONST_SCALAR_INT_P (operands[3])
+ && !x86_64_immediate_operand (operands[3], mode))
+ operands[3] = force_reg (mode, operands[3]);
+ emit_insn (gen_xor3 (operands[5], operands[2], operands[3]));
+ }
}
})
diff --git a/gcc/testsuite/gcc.target/i386/cmpti1.c
b/gcc/testsuite/gcc.target/i386/cmpti1.c
new file mode 100644
index 000..1c5f121
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/cmpti1.c
@@ -0,0 +1,8 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+int eq(__int128 x, __int128 y) { return x == y; }
+int ne(__int128 x, __int128 y) { return x != y; }
+/* { dg-final { scan-assembler-times "xorq" 4 } } */
+/* { dg-final { scan-assembler-times "setne" 1 } } */
+/* { dg-final { scan-assembler-times "sete" 1 } } */
+
diff --git a/gcc/testsuite/gcc.target/i386/cmpti2.c
b/gcc/testsuite/gcc.target/i386/cmpti2.c
new file mode 100644
index 000..ad95729
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/cmpti2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+
+__int128 x;
+__int128 y;
+
+int eq() { return x == y; }
+int ne() { return x != y; }
+
+/* { dg-final { scan-assembler-times "xorq" 4 } } */
+/* { dg-final { scan-assembler-times "setne" 1 } } */
+/* { dg-final { scan-assembler-times "sete" 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/cmpti3.c
b/gcc/testsuite/gcc.target/i386/cmpti3.c
new file mode 100644
index 000..302efd2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/cmpti3.c
@@ -0,0 +1,13 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+
+__int128 x;
+int foo()
+{
[PATCH 4/4][RFC] VLA Constructor
This isn't really a 'PATCH' yet, it's something I was working on but had
to put on hold. Feel free to re-use any bits or trash all of it if you'd
like.diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
index
82f9eba5c397af04924bdebdc684a1d77682d3fd..08625aad7b1a8dc9c9f8c491cb13d8af0b46a946
100644
--- a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
@@ -842,13 +842,45 @@ public:
for (unsigned int i = 0; i < nargs; ++i)
{
tree elt = gimple_call_arg (f.call, i);
- if (!CONSTANT_CLASS_P (elt))
- return NULL;
builder.quick_push (elt);
for (unsigned int j = 1; j < factor; ++j)
builder.quick_push (build_zero_cst (TREE_TYPE (vec_type)));
}
-return gimple_build_assign (f.lhs, builder.build ());
+builder.finalize ();
+unsigned int n_elts
+ = builder.nelts_per_pattern () == 1 ? builder.npatterns ()
+ : builder.full_nelts ().coeffs[0];
+
+if (n_elts == 1)
+ return gimple_build_assign (f.lhs, build1 (VEC_DUPLICATE_EXPR, vec_type,
+builder.elt (0)));
+tree list = NULL_TREE;
+tree *pp =
+for (unsigned int i = 0; i < n_elts; ++i)
+ {
+ *pp = build_tree_list (NULL, builder.elt (i) PASS_MEM_STAT);
+ pp = _CHAIN (*pp);
+ }
+
+poly_uint64 vec_len = TYPE_VECTOR_SUBPARTS (vec_type);
+vec_perm_builder sel (vec_len, n_elts, 1);
+for (unsigned int i = 0; i < n_elts; i++)
+ sel.quick_push (i);
+vec_perm_indices indices (sel, 1, n_elts);
+
+tree elt_type = TREE_TYPE (vec_type);
+
+tree ctor_type = build_vector_type (elt_type, n_elts);
+tree ctor = make_ssa_name_fn (cfun, ctor_type, 0);
+gimple *ctor_stmt
+ = gimple_build_assign (ctor,
+build_constructor_from_list (ctor_type, list));
+gsi_insert_before (f.gsi, ctor_stmt, GSI_SAME_STMT);
+
+tree mask_type = build_vector_type (ssizetype, vec_len);
+tree mask = vec_perm_indices_to_tree (mask_type, indices);
+return gimple_build_assign (f.lhs, fold_build3 (VEC_PERM_EXPR, vec_type,
+ ctor, ctor, mask));
}
rtx
diff --git a/gcc/config/aarch64/aarch64-sve.md
b/gcc/config/aarch64/aarch64-sve.md
index
bd60e65b0c3f05f1c931f03807170f3b9d699de5..dec935211e5a064239c858880a696e6ca3fe1ae2
100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -2544,6 +2544,17 @@
}
)
+;; Duplicate an Advanced SIMD vector to fill an SVE vector (LE version).
+(define_insn "*aarch64_vec_duplicate_reg_le"
+ [(set (match_operand:SVE_FULL 0 "register_operand" "=w,w")
+ (vec_duplicate:SVE_FULL
+ (match_operand: 1 "register_operand" "w,r")))]
+ "TARGET_SVE && !BYTES_BIG_ENDIAN"
+ "@
+ mov\t%0., %1
+ mov\t%0., %1"
+)
+
;; Duplicate an Advanced SIMD vector to fill an SVE vector (BE version).
;; The SVE register layout puts memory lane N into (architectural)
;; register lane N, whereas the Advanced SIMD layout puts the memory
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
a08043e18d609e258ebfe033875201163d129aba..9b118e4101d0a5995a833769433be49321ab2151
100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6033,7 +6033,6 @@ rtx
aarch64_expand_sve_dupq (rtx target, machine_mode mode, rtx src)
{
machine_mode src_mode = GET_MODE (src);
- gcc_assert (GET_MODE_INNER (mode) == GET_MODE_INNER (src_mode));
insn_code icode = (BYTES_BIG_ENDIAN
? code_for_aarch64_vec_duplicate_vq_be (mode)
: code_for_aarch64_vec_duplicate_vq_le (mode));
@@ -21806,20 +21805,29 @@ aarch64_simd_make_constant (rtx vals)
}
static void
-aarch64_vec_duplicate (rtx target, machine_mode mode, machine_mode
element_mode,
+aarch64_vec_duplicate (rtx target, rtx op, machine_mode mode, machine_mode
element_mode,
int narrow_n_elts)
{
poly_uint64 size = narrow_n_elts * GET_MODE_BITSIZE (element_mode);
- scalar_mode i_mode = int_mode_for_size (size, 0).require ();
machine_mode o_mode;
- if (aarch64_sve_mode_p (mode))
-o_mode = aarch64_full_sve_mode (i_mode).require ();
+ rtx input, output;
+ bool sve = aarch64_sve_mode_p (mode);
+ if (sve && known_eq (size, 128U))
+{
+ o_mode = mode;
+ output = target;
+ input = op;
+}
else
-o_mode
- = aarch64_simd_container_mode (i_mode,
-GET_MODE_BITSIZE (mode));
- rtx input = simplify_gen_subreg (i_mode, target, mode, 0);
- rtx output = simplify_gen_subreg (o_mode, target, mode, 0);
+{
+ scalar_mode i_mode = int_mode_for_size (size, 0).require ();
+ o_mode
+ = sve ? aarch64_full_sve_mode (i_mode).require ()
+ :
[PATCH 3/4] match.pd: Teach forwprop to handle VLA VEC_PERM_EXPRs with VLS CONSTRUCTORs as arguments
Hi,
This patch is part of the WIP patch that follows in this series. It's
goal is to teach forwprop to handle VLA VEC_PERM_EXPRs with VLS
CONSTRUCTORs as arguments as preparation for the 'VLA constructor' hook
approach.
Kind Regards,
Andrediff --git a/gcc/match.pd b/gcc/match.pd
index
9736393061aac61d4d53aaad6cf6b2c97a7d4679..3c3c0c6a88b35a6e42c506f6c4603680fe6e4318
100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7852,14 +7852,24 @@ and,
if (!tree_to_vec_perm_builder (, op2))
return NULL_TREE;
+/* FIXME: disable folding of a VEC_PERM_EXPR with a VLA mask and VLS
+ CONSTRUCTORS, since that would yield a VLA CONSTRUCTOR which we
+ currently do not support. */
+if (!TYPE_VECTOR_SUBPARTS (type).is_constant ()
+ && (TYPE_VECTOR_SUBPARTS (TREE_TYPE (op0)).is_constant ()
+ || TYPE_VECTOR_SUBPARTS (TREE_TYPE (op1)).is_constant ()))
+ return NULL_TREE;
+
/* Create a vec_perm_indices for the integer vector. */
poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
bool single_arg = (op0 == op1);
vec_perm_indices sel (builder, single_arg ? 1 : 2, nelts);
}
- (if (sel.series_p (0, 1, 0, 1))
+ (if (sel.series_p (0, 1, 0, 1)
+ && useless_type_conversion_p (type, TREE_TYPE (op0)))
{ op0; }
- (if (sel.series_p (0, 1, nelts, 1))
+ (if (sel.series_p (0, 1, nelts, 1)
+ && useless_type_conversion_p (type, TREE_TYPE (op1)))
{ op1; }
(with
{
diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index
fdc4bc8909d2763876550e53277ff2b3dcca796a..cda91c21c476ea8611e12c593bfa64e1d71dd29e
100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -2661,7 +2661,7 @@ simplify_permutation (gimple_stmt_iterator *gsi)
/* Shuffle of a constructor. */
bool ret = false;
- tree res_type = TREE_TYPE (arg0);
+ tree res_type = TREE_TYPE (gimple_get_lhs (stmt));
tree opt = fold_ternary (VEC_PERM_EXPR, res_type, arg0, arg1, op2);
if (!opt
|| (TREE_CODE (opt) != CONSTRUCTOR && TREE_CODE (opt) != VECTOR_CST))
[PATCH 2/4]aarch64: Change aarch64_expand_vector_init to use rtx_vector_builder
Hi,
This patch changes aarch64_expand_vector_init to use rtx_vector_builder,
exploiting it's internal pattern detection to find 'dup' patterns.
Bootstrapped and regression tested on aarch64-none-linux-gnu.
Is this OK for trunk or should we wait for the rest of the series?
gcc/ChangeLog:
2022-08-05 Andre Vieira
* config/aarch64/aarch64.cc (aarch64_vec_duplicate): New.
(aarch64_expand_vector_init): Make the existing variant construct
a rtx_vector_builder from the list of elements and use this to
detect
duplicate patterns.
gcc/testesuite/ChangeLog:
2022-08-05 Andre Vieira
* gcc.target/aarch64/ldp_stp_16.c: Modify to reflect code change.diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
4b486aeea90ea2afb9cdd96a4dbe15c5bb2abd7a..a08043e18d609e258ebfe033875201163d129aba
100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -305,6 +305,7 @@ static machine_mode aarch64_simd_container_mode
(scalar_mode, poly_int64);
static bool aarch64_print_address_internal (FILE*, machine_mode, rtx,
aarch64_addr_query_type);
static HOST_WIDE_INT aarch64_clamp_to_uimm12_shift (HOST_WIDE_INT val);
+static void aarch64_expand_vector_init (rtx, rtx_vector_builder&);
/* The processor for which instructions should be scheduled. */
enum aarch64_processor aarch64_tune = cortexa53;
@@ -21804,55 +21805,96 @@ aarch64_simd_make_constant (rtx vals)
return NULL_RTX;
}
+static void
+aarch64_vec_duplicate (rtx target, machine_mode mode, machine_mode
element_mode,
+ int narrow_n_elts)
+{
+ poly_uint64 size = narrow_n_elts * GET_MODE_BITSIZE (element_mode);
+ scalar_mode i_mode = int_mode_for_size (size, 0).require ();
+ machine_mode o_mode;
+ if (aarch64_sve_mode_p (mode))
+o_mode = aarch64_full_sve_mode (i_mode).require ();
+ else
+o_mode
+ = aarch64_simd_container_mode (i_mode,
+GET_MODE_BITSIZE (mode));
+ rtx input = simplify_gen_subreg (i_mode, target, mode, 0);
+ rtx output = simplify_gen_subreg (o_mode, target, mode, 0);
+ aarch64_emit_move (output, gen_vec_duplicate (o_mode, input));
+}
+
+
/* Expand a vector initialisation sequence, such that TARGET is
initialised to contain VALS. */
void
aarch64_expand_vector_init (rtx target, rtx vals)
{
- machine_mode mode = GET_MODE (target);
- scalar_mode inner_mode = GET_MODE_INNER (mode);
/* The number of vector elements. */
int n_elts = XVECLEN (vals, 0);
- /* The number of vector elements which are not constant. */
- int n_var = 0;
- rtx any_const = NULL_RTX;
+ machine_mode mode = GET_MODE (target);
+ scalar_mode inner_mode = GET_MODE_INNER (mode);
/* The first element of vals. */
rtx v0 = XVECEXP (vals, 0, 0);
- bool all_same = true;
/* This is a special vec_init where N is not an element mode but a
vector mode with half the elements of M. We expect to find two entries
of mode N in VALS and we must put their concatentation into TARGET. */
- if (XVECLEN (vals, 0) == 2 && VECTOR_MODE_P (GET_MODE (XVECEXP (vals, 0,
0
+ if (n_elts == 2
+ && VECTOR_MODE_P (GET_MODE (v0)))
{
- machine_mode narrow_mode = GET_MODE (XVECEXP (vals, 0, 0));
+ machine_mode narrow_mode = GET_MODE (v0);
gcc_assert (GET_MODE_INNER (narrow_mode) == inner_mode
&& known_eq (GET_MODE_SIZE (mode),
2 * GET_MODE_SIZE (narrow_mode)));
- emit_insn (gen_aarch64_vec_concat (narrow_mode, target,
-XVECEXP (vals, 0, 0),
+ emit_insn (gen_aarch64_vec_concat (narrow_mode, target, v0,
XVECEXP (vals, 0, 1)));
return;
}
- /* Count the number of variable elements to initialise. */
+ rtx_vector_builder builder (mode, n_elts, 1);
for (int i = 0; i < n_elts; ++i)
+builder.quick_push (XVECEXP (vals, 0, i));
+ builder.finalize ();
+
+ aarch64_expand_vector_init (target, builder);
+}
+
+static void
+aarch64_expand_vector_init (rtx target, rtx_vector_builder )
+{
+ machine_mode mode = GET_MODE (target);
+ scalar_mode inner_mode = GET_MODE_INNER (mode);
+ /* The number of vector elements which are not constant. */
+ unsigned n_var = 0;
+ rtx any_const = NULL_RTX;
+ /* The first element of vals. */
+ rtx v0 = v.elt (0);
+ /* Get the number of elements to insert into an Advanced SIMD vector.
+ If we have more than one element per pattern then we use the constant
+ number of elements in a full vector.
+ If we only have one element per pattern we use the number of patterns as
+ this may be lower than the number of elements in a full vector, which
+ means they repeat and we should use a duplicate of the smaller vector. */
+ unsigned n_elts
+= v.nelts_per_pattern () == 1 ? v.npatterns ()
+ :
[PATCH 1/4] aarch64: encourage use of GPR input for SIMD inserts
Hi, This enables and makes it more likely the compiler is able to use GPR input for SIMD inserts. I believe this is some outdated hack we used to prevent costly GPR<->SIMD register file swaps. This patch is required for better codegen in situations like the test case 'int8_3' in the next patch in this series. Bootstrapped and regression tested together with the next patch on aarch64-none-linux-gnu. gcc/ChangeLog: 2022-08-05 Andre Vieira * config/aarch64/aarch64-simd.md (aarch64_simd_vec_set): Remove '?' modifier.diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index 587a45d77721e1b39accbad7dbeca4d741eccb10..51eab5a872ade7b70268676346e8be7c9c6c8e3a 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -1038,7 +1038,7 @@ [(set (match_operand:VALL_F16 0 "register_operand" "=w,w,w") (vec_merge:VALL_F16 (vec_duplicate:VALL_F16 - (match_operand: 1 "aarch64_simd_nonimmediate_operand" "w,?r,Utv")) + (match_operand: 1 "aarch64_simd_nonimmediate_operand" "w,r,Utv")) (match_operand:VALL_F16 3 "register_operand" "0,0,0") (match_operand:SI 2 "immediate_operand" "i,i,i")))] "TARGET_SIMD"
[PATCH 0/4] aarch64: Improve codegen for dups and constructors
Hi, This patch series is a work in progress towards getting the compiler to generate better code for constructors and dups in both NEON and SVE targets. It first changes the backend to use rtx_vector_builder for vector_init's. Then it is followed by some prepraration passes to better handle VLA VEC_PERM_EXPRs followed by the addition of a new TARGET_HOOK VLA_CONSTRUCTOR that is used to expand VLA VEC_PERM_EXPRs, all based on Prathamesh's initial work in this area. As I said before, this is still work in progress, though I suspect the first two patches could go in but I was trying to get the series ready to post to make sure the first patches were in the right shape. I have put this work on hold right now, but I heard Prathamesh might want to pick this up, feel free to use any of this, or discard as you see fit. Andre Vieira (4) aarch64: Encourage use of GPR input for SIMD inserts aarch64: Change aarch64_expand_vector_init to use rtx_vector_builder match.pd: Teach forwprop to handle VLA VEC_PERM_EXPRs with VLS CONSTRUCTORs as arguments [RFC]: VLA Constructors Kind regards, Andre
Re: [PATCH] middle-end: Allow backend to expand/split double word compare to 0/-1.
"Roger Sayle" writes:
> This patch to the middle-end's RTL expansion reorders the code in
> emit_store_flag_1 so that the backend has more control over how best
> to expand/split double word equality/inequality comparisons against
> zero or minus one. With the current implementation, the middle-end
> always decides to lower this idiom during RTL expansion using SUBREGs
> and word mode instructions, without ever consulting the backend's
> machine description. Hence on x86_64, a TImode comparison against zero
> is always expanded as:
>
> (parallel [
> (set (reg:DI 91)
>(ior:DI (subreg:DI (reg:TI 88) 0)
>(subreg:DI (reg:TI 88) 8)))
> (clobber (reg:CC 17 flags))])
>
> (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:DI 91)
> (const_int 0 [0])))
>
> This patch, which makes no changes to the code itself, simply reorders
> the clauses in emit_store_flag_1 so that the middle-end first attempts
> expansion using the target's doubleword mode cstore optab/expander,
> and only if this fails, falls back to lowering to word mode operations.
> On x86_64, this allows the expander to produce:
>
> (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:TI 88)
> (const_int 0 [0])))
>
> which is a candidate for scalar-to-vector transformations (and
> combine simplifications etc.). On targets that don't define a cstore
> pattern for doubleword integer modes, there should be no change in
> behaviour. For those that do, the current behaviour can be restored
> (if desired) by restricting the expander/insn to not apply when the
> comparison is EQ or NE, and operand[2] is either const0_rtx or
> constm1_rtx.
>
> This change just keeps RTL expansion more consistent (in philosophy).
> For other doubleword comparisons, such as with operators LT and GT,
> or with constants other than zero or -1, the wishes of the backend
> are respected, and only if the optab expansion fails are the default
> fall-back implementations using narrower integer mode operations
> (and conditional jumps) used.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures. I'm happy to help tweak any backends that notice
> a change in their generated code. Ok for mainline?
>
> 2022-08-03 Roger Sayle
>
> gcc/ChangeLog
> * expmed.cc (emit_store_flag_1): Move code to expand double word
> equality and inequality against zero or -1, using word operations,
> to after trying to use the backend's cstore4 optab/expander.
LGTM. I guess this raises the question of whether the shift conversion
should still come first. But I think the reason for treating the two
cases differently is that the one that you're moving is still a cstore
operation, just in a different mode. It makes sense to give the target
a go in the original mode before trying a smaller one.
Thanks,
Richard
> Thanks in advance,
> Roger
> --
>
> diff --git a/gcc/expmed.cc b/gcc/expmed.cc
> index 9b01b5a..8d7418b 100644
> --- a/gcc/expmed.cc
> +++ b/gcc/expmed.cc
> @@ -5662,63 +5662,9 @@ emit_store_flag_1 (rtx target, enum rtx_code code, rtx
> op0, rtx op1,
>break;
> }
>
> - /* If we are comparing a double-word integer with zero or -1, we can
> - convert the comparison into one involving a single word. */
> - scalar_int_mode int_mode;
> - if (is_int_mode (mode, _mode)
> - && GET_MODE_BITSIZE (int_mode) == BITS_PER_WORD * 2
> - && (!MEM_P (op0) || ! MEM_VOLATILE_P (op0)))
> -{
> - rtx tem;
> - if ((code == EQ || code == NE)
> - && (op1 == const0_rtx || op1 == constm1_rtx))
> - {
> - rtx op00, op01;
> -
> - /* Do a logical OR or AND of the two words and compare the
> - result. */
> - op00 = simplify_gen_subreg (word_mode, op0, int_mode, 0);
> - op01 = simplify_gen_subreg (word_mode, op0, int_mode, UNITS_PER_WORD);
> - tem = expand_binop (word_mode,
> - op1 == const0_rtx ? ior_optab : and_optab,
> - op00, op01, NULL_RTX, unsignedp,
> - OPTAB_DIRECT);
> -
> - if (tem != 0)
> - tem = emit_store_flag (NULL_RTX, code, tem, op1, word_mode,
> -unsignedp, normalizep);
> - }
> - else if ((code == LT || code == GE) && op1 == const0_rtx)
> - {
> - rtx op0h;
> -
> - /* If testing the sign bit, can just test on high word. */
> - op0h = simplify_gen_subreg (word_mode, op0, int_mode,
> - subreg_highpart_offset (word_mode,
> - int_mode));
> - tem = emit_store_flag (NULL_RTX, code, op0h, op1, word_mode,
> - unsignedp, normalizep);
> - }
> - else
> - tem = NULL_RTX;
> -
> - if (tem)
> - {
> - if (target_mode == VOIDmode || GET_MODE
[Bug c/106537] New: GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
Bug ID: 106537
Summary: GCC doesn't support
-W[no-]compare-distinct-pointer-types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
GCC emits pedwarns unconditionally when comparing pointers of different types,
for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
return 0;
return 1;
}
/home/jemarch/foo.c: In function ‘xdp_context’:
/home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types
lacks a cast
15 | if (metadata + 1 > data)
|^
LLVM supports an option -W[no-]compare-distinct-pointer-types that can be used
in order to enable or disable the emission of such warnings. It is enabled by
default.
This option is used in the kernel source tree for some BPF programs.
I already got a patch for this.
[PATCH] backthreader dump fix
This fixes odd SUCCEEDED dumps from the backthreader registry that
can happen even though register_jump_thread cancelled the thread
as invalid.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-threadbackward.cc (back_threader::maybe_register_path):
Check whether the registry register_path rejected the path.
(back_threader_registry::register_path): Return whether
register_jump_thread succeeded.
---
gcc/tree-ssa-threadbackward.cc | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 3acd66a7780..332a1d2a1dd 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -243,10 +243,9 @@ back_threader::maybe_register_path ()
bool irreducible = false;
if (m_profit.profitable_path_p (m_path, m_name, taken_edge,
)
- && debug_counter ())
+ && debug_counter ()
+ && m_registry.register_path (m_path, taken_edge))
{
- m_registry.register_path (m_path, taken_edge);
-
if (irreducible)
vect_free_loop_info_assumptions (m_path[0]->loop_father);
}
@@ -858,8 +857,7 @@ back_threader_registry::register_path (const
vec _path,
}
push_edge (jump_thread_path, taken_edge, EDGE_NO_COPY_SRC_BLOCK);
- register_jump_thread (jump_thread_path);
- return true;
+ return register_jump_thread (jump_thread_path);
}
// Thread all suitable paths in the current function.
--
2.35.3
Re: Missed lowering to ld1rq from svld1rq for memory operand
Prathamesh Kulkarni writes: > Hi Richard, > Following from off-list discussion, in the attached patch, I wrote pattern > similar to vec_duplicate_reg, which seems to work for the svld1rq tests. > Does it look OK ? > > Sorry, I didn't fully understand your suggestion on integrating with > vec_duplicate_reg > pattern. For vec_duplicate_reg, the operand to vec_duplicate expects > mode to be , while the pattern in patch expects operand of > vec_duplicate to have mode . > How do we write a pattern so an operand can accept either of the 2 modes ? I quoted the wrong one, sorry, should have been aarch64_vec_duplicate_vq_le. > Also it seems cannot be used with SVE_ALL ? Yeah, these would be SVE_FULL only. Richard
[COMMITTED] Inline unsupported_range constructor.
An unsupported_range temporary is instantiated in every Value_Range
for completeness sake and should be mostly a NOP. However, it's
showing up in the callgrind stats, because it's not inline. This
fixes the oversight.
PR tree-optimization/106514
gcc/ChangeLog:
* value-range.cc (unsupported_range::unsupported_range): Move...
* value-range.h (unsupported_range::unsupported_range): ...here.
(unsupported_range::set_undefined): New.
---
gcc/value-range.cc | 6 --
gcc/value-range.h | 10 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index dd5a4303908..a2273f540e8 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -248,12 +248,6 @@ irange::set_nonnegative (tree type)
set (build_int_cst (type, 0), TYPE_MAX_VALUE (type));
}
-unsupported_range::unsupported_range ()
-{
- m_discriminator = VR_UNKNOWN;
- set_undefined ();
-}
-
void
frange::accept (const vrange_visitor ) const
{
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 305e2cae7e6..856947d23dd 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -250,7 +250,15 @@ private:
class unsupported_range : public vrange
{
public:
- unsupported_range ();
+ unsupported_range ()
+ {
+m_discriminator = VR_UNKNOWN;
+set_undefined ();
+ }
+ virtual void set_undefined () final override
+ {
+m_kind = VR_UNDEFINED;
+ }
virtual void accept (const vrange_visitor ) const override;
};
--
2.37.1
[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514 --- Comment #4 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:47964e766270f349f5b171bcd68ff7c1e60d85d8 commit r13-1973-g47964e766270f349f5b171bcd68ff7c1e60d85d8 Author: Aldy Hernandez Date: Fri Aug 5 08:04:10 2022 +0200 Inline unsupported_range constructor. An unsupported_range temporary is instantiated in every Value_Range for completeness sake and should be mostly a NOP. However, it's showing up in the callgrind stats, because it's not inline. This fixes the oversight. PR tree-optimization/106514 gcc/ChangeLog: * value-range.cc (unsupported_range::unsupported_range): Move... * value-range.h (unsupported_range::unsupported_range): ...here. (unsupported_range::set_undefined): New.
[PATCH V2] place `const volatile' objects in read-only sections
[Changes from V1:
- Added a test.]
It is common for C BPF programs to use variables that are implicitly
set by the BPF loader and run-time. It is also necessary for these
variables to be stored in read-only storage so the BPF verifier
recognizes them as such. This leads to declarations using both
`const' and `volatile' qualifiers, like this:
const volatile unsigned char is_allow_list = 0;
Where `volatile' is used to avoid the compiler to optimize out the
variable, or turn it into a constant, and `const' to make sure it is
placed in .rodata.
Now, it happens that:
- GCC places `const volatile' objects in the .data section, under the
assumption that `volatile' somehow voids the `const'.
- LLVM places `const volatile' objects in .rodata, under the
assumption that `volatile' is orthogonal to `const'.
So there is a divergence, that has practical consequences: it makes
BPF programs compiled with GCC to not work properly.
When looking into this, I found this bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
"change semantics of const volatile variables"
which was filed back in 2005, long ago. This report was already
asking to put `const volatile' objects in .rodata, questioning the
current behavior.
While discussing this in the #gcc IRC channel I was pointed out to the
following excerpt from the C18 spec:
6.7.3 Type qualifiers / 5 The properties associated with qualified
types are meaningful only for expressions that are
lval-values [note 135]
135) The implementation may place a const object that is not
volatile in a read-only region of storage. Moreover, the
implementation need not allocate storage for such an object if
its $ address is never used.
This footnote may be interpreted as if const objects that are volatile
shouldn't be put in read-only storage. Even if I personally was not
very convinced of that interpretation (see my earlier comment in BZ
25521) I filed the following issue in the LLVM tracker in order to
discuss the matter:
https://github.com/llvm/llvm-project/issues/56468
As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14
reflectors about this. He reported that the reflectors don't think
footnote 135 has any normative value.
So, not having a normative mandate on either direction, there are two
options:
a) To change GCC to place `const volatile' objects in .rodata instead
of .data.
b) To change LLVM to place `const volatile' objects in .data instead
of .rodata.
Considering that:
- One target (bpf-unknown-none) breaks with the current GCC behavior.
- No target/platform relies on the GCC behavior, that we know.
- Changing the LLVM behavior at this point would be very severely
traumatic for the BPF people and their users.
I think the right thing to do at this point is a).
Therefore this patch.
Regtested in x86_64-linux-gnu and bpf-unknown-none.
No regressions observed.
gcc/ChangeLog:
PR middle-end/25521
* varasm.cc (categorize_decl_for_section): Place `const volatile'
objects in read-only sections.
(default_select_section): Likewise.
gcc/testsuite/ChangeLog:
PR middle-end/25521
* lib/target-supports.exp (check_effective_target_elf): Define.
* gcc.dg/pr25521.c: New test.
---
gcc/testsuite/gcc.dg/pr25521.c| 10 ++
gcc/testsuite/lib/target-supports.exp | 10 ++
gcc/varasm.cc | 3 ---
3 files changed, 20 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr25521.c
diff --git a/gcc/testsuite/gcc.dg/pr25521.c b/gcc/testsuite/gcc.dg/pr25521.c
new file mode 100644
index 000..74fe2ae6626
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr25521.c
@@ -0,0 +1,10 @@
+/* PR middle-end/25521 - place `const volatile' objects in read-only
+ sections.
+
+ { dg-require-effective-target elf }
+ { dg-do compile } */
+
+const volatile int foo = 30;
+
+
+/* { dg-final { scan-assembler "\\.rodata" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 04a2a8e8659..c663d59264b 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -483,6 +483,16 @@ proc check_effective_target_alias { } {
}
}
+# Returns 1 if the target uses the ELF object format, 0 otherwise.
+
+proc check_effective_target_elf { } {
+if { [gcc_target_object_format] == "elf" } {
+ return 1;
+} else {
+ return 0;
+}
+}
+
# Returns 1 if the target toolchain supports ifunc, 0 otherwise.
proc check_ifunc_available { } {
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 4db8506b106..7864db11faf 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -6971,7 +6971,6 @@ default_select_section (tree decl, int reloc,
{
if (! ((flag_pic && reloc)
|| !TREE_READONLY (decl)
-|| TREE_SIDE_EFFECTS (decl)
|| !TREE_CONSTANT (decl)))
return
Missed lowering to ld1rq from svld1rq for memory operand
Hi Richard,
Following from off-list discussion, in the attached patch, I wrote pattern
similar to vec_duplicate_reg, which seems to work for the svld1rq tests.
Does it look OK ?
Sorry, I didn't fully understand your suggestion on integrating with
vec_duplicate_reg
pattern. For vec_duplicate_reg, the operand to vec_duplicate expects
mode to be , while the pattern in patch expects operand of
vec_duplicate to have mode .
How do we write a pattern so an operand can accept either of the 2 modes ?
Also it seems cannot be used with SVE_ALL ?
Thanks,
Prathamesh
diff --git a/gcc/config/aarch64/aarch64-sve.md
b/gcc/config/aarch64/aarch64-sve.md
index bd60e65b0c3..b0dc33870b8 100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -2504,6 +2504,27 @@
}
)
+;; Fold ldr+dup -> ld1rq
+
+(define_insn_and_split "*vec_duplicate_ld1rq"
+ [(set (match_operand:SVE_FULL 0 "register_operand" "=w")
+ (vec_duplicate:SVE_FULL
+ (match_operand: 1 "aarch64_sve_ld1rq_operand" "UtQ")))
+ (clobber (match_scratch:VNx16BI 2 "=Upl"))]
+ "TARGET_SVE"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+ {
+if (GET_CODE (operands[2]) == SCRATCH)
+ operands[2] = gen_reg_rtx (VNx16BImode);
+emit_move_insn (operands[2], CONSTM1_RTX (VNx16BImode));
+rtx gp = gen_lowpart (mode, operands[2]);
+emit_insn (gen_aarch64_sve_ld1rq (operands[0], operands[1], gp));
+DONE;
+ }
+)
+
;; Accept memory operands for the benefit of combine, and also in case
;; the scalar input gets spilled to memory during RA. We want to split
;; the load at the first opportunity in order to allow the PTRUE to be
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96463-2.c
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96463-2.c
index 196de3f5e0a..0dfe125507f 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96463-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96463-2.c
@@ -26,4 +26,8 @@ TEST(svfloat64_t, float64_t, f64)
TEST(svbfloat16_t, bfloat16_t, bf16)
-/* { dg-final { scan-assembler-times {\tdup\tz[0-9]+\.q, z[0-9]+\.q\[0\]} 12 {
target aarch64_little_endian } } } */
+/* { dg-final { scan-assembler-not "dup" { target aarch64_little_endian } } }
*/
+/* { dg-final { scan-assembler-times {\tld1rqb\tz0\.b, p0/z, \[x0\]} 2 {
target aarch64_little_endian } } } */
+/* { dg-final { scan-assembler-times {\tld1rqh\tz0\.h, p0/z, \[x0\]} 4 {
target aarch64_little_endian } } } */
+/* { dg-final { scan-assembler-times {\tld1rqw\tz0\.s, p0/z, \[x0\]} 3 {
target aarch64_little_endian } } } */
+/* { dg-final { scan-assembler-times {\tld1rqd\tz0\.d, p0/z, \[x0\]} 3 {
target aarch64_little_endian } } } */
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #9 from Tamar Christina --- (In reply to Tamar Christina from comment #6) > (In reply to rguent...@suse.de from comment #5) > > On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > > > > > --- Comment #4 from Tobias Burnus --- > > > Seems as if the ICE is fixed for that file by reverting the following > > > commit: > > > > > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > > > middle-end: Fix phi-ssa assertion triggers. [PR106519] > > > > As hinted in the e-mail exchange the earlier two transforms might need > > guarding with !diamond_p since IIRC only minmax is capable of dealing > > with it? > > Yes, Though I didn't find any failing cases so I didn't guard store elim. > value_replacement is a weird one as it looks like it's already looking for > some kind of diamond form. I can guard both to be safe, but that's > essentially doing a blind change if I can't reproduce this locally. This does seem to fix it, so bootstrapping now and will put up a patch once done.
☺ Buildbot (GNU Toolchain): gccrust - build successful (master)
A passing build has been detected on builder gccrust-opensusetw-x86_64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/103/builds/149 Build state: build successful Revision: 6f88307147ac7b63c315aab2e81811e985a867a7 Worker: bb1 Build Reason: (unknown) Blamelist: Philip Herron Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/4/logs/stdio - warnings (27): https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/4/logs/warnings__27_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/11/logs/stdio - 12: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/12/logs/stdio - 13: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/13/logs/stdio - 14: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/14/logs/stdio - 15: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/15/logs/stdio - 16: make clean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/103/builds/149/steps/16/logs/stdio -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Last reconfirmed||2022-08-05 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #8 from Tamar Christina --- (In reply to Tobias Burnus from comment #7) > (In reply to Tamar Christina from comment #3) > > Thanks for the repro, could you tell me what target I need to use or what > > configure options to build amdgcn-amdhsa? > > See > https://gcc.gnu.org/wiki/Offloading#How_to_build_an_offloading-enabled_GCC > for some guidance. (But that's more for building a full compiler and more > than you need.) > > I think you just need to know: --target=amdgcn-amdhsa Thanks! Able to reproduce it now!
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #7 from Tobias Burnus --- (In reply to Tamar Christina from comment #3) > Thanks for the repro, could you tell me what target I need to use or what > configure options to build amdgcn-amdhsa? See https://gcc.gnu.org/wiki/Offloading#How_to_build_an_offloading-enabled_GCC for some guidance. (But that's more for building a full compiler and more than you need.) I think you just need to know: --target=amdgcn-amdhsa
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #6 from Tamar Christina --- (In reply to rguent...@suse.de from comment #5) > On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > > > --- Comment #4 from Tobias Burnus --- > > Seems as if the ICE is fixed for that file by reverting the following > > commit: > > > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > > middle-end: Fix phi-ssa assertion triggers. [PR106519] > > As hinted in the e-mail exchange the earlier two transforms might need > guarding with !diamond_p since IIRC only minmax is capable of dealing > with it? Yes, Though I didn't find any failing cases so I didn't guard store elim. value_replacement is a weird one as it looks like it's already looking for some kind of diamond form. I can guard both to be safe, but that's essentially doing a blind change if I can't reproduce this locally.
☺ Buildbot (GNU Toolchain): gccrust - build successful (master)
A passing build has been detected on builder gccrust-opensuseleap-x86_64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/104/builds/147 Build state: build successful Revision: 94e53f8e55e93da8db3d948c3f16d23b7c4ba7a6 Worker: bb1 Build Reason: (unknown) Blamelist: Philip Herron Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/4/logs/stdio - warnings (74): https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/4/logs/warnings__74_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/11/logs/stdio - 12: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/12/logs/stdio - 13: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/13/logs/stdio - 14: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/14/logs/stdio - 15: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/15/logs/stdio - 16: make clean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/104/builds/147/steps/16/logs/stdio -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] lto: support --jobserver-style=fifo for recent GNU make
On Thu, Aug 4, 2022 at 10:57 AM Martin Liška wrote:
>
> After a long time, GNU make has finally implemented named pipes when
> it comes to --jobserver-auth. The traditional approach are
> provided opened file descriptors that causes troubles:
> https://savannah.gnu.org/bugs/index.php?57242
>
> GNU make commit:
> https://git.savannah.gnu.org/cgit/make.git/commit/?id=7ad2593b2d2bb5b9332fd8bf93ac6f958bc6
>
> I tested that locally with TOT GNU make and it works:
>
> $ cat Makefile
> all:
> g++ tramp3d-v4.ii -c -flto -O2
> g++ tramp3d-v4.o -flto=jobserver
>
> $ MAKE=/tmp/bin/bin/make /tmp/bin/bin/make -j16 --jobserver-style=fifo
> g++ tramp3d-v4.ii -c -flto -O2
> g++ tramp3d-v4.o -flto=jobserver
> (ltrans run in parallel)
>
> Ready to be installed after tests?
LGTM.
Thanks,
Richard.
> Martin
>
> gcc/ChangeLog:
>
> * gcc.cc (driver::detect_jobserver): Support --jobserver-style=fifo.
> * lto-wrapper.cc (jobserver_active_p): Likewise.
> ---
> gcc/gcc.cc | 15 ---
> gcc/lto-wrapper.cc | 20 +++-
> 2 files changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index 5cbb38560b2..c98407fe03d 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -9182,15 +9182,24 @@ driver::detect_jobserver () const
> const char *makeflags = env.get ("MAKEFLAGS");
> if (makeflags != NULL)
> {
> - const char *needle = "--jobserver-auth=";
> - const char *n = strstr (makeflags, needle);
> + /* Traditionally, GNU make uses opened pieps for jobserver-auth,
> +e.g. --jobserver-auth=3,4. */
> + const char *pipe_needle = "--jobserver-auth=";
> +
> + /* Starting with GNU make 4.4, one can use --jobserver-style=fifo
> +and then named pipe is used: --jobserver-auth=fifo:/tmp/hcsparta. */
> + const char *fifo_needle = "--jobserver-auth=fifo:";
> + if (strstr (makeflags, fifo_needle) != NULL)
> + return;
> +
> + const char *n = strstr (makeflags, pipe_needle);
> if (n != NULL)
> {
> int rfd = -1;
> int wfd = -1;
>
> bool jobserver
> - = (sscanf (n + strlen (needle), "%d,%d", , ) == 2
> + = (sscanf (n + strlen (pipe_needle), "%d,%d", , ) == 2
>&& rfd > 0
>&& wfd > 0
>&& is_valid_fd (rfd)
> diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
> index 795ab74555c..756350d5ace 100644
> --- a/gcc/lto-wrapper.cc
> +++ b/gcc/lto-wrapper.cc
> @@ -1342,27 +1342,37 @@ static const char *
> jobserver_active_p (void)
> {
> #define JS_PREFIX "jobserver is not available: "
> - #define JS_NEEDLE "--jobserver-auth="
> +
> + /* Traditionally, GNU make uses opened pieps for jobserver-auth,
> + e.g. --jobserver-auth=3,4. */
> + #define JS_PIPE_NEEDLE "--jobserver-auth="
> +
> + /* Starting with GNU make 4.4, one can use --jobserver-style=fifo
> + and then named pipe is used: --jobserver-auth=fifo:/tmp/hcsparta. */
> + #define JS_FIFO_NEEDLE "--jobserver-auth=fifo:"
>
> const char *makeflags = getenv ("MAKEFLAGS");
> if (makeflags == NULL)
> return JS_PREFIX "% environment variable is unset";
>
> - const char *n = strstr (makeflags, JS_NEEDLE);
> + if (strstr (makeflags, JS_FIFO_NEEDLE) != NULL)
> +return NULL;
> +
> + const char *n = strstr (makeflags, JS_PIPE_NEEDLE);
> if (n == NULL)
> -return JS_PREFIX "%<" JS_NEEDLE "%> is not present in %";
> +return JS_PREFIX "%<" JS_PIPE_NEEDLE "%> is not present in
> %";
>
> int rfd = -1;
> int wfd = -1;
>
> - if (sscanf (n + strlen (JS_NEEDLE), "%d,%d", , ) == 2
> + if (sscanf (n + strlen (JS_PIPE_NEEDLE), "%d,%d", , ) == 2
> && rfd > 0
> && wfd > 0
> && is_valid_fd (rfd)
> && is_valid_fd (wfd))
> return NULL;
> else
> -return JS_PREFIX "cannot access %<" JS_NEEDLE "%> file descriptors";
> +return JS_PREFIX "cannot access %<" JS_PIPE_NEEDLE "%> file descriptors";
> }
>
> /* Print link to -flto documentation with a hint message. */
> --
> 2.37.1
>
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #5 from rguenther at suse dot de --- On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > --- Comment #4 from Tobias Burnus --- > Seems as if the ICE is fixed for that file by reverting the following commit: > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > middle-end: Fix phi-ssa assertion triggers. [PR106519] As hinted in the e-mail exchange the earlier two transforms might need guarding with !diamond_p since IIRC only minmax is capable of dealing with it?
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #4 from Tobias Burnus --- Seems as if the ICE is fixed for that file by reverting the following commit: commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc middle-end: Fix phi-ssa assertion triggers. [PR106519]
☺ Buildbot (GNU Toolchain): gccrust - build successful (master)
A restored build has been detected on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/3/builds/282 Build state: build successful Revision: ffb419d6a46302126944066ef46bd0c9f590ee30 Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/4/logs/stdio - warnings (32): https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/4/logs/warnings__32_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/11/logs/stdio - 12: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/12/logs/stdio - 13: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/13/logs/stdio - 14: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/14/logs/stdio - 15: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/15/logs/stdio - 16: make clean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/282/steps/16/logs/stdio A restored build has been detected on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/27/builds/281 Build state: build successful Revision: ffb419d6a46302126944066ef46bd0c9f590ee30 Worker: debian-i386 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/4/logs/stdio - warnings (50): https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/4/logs/warnings__50_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/281/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio:
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #3 from Tamar Christina --- Thanks for the repro, could you tell me what target I need to use or what configure options to build amdgcn-amdhsa?
☠ Buildbot (GNU Toolchain): gccrust - failed 'grep unexpected ...' (failure) (master)
A new failure has been detected on builder gccrust-debian-ppc64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/3/builds/281 Build state: failed 'grep unexpected ...' (failure) Revision: 7022b9dd107e534896d8383f6bc4ce70b4726cc9 Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/4/logs/stdio - warnings (32): https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/4/logs/warnings__32_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/11/logs/stdio - 12: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/12/logs/stdio - 13: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/13/logs/stdio - 14: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/14/logs/stdio - 15: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/15/logs/stdio - 16: make clean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/3/builds/281/steps/16/logs/stdio A new failure has been detected on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/27/builds/280 Build state: failed 'grep unexpected ...' (failure) Revision: 7022b9dd107e534896d8383f6bc4ce70b4726cc9 Worker: debian-i386 Build Reason: (unknown) Blamelist: Philip Herron , bors[bot] <26634292+bors[bot]@users.noreply.github.com> Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/4/logs/stdio - warnings (50): https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/4/logs/warnings__50_ - 5: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/5/logs/rust_log - 6: grep unexpected rust.sum ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/27/builds/280/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio:
[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #4 from Ivan Sorokin ---
Perhaps the warning message could be improved? The warning is saying about
arrays but there are no arrays in the original code.
I think it would be great if the warning said something about
{invalid/wild/cast from int} pointer. English is not my strong suit, perhaps
something like this:
warning: dereferencing wild pointer '(int*)1ul' is undefined
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #2 from Tobias Burnus --- Created attachment 53416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53416=edit Reduced testcase - fails with cc1 -O2 inp.i Reduced inputfile attached. Full code has the full ICE output: src/gcc-mainline/libgfortran/io/unit.c: In function 'get_gfc_unit': gcc-mainline/libgfortran/io/unit.c:326:1: error: definition in block 18 does not dominate use in block 19 326 | get_gfc_unit (int n, int do_create) | ^~~~ for SSA_NAME: p_47 in statement: p_30 = PHI PHI argument p_47 for PHI node p_30 = PHI during GIMPLE pass: phiopt gcc-mainline/libgfortran/io/unit.c:326:1: internal compiler error: verify_ssa failed 0x11699ff verify_ssa(bool, bool) gcc-mainline/gcc/tree-ssa.cc:1211 0xe4e6dd execute_function_todo gcc-mainline/gcc/passes.cc:2098 0xe4eb7b execute_todo gcc-mainline/gcc/passes.cc:2145
[Bug target/106536] New: P9: gcc does not detect setb pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106536
Bug ID: 106536
Summary: P9: gcc does not detect setb pattern
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
int compare2(unsigned long long a, unsigned long long b)
{
return (a > b ? 1 : (a < b ? -1 : 0));
}
Output:
_Z8compare2yy:
cmpld 0,3,4
bgt 0,.L5
mfcr 3,128
rlwinm 3,3,1,1
neg 3,3
blr
.L5:
li 3,1
blr
.long 0
.byte 0,9,0,0,0,0,0,0
clang generates:
_Z8compare2yy: # @_Z8compare2yy
cmpld 3, 4
setb 3, 0
extsw 3, 3
blr
.long 0
.quad 0
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-08-05
--- Comment #2 from Jonathan Wakely ---
Looks like this comment is not correct:
/* Compound expressions can only occur here if -Wpedantic or
-pedantic-errors is specified. In the later case, we always want
an error. In the former case, we simply want a warning. */
if (require_constant && pedantic
&& TREE_CODE (inside_init) == COMPOUND_EXPR)
{
inside_init
= valid_compound_expr_initializer (inside_init,
TREE_TYPE (inside_init));
if (inside_init == error_mark_node)
error_init (init_loc, "initializer element is not constant");
else
pedwarn_init (init_loc, OPT_Wpedantic,
"initializer element is not constant");
if (flag_pedantic_errors)
inside_init = error_mark_node;
}
else if (require_constant
&& !initializer_constant_valid_p (inside_init,
TREE_TYPE (inside_init)))
{
error_init (init_loc, "initializer element is not constant");
inside_init = error_mark_node;
}
else if (require_constant && !maybe_const)
pedwarn_init (init_loc, OPT_Wpedantic,
"initializer element is not a constant expression");
Without -pedantic the first condition is false, so it takes the second branch
which uses error_init. With -pedantic the first branch is taken, and it uses
pedwarn_init which is only a warning unless you use -pedantic-errors.
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed for GCC 13.
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:36bc2a8f24f9c8f6eb2c579d520d7fc73a113ae1 commit r13-1972-g36bc2a8f24f9c8f6eb2c579d520d7fc73a113ae1 Author: Richard Biener Date: Fri Aug 5 10:40:18 2022 +0200 tree-optimization/106533 - loop distribution of inner loop of nest Loop distribution currently gives up if the outer loop of a loop nest it analyzes contains a stmt with side-effects instead of continuing to analyze the innermost loop. The following fixes that by continuing anyway. PR tree-optimization/106533 * tree-loop-distribution.cc (loop_distribution::execute): Continue analyzing the inner loops when find_seed_stmts_for_distribution fails. * gcc.dg/tree-ssa/ldist-39.c: New testcase.
[PATCH] tree-optimization/106533 - loop distribution of inner loop of nest
Loop distribution currently gives up if the outer loop of a loop
nest it analyzes contains a stmt with side-effects instead of
continuing to analyze the innermost loop. The following fixes that
by continuing anyway.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/106533
* tree-loop-distribution.cc (loop_distribution::execute): Continue
analyzing the inner loops when find_seed_stmts_for_distribution
fails.
* gcc.dg/tree-ssa/ldist-39.c: New testcase.
---
gcc/testsuite/gcc.dg/tree-ssa/ldist-39.c | 16
gcc/tree-loop-distribution.cc| 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ldist-39.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-39.c
b/gcc/testsuite/gcc.dg/tree-ssa/ldist-39.c
new file mode 100644
index 000..3ef72864d96
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ldist-39.c
@@ -0,0 +1,16 @@
+/* PR/106533 */
+/* { dg-options "-O2 -fdump-tree-ldist-optimized" } */
+
+void bar (int *a, int * __restrict b)
+{
+ for (int k = 0; k < 10; k++)
+{
+ for (int j = 0; j < 10; ++j)
+ a[j] = b[j];
+ __builtin_printf ("Foo!");
+}
+}
+
+/* The stmt with side-effects in the outer loop should not prevent
+ distribution of the inner loop of the loop nest. */
+/* { dg-final { scan-tree-dump "optimized: Loop . distributed: split to 0
loops and 1 library calls" "ldist" } } */
diff --git a/gcc/tree-loop-distribution.cc b/gcc/tree-loop-distribution.cc
index 0ee441c077d..e1948fb452a 100644
--- a/gcc/tree-loop-distribution.cc
+++ b/gcc/tree-loop-distribution.cc
@@ -3829,7 +3829,7 @@ loop_distribution::execute (function *fun)
{
auto_vec work_list;
if (!find_seed_stmts_for_distribution (loop, _list))
- break;
+ continue;
const char *str = loop->inner ? " nest" : "";
dump_user_location_t loc = find_loop_location (loop);
--
2.35.3
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Gabriel Ravier changed: What|Removed |Added Keywords||accepts-invalid, ||rejects-valid --- Comment #1 from Gabriel Ravier --- (PS: I'm not sure whether it's intended that it should be rejected under -pedantic or accepted without any options, so I've used both of the keywords)
[Bug c/106535] New: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Bug ID: 106535 Summary: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- int f = (0, 0); Compiled without any options: :1:9: error: initializer element is not constant 1 | int f = (0, 0); | ^ Compiled with -pedantic: :1:9: warning: initializer element is not constant [-Wpedantic] 1 | int f = (0, 0); | ^ It seems rather odd that adding -pedantic transforms an error into a warning...
Re: 回复：[PATCH v5] LoongArch: add movable attribute
On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote: > I think the model of precpu is not very easy to describe. > model(got)?model(global)? > I also want to use attribute model and -mcmodel together, but this is just an > initial idea, > what do you think? It seems I had some misunderstanding about IA-64 model attribute. IA-64 actually does not have -mcmodel= options. And a code model only specifies where "the GOT and the local symbols" are, but our new attribute should apply for both local symbols and global symbols. So I don't think we should strongly bind the new attribute and -mcmodel. Maybe, __attribute__((addressing_model(got/pcrel32/pcrel64/abs32/abs64)) ? I think they are explicit enough (we can implement got and pc32 first, and adding the others when we implement other code models). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[Bug target/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 --- Comment #7 from Jonathan Wakely --- (In reply to Thomas Klausner from comment #4) > a) there is no conflict since there is no builtin or otherwise sincos() > function > b) it is not declared in math.h As it says, it's a built-in function automatically recognized by GCC, which is documented here: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html With -std=c17 instead of the -std=gnu17 default that doesn't happen. The warning is correct, GCC gives that special handling. You can use -fno-builtin-sincos to disable the handling for this particular function, but maybe that should be the default on NetBSD. > the linker warning is correct though :) Error, not warning :)
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #1 from Richard Biener --- Can you please attach preprocessed source so it can be reproduced with a cc1 cross from x86_64?
[Bug middle-end/106534] New: [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Bug ID: 106534 Summary: [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org Target Milestone: --- Target: amdgcn-amdhsa Build of amdgcn-amdhsa (as offloading compiler for/on x86_64-gnu-linux) fails to build as follows. It did bootstrap successfully a few days back (like Aug 2 or 3): src/gcc-mainline/libgfortran/io/unit.c: In function 'get_gfc_unit': src/gcc-mainline/libgfortran/io/unit.c:326:1: error: definition in block 18 does not dominate use in block 19 326 | get_gfc_unit (int n, int do_create) | ^~~~ for SSA_NAME: p_47 in statement: p_30 = PHI PHI argument p_47 for PHI node p_30 = PHI during GIMPLE pass: phiopt /scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgfortran/io/unit.c:326:1: internal compiler error: verify_ssa failed
Re: [PATCH] place `const volatile' objects in read-only sections
On Fri, Aug 5, 2022 at 10:30 AM Jose E. Marchesi
wrote:
>
>
> Hi Richard.
>
> > On Fri, Aug 5, 2022 at 3:27 AM Jose E. Marchesi via Gcc-patches
> > wrote:
> >>
> >>
> >> Hi people!
> >>
> >> First of all, a bit of context.
> >>
> >> It is common for C BPF programs to use variables that are implicitly set
> >> by the underlying BPF machinery and not by the program itself. It is
> >> also necessary for these variables to be stored in read-only storage so
> >> the BPF verifier recognizes them as such. This leads to declarations
> >> using both `const' and `volatile' qualifiers, like this:
> >>
> >> const volatile unsigned char is_allow_list = 0;
> >>
> >> Where `volatile' is used to avoid the compiler to optimize out the
> >> variable, or turn it into a constant, and `const' to make sure it is
> >> placed in .rodata.
> >>
> >> Now, it happens that:
> >>
> >> - GCC places `const volatile' objects in the .data section, under the
> >> assumption that `volatile' somehow voids the `const'.
> >>
> >> - LLVM places `const volatile' objects in .rodata, under the
> >> assumption that `volatile' is orthogonal to `const'.
> >>
> >> So there is a divergence, and this divergence has practical
> >> consequences: it makes BPF programs compiled with GCC to not work
> >> properly.
> >>
> >> When looking into this, I found this bugzilla:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
> >> "change semantics of const volatile variables"
> >>
> >> which was filed back in 2005. This report was already asking to put
> >> `const volatile' objects in .rodata, questioning the current behavior.
> >>
> >> While discussing this in the #gcc IRC channel I was pointed out to the
> >> following excerpt from the C18 spec:
> >>
> >>6.7.3 Type qualifiers / 5 The properties associated with qualified
> >> types are meaningful only for expressions that are
> >> lval-values [note 135]
> >>
> >>
> >>135) The implementation may place a const object that is not
> >> volatile in a read-only region of storage. Moreover, the
> >> implementation need not allocate storage for such an object if
> >> its $ address is never used.
> >>
> >> This footnote may be interpreted as if const objects that are volatile
> >> shouldn't be put in read-only storage. Even if I was not very convinced
> >> of that interpretation (see my earlier comment in BZ 25521) I filed the
> >> following issue in the LLVM tracker in order to discuss the matter:
> >>
> >> https://github.com/llvm/llvm-project/issues/56468
> >>
> >> As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14
> >> reflectors about this. He reported back that the reflectors consider
> >> footnote 135 has not normative value.
> >>
> >> So, not having a normative mandate on either direction, there are two
> >> options:
> >>
> >> a) To change GCC to place `const volatile' objects in .rodata instead
> >>of .data.
> >>
> >> b) To change LLVM to place `const volatile' objects in .data instead
> >>of .rodata.
> >>
> >> Considering that:
> >>
> >> - One target (bpf-unknown-none) breaks with the current GCC behavior.
> >>
> >> - No target/platform relies on the GCC behavior, that we know. (And it
> >> is unlikely there is any, at least for targets also supported by
> >> LLVM.)
> >>
> >> - Changing the LLVM behavior at this point would be very severely
> >> traumatic for the BPF people and their users.
> >>
> >> I think the right thing to do is a).
> >> Therefore this patch.
> >>
> >> A note about the patch itself:
> >>
> >> I am not that familiar with the middle-end and in this patch I am
> >> assuming that a `var|constructor + SIDE_EFFECTS' is the result of
> >> `volatile' (or an equivalent language construction) and nothing else.
> >> It would be good if some middle-end wizard could confirm this.
> >
> > Yes, for decls that sounds correct. For a CTOR it just means
> > re-evaluation is not safe.
>
> Thanks for confirming.
>
> >> Regtested in x86_64-linux-gnu and bpf-unknown-none.
> >> No regressions observed.
> >
> > I think this warrants a testcase.
>
> Sure, will add one.
> What would be the right testsuite? gcc.dg?
That sounds good.
> > I'm not sure I agree about the whole thing though, I'm leaving it
> > to Joseph.
> >
> >> gcc/ChangeLog:
> >>
> >> PR middle-end/25521
> >> * varasm.cc (categorize_decl_for_section): Place `const volatile'
> >> objects in read-only sections.
> >> (default_select_section): Likewise.
> >> ---
> >> gcc/varasm.cc | 3 ---
> >> 1 file changed, 3 deletions(-)
> >>
> >> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> >> index 4db8506b106..7864db11faf 100644
> >> --- a/gcc/varasm.cc
> >> +++ b/gcc/varasm.cc
> >> @@ -6971,7 +6971,6 @@ default_select_section (tree decl, int reloc,
> >> {
> >>if (! ((flag_pic && reloc)
> >> || !TREE_READONLY (decl)
> >> -|| TREE_SIDE_EFFECTS (decl)
> >> ||
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Keywords||missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-08-05
--- Comment #4 from Richard Biener ---
The code should iterate and eventually distribute inner loops of perfect loop
nests. In fact for
void bar (int *a, int * __restrict b)
{
for (int k = 0; k < 10; k++)
for (int j = 0; j < 10; ++j)
a[j] = b[j];
}
I do see
> ./cc1 -quiet t.c -O2 -fopt-info
t.c:4:23: optimized: Loop 2 distributed: split to 0 loops and 1 library calls.
the issue is likely that
void bar (int *a, int * __restrict b)
{
for (int k = 0; k < 10; k++)
{
for (int j = 0; j < 10; ++j)
a[j] = b[j];
__builtin_printf ("Foo!");
}
}
causes distribution to fail early in find_seed_stmts_for_distribution and
that's taken as fatal error. I have a fix.
Re: [PATCH] place `const volatile' objects in read-only sections
Hi Richard.
> On Fri, Aug 5, 2022 at 3:27 AM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hi people!
>>
>> First of all, a bit of context.
>>
>> It is common for C BPF programs to use variables that are implicitly set
>> by the underlying BPF machinery and not by the program itself. It is
>> also necessary for these variables to be stored in read-only storage so
>> the BPF verifier recognizes them as such. This leads to declarations
>> using both `const' and `volatile' qualifiers, like this:
>>
>> const volatile unsigned char is_allow_list = 0;
>>
>> Where `volatile' is used to avoid the compiler to optimize out the
>> variable, or turn it into a constant, and `const' to make sure it is
>> placed in .rodata.
>>
>> Now, it happens that:
>>
>> - GCC places `const volatile' objects in the .data section, under the
>> assumption that `volatile' somehow voids the `const'.
>>
>> - LLVM places `const volatile' objects in .rodata, under the
>> assumption that `volatile' is orthogonal to `const'.
>>
>> So there is a divergence, and this divergence has practical
>> consequences: it makes BPF programs compiled with GCC to not work
>> properly.
>>
>> When looking into this, I found this bugzilla:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
>> "change semantics of const volatile variables"
>>
>> which was filed back in 2005. This report was already asking to put
>> `const volatile' objects in .rodata, questioning the current behavior.
>>
>> While discussing this in the #gcc IRC channel I was pointed out to the
>> following excerpt from the C18 spec:
>>
>>6.7.3 Type qualifiers / 5 The properties associated with qualified
>> types are meaningful only for expressions that are
>> lval-values [note 135]
>>
>>
>>135) The implementation may place a const object that is not
>> volatile in a read-only region of storage. Moreover, the
>> implementation need not allocate storage for such an object if
>> its $ address is never used.
>>
>> This footnote may be interpreted as if const objects that are volatile
>> shouldn't be put in read-only storage. Even if I was not very convinced
>> of that interpretation (see my earlier comment in BZ 25521) I filed the
>> following issue in the LLVM tracker in order to discuss the matter:
>>
>> https://github.com/llvm/llvm-project/issues/56468
>>
>> As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14
>> reflectors about this. He reported back that the reflectors consider
>> footnote 135 has not normative value.
>>
>> So, not having a normative mandate on either direction, there are two
>> options:
>>
>> a) To change GCC to place `const volatile' objects in .rodata instead
>>of .data.
>>
>> b) To change LLVM to place `const volatile' objects in .data instead
>>of .rodata.
>>
>> Considering that:
>>
>> - One target (bpf-unknown-none) breaks with the current GCC behavior.
>>
>> - No target/platform relies on the GCC behavior, that we know. (And it
>> is unlikely there is any, at least for targets also supported by
>> LLVM.)
>>
>> - Changing the LLVM behavior at this point would be very severely
>> traumatic for the BPF people and their users.
>>
>> I think the right thing to do is a).
>> Therefore this patch.
>>
>> A note about the patch itself:
>>
>> I am not that familiar with the middle-end and in this patch I am
>> assuming that a `var|constructor + SIDE_EFFECTS' is the result of
>> `volatile' (or an equivalent language construction) and nothing else.
>> It would be good if some middle-end wizard could confirm this.
>
> Yes, for decls that sounds correct. For a CTOR it just means
> re-evaluation is not safe.
Thanks for confirming.
>> Regtested in x86_64-linux-gnu and bpf-unknown-none.
>> No regressions observed.
>
> I think this warrants a testcase.
Sure, will add one.
What would be the right testsuite? gcc.dg?
> I'm not sure I agree about the whole thing though, I'm leaving it
> to Joseph.
>
>> gcc/ChangeLog:
>>
>> PR middle-end/25521
>> * varasm.cc (categorize_decl_for_section): Place `const volatile'
>> objects in read-only sections.
>> (default_select_section): Likewise.
>> ---
>> gcc/varasm.cc | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
>> index 4db8506b106..7864db11faf 100644
>> --- a/gcc/varasm.cc
>> +++ b/gcc/varasm.cc
>> @@ -6971,7 +6971,6 @@ default_select_section (tree decl, int reloc,
>> {
>>if (! ((flag_pic && reloc)
>> || !TREE_READONLY (decl)
>> -|| TREE_SIDE_EFFECTS (decl)
>> || !TREE_CONSTANT (decl)))
>> return readonly_data_section;
>> }
>> @@ -7005,7 +7004,6 @@ categorize_decl_for_section (const_tree decl, int
>> reloc)
>>if (bss_initializer_p (decl))
>> ret = SECCAT_BSS;
>>else if (! TREE_READONLY (decl)
>> - || TREE_SIDE_EFFECTS (decl)
>>||
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493 Tobias Burnus changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-05 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Tobias Burnus --- Submitted mainline patch, (still) pending review: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598918.html
Re: 回复：[PATCH v5] LoongArch: add movable attribute
在 2022/8/5 下午3:41, WANG Xuerui 写道: On 2022/8/5 15:19, Lulu Cheng wrote: 在 2022/8/5 下午2:03, Xi Ruoyao 写道: On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote: 在 2022/8/5 上午11:45, Xi Ruoyao 写道: On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote: Or maybe we should just use a PC-relative addressing with 4 instructions instead of GOT for -fno-PIC? Not possible, Glibc does not support R_LARCH_PCALA* relocations in ld.so. So we still need a -mno-got (or something) option to disable GOT for special cases like the kernel. Both way consumes 16 bytes (4 instructions for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC- relative may be more cache friendly. But such a major change cannot be backported for 12.2 IMO. I'm very sorry, my understanding of the precpu variable is wrong, I just read the code of the kernel you submitted, this precpu variable not only has a large offset but also has an uncertain address when compiling, so no matter whether it is addressed with pcrel Still got addressing needs dynamic relocation when loading. It seems that accessing through the got table is a better choice. The name movable is also very vivid to describe this function in the kernel, indicating that the address of the variable can be changed at will. But this name is more difficult to understand in gcc, I have no opinion on other, can this name be changed? Yes, we don't need to be compatible with old vendor compiler IMO. "force_got_access" as Xuerui suggested? Compared with these names, I think addr_global is better. Actually if "model(...)" can be implemented I'd prefer a descriptive word/phrase inside model(). Because it may well be the case that more peculiar ways of accessing some special data will have to be supported in the future, and all of them are kind of "data models" so we'd be able to nicely group them with model(...). Otherwise I actually don't have a particularly strong opinion, aside from "movable" which IMO should definitely not be taken. I think the model of precpu is not very easy to describe. model(got)?model(global)? I also want to use attribute model and -mcmodel together, but this is just an initial idea, what do you think?
