[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 Roman Lebedev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=39369 Resolution|--- |INVALID --- Comment #4 from Roman Lebedev --- clang agrees that the problem seems to be on their side.
Re: Fix std::byte namespace declaration
On 10/18/2018 10:34 PM, Jonathan Wakely wrote:
On 18/10/18 22:12 +0200, François Dumont wrote:
Current build of libstdc++ with
--enable-symvers=gnu-versioned-namespace fails (at least under Linux)
because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
from
../../../../../git/libstdc++-v3/src/c++17/memory_resource.cc:25:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/cstddef:71:59:
error: la référence à « byte » est ambiguë
71 | template<> struct __byte_operand { using __type =
byte; };
| ^~~~
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:61,
from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory:62,
from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:37,
from
../../../../../git/libstdc++-v3/src/c++17/memory_resource.cc:25:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/cpp_type_traits.h:395:30:
note: les candidats sont : « enum class std::__8::byte »
395 | enum class byte : unsigned char;
| ^~~~
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
from
../../../../../git/libstdc++-v3/src/c++17/memory_resource.cc:25:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/cstddef:68:14:
note: « enum class std::byte »
68 | enum class byte : unsigned char {};
| ^~~~
I think the issue if that std::byte declaration in cpp_type_traits.h
has been done in versioned namespace, so the attached patch.
I think the definitions in should use the versioned
namespace macros. Then would be correct.
I thought cstddef was some kind of generated file.
I eventually put all its content in versioned namespace.
* include/c_global/cstddef: Add versioned namespace.
Build successful with the patch, still tests to run. Ok if successful ?
François
diff --git a/libstdc++-v3/include/c_global/cstddef b/libstdc++-v3/include/c_global/cstddef
index 0ca3b82338a..b6d4a13c0b1 100644
--- a/libstdc++-v3/include/c_global/cstddef
+++ b/libstdc++-v3/include/c_global/cstddef
@@ -62,6 +62,7 @@ namespace std
#if __cplusplus >= 201703L
namespace std
{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
#define __cpp_lib_byte 201603
/// std::byte
@@ -187,6 +188,7 @@ namespace std
to_integer(__byte_op_t<_IntegerType> __b) noexcept
{ return _IntegerType(__b); }
+_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
#endif // C++17
} // extern "C++"
Artık Herkes Yapıyor Sosyal Hesaplarınızda Beğeni ve Takipçi Arttırmak Ücretsiz gcc-patches@gcc.gnu.org gcc-patches@gcc.gnu.org!
Youtube Abone Artık Herkes Yapıyor Sosyal Hesaplarınızda Beğeni Almak Binlerce Kişi Tarafından Takip Edilmek Ücretsiz Merhaba gcc-patches@gcc.gnu.org, Siz de yakınlarınızın , arkadaşlarınızın yada sosyal hesaplarınızdaki tanışıklarınızın aşırı beğeni alan içeriklerine ve hergün daha da artan binlerce takipçilerine şahit olup şaşırdınız mı ? Artık herkesin kullandığı yöntemle yüzlerce beğeni almak ve binlerce takipçiye ulaşmak çok kolay ve ÜCRETSİZ. Hemen sitemize ÜCRETSİZ kayıt olun , kredi kazanın yada satın alın ve sosyal hesaplarınız yükselişe geçsin. HEMEN ÜCRETSİZ KAYIT OL Merak ettikleriniz , sormak istedikleriniz için bu maili yanıtlayabilirsiniz. Bu mailin size hata ile gönderildiğini mi düşünüyorsunuz ? Bu ve benzeri mailleri almak istemiyorsanız lütfen `Bilgilendirme` listesinden çıkış yapınız. Youtube Abone - İzlenme , Beğeni , Abone ve Hit Arttırma - 2018 - gcc-patches@gcc.gnu.org
Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)
On 10/01/2018 05:00 PM, Joseph Myers wrote: On Mon, 1 Oct 2018, Martin Sebor wrote: Testing the patch with Glibc triggers thousands of warnings of both kinds. After reviewing a small subset it became apparent Thousands of warnings suggests initially having the warning outside -Wall (though one might hope to move it into -Wall at some point, depending on how hard the warnings are to address and to what extent they appear at all for other packages - most don't make heavy use of aliases like that - or failing that, to enable it explicitly for glibc once all the warnings are fixed, since this is certainly a useful warning for glibc showing issues we want to fix) - it's not like the typical case of a new warning where you can quickly and easily fix all the instances in glibc, for all architectures, to keep it building with mainline GCC. I have improved the Glibc patch to avoid many of the warnings. To avoid most of the rest I have adjusted the GCC patch to make -Wattribute-alias a two-level warning, and to disregard mismatches between aliases and ifunc resolvers. With -Wattribute-alias=1 that reduced the number of unique instances of the warnings for a Glibc build to just 27. Of those, all but one of the -Wattributes instances are of the form: warning: ‘leaf’ attribute has no effect on unit local functions All the -Wmissing-attributes instances are due to a missing nonnull attribute on the __EI__ kinds of functions, like: warning: ‘__EI_vfprintf’ specifies less restrictive attribute than its target ‘vfprintf’: ‘nonnull’ I think both sets might be caused either by a bug/missing handling in my Glibc patch, or by a bug in the GCC patch, but I'm a little lost in the maze of Glibc ifunc macro to tell which just yet. I can keep looking into it but it would make it easier if you could apply it and see if the Glibc macros need tweaking. Enabling -Wattribute-alias=2 shows the remaining attribute mismatches (those highlighting "potential bugs," although I suspect few, if any, are real bugs; more than likely they are benign.) attribute called copy. The attribute copies attributes from one declaration (or type) to another. The attribute doesn't resolve all the warnings but it helps. (For actual use in glibc that use would of course need to be conditional on a GCC version supporting the attribute.) Sure. The patch is just to show what I did to get the warnings. (Attached is an update with the changes I mentioned above and the Glibc warning breakdown with it.) The class of warnings I noticed that can't be so easily handled are due to inconsistencies between ifuncs and their resolvers. One way to solve it might be to have resolvers automatically "inherit" all the attributes of their targets (and enhance GCC to warn for violations). Another way might be to expect resolvers to be explicitly declared with attribute copy to copy the attributes of all the targets (and also warn for violations). I'm not sure we should care about the attributes on IFUNC resolvers at all; no normal code will see a declaration of the resolver and also call the function, whereas lots of code calls functions under internal alias names that currently lack the same attributes as the public declaration has. It's also not obvious whether there might be more cases of attributes for a function that are inapplicable to IFUNC resolvers than just the attributes relating to a symbol rather than the function itself which are hardcoded as excluded. I agree that checking attributes on ifunc resolvers probably doesn't make much sense. It would be helpful to check their targets against the aliases, but that's a whole other project. Attached is the latest update along with the Glibc warning breakdown. Tested on x86_64-linux. Martin PR middle-end/81824 - Warn for missing attributes with function aliases gcc/c-family/ChangeLog: PR middle-end/81824 * c-attribs.c (handle_copy_attribute_impl): New function. (handle_copy_attribute): Same. gcc/cp/ChangeLog: PR middle-end/81824 * pt.c (warn_spec_missing_attributes): Move code to attribs.c. Call decls_mismatched_attributes. gcc/ChangeLog: PR middle-end/81824 * attribs.c (has_attribute): New helper function. (decls_mismatched_attributes, maybe_diag_alias_attributes): Same. * attribs.h (decls_mismatched_attributes): Declare. * cgraphunit.c (handle_alias_pairs): Call maybe_diag_alias_attributes. (maybe_diag_incompatible_alias): Use OPT_Wattribute_alias_. * common.opt (-Wattribute-alias): Take an argument. (-Wno-attribute-alias): New option. * doc/extend.texi (Common Function Attributes): Document copy. (Common Variable Attributes): Same. * doc/invoke.texi (-Wmissing-attributes): Document enhancement. (-Wattribute-alias): Document new option argument. libgomp/ChangeLog: PR c/81824 * libgomp.h (strong_alias, ialias, ialias_redirect): Use attribute copy. gcc/testsuite/ChangeLog: PR middle-end/81824 * gcc.dg/Wattribute-alias.c: New test. *
[Bug c++/87699] New: Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
Bug ID: 87699
Summary: Implement CWG 1512
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
As per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html
the below should not compile.
https://godbolt.org/z/mOpxau
bool foo(int* bar)
{
return bar > 0;
}
Go patch committed: Export indexed type data, read unexported types lazily
This patch to the Go frontend changes the export format to index type
data so that it doesn't have to be read until needed. It changes the
importer to only read the exported types at first, and to read other
types as they are needed. It introduces a new "types" command to the
export data to record the number of types and the size of their export
data. It is immediately followed by new "type" commands that can be
indexed. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 265408)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e1dc92a6037a3f81ea1b8ea8fb6207af33505f0c
+6db7e35d3bcd75ab3cb15296a5ddc5178038c9c1
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: gcc/go/gofrontend/export.cc
===
--- gcc/go/gofrontend/export.cc (revision 265408)
+++ gcc/go/gofrontend/export.cc (working copy)
@@ -44,11 +44,49 @@ const int Export::checksum_len;
// Constructor.
Export::Export(Stream* stream)
- : stream_(stream), type_refs_(), type_index_(1), packages_()
+ : stream_(stream), type_index_(1), packages_()
{
go_assert(Export::checksum_len == Go_sha1_helper::checksum_len);
}
+// Type hash table operations, treating aliases as distinct.
+
+class Type_hash_alias_identical
+{
+ public:
+ unsigned int
+ operator()(const Type* type) const
+ {
+return type->hash_for_method(NULL,
+(Type::COMPARE_ERRORS
+ | Type::COMPARE_TAGS
+ | Type::COMPARE_ALIASES));
+ }
+};
+
+class Type_alias_identical
+{
+ public:
+ bool
+ operator()(const Type* t1, const Type* t2) const
+ {
+return Type::are_identical(t1, t2,
+ (Type::COMPARE_ERRORS
+ | Type::COMPARE_TAGS
+ | Type::COMPARE_ALIASES),
+ NULL);
+ }
+};
+
+// Mapping from Type objects to a constant index. This would be nicer
+// as a field in Export, but then export.h would have to #include
+// types.h.
+
+typedef Unordered_map_hash(const Type*, int, Type_hash_alias_identical,
+ Type_alias_identical) Type_refs;
+
+static Type_refs type_refs;
+
// A functor to sort Named_object pointers by name.
struct Sort_bindings
@@ -139,9 +177,10 @@ Export::export_globals(const std::string
std::sort(exports.begin(), exports.end(), Sort_bindings());
- // Find all packages not explicitly imported but mentioned by types.
+ // Assign indexes to all exported types and types referenced by
+ // exported types, and collect all packages mentioned.
Unordered_set(const Package*) type_imports;
- this->prepare_types(, _imports);
+ int unexported_type_index = this->prepare_types(, _imports);
// Although the export data is readable, at least this version is,
// it is conceptually a binary format. Start with a four byte
@@ -178,10 +217,17 @@ Export::export_globals(const std::string
// and ABI being used, although ideally any problems in that area
// would be caught by the linker.
+ // Write out all the types, both exported and not.
+ this->write_types(unexported_type_index);
+
+ // Write out the non-type export data.
for (std::vector::const_iterator p = exports.begin();
p != exports.end();
++p)
-(*p)->export_named_object(this);
+{
+ if (!(*p)->is_type())
+ (*p)->export_named_object(this);
+}
std::string checksum = this->stream_->checksum();
std::string s = "checksum ";
@@ -204,9 +250,10 @@ Export::export_globals(const std::string
class Find_types_to_prepare : public Traverse
{
public:
- Find_types_to_prepare(Unordered_set(const Package*)* imports)
+ Find_types_to_prepare(Export* exp,
+ Unordered_set(const Package*)* imports)
: Traverse(traverse_types),
- imports_(imports)
+ exp_(exp), imports_(imports)
{ }
int
@@ -221,19 +268,34 @@ class Find_types_to_prepare : public Tra
traverse_named_type(Named_type*);
private:
+ // Exporters.
+ Export* exp_;
// List of packages we are building.
Unordered_set(const Package*)* imports_;
};
-// Traverse a type.
+// Set type index of referenced type, record package imports, and make
+// sure we traverse methods of named types.
int
Find_types_to_prepare::type(Type* type)
{
- // Skip forwarders.
+ // Skip forwarders; don't try to give them a type index.
if (type->forward_declaration_type() != NULL)
return TRAVERSE_CONTINUE;
+ // Skip the void type, which we'll see when exporting
+ // unsafe.Pointer. The void type is not itself exported, because
+ // Pointer_type::do_export checks for it.
+ if (type->is_void_type())
+
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #5) > The description of what the warning is supposed to do is still incredibly > vague and unspecified. It's whatever you agreed to here: (In reply to Jonathan Wakely from comment #2) > > I agree a warning when the functions are declared could be useful for > finding the problem earlier
NDI[SV]: JKT: Blsvn: JV Invite
- This mail is in HTML. Some elements may be ommited in plain text. - Hello, I sent you an e-mail last week but did not receive any feedback from you so I am sending this message hoping to get your response. We are international project financiers and we specialize in both start up projects and existing businesses needing funding or Loan for expansion. We are committed to helping businesses develop and succeed. We will like to partner with you/your company should you be interested or may require funding for the expansion of your business. We will be glad to receiving your terms and condition before proceeding further. This is my personal email: jamkit...@outlook.com Looking forward to hear from you. Sincere regards, James Kitula.
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
On 10/22/18 7:20 PM, Segher Boessenkool wrote:
> Hi peter,
>> + /* If we have a matching constraint and both operands are hard
>> registers,
>> + then they must be the same hard register. */
>> + if (HARD_REGISTER_P (output)
>> + && HARD_REGISTER_P (input)
>> + && REGNO (output) != REGNO (input))
>
> You need to test for REG_P (input) before you can HARD_REGISTER_P (input)
> or REGNO (input).
Yup, already done that. Just checking the s390 debugger which is seeing
a SUBREG, so trying to decide whether I should be looking inside the SUBREG
or not. Shouldn't be hard to do if it makes sense.
>> +fatal_insn ("unable to fixup asm constraints for:", insn);
>
> "impossible constraints"? There are some more of those already. Or you
> could describe the actual problem even?
>
>> +/* Operands don't match. Make sure the two operands
>> + are not two different explicit hard registers. */
>> +if (HARD_REGISTER_P (*curr_id->operand_loc[nop])
>> +&& HARD_REGISTER_P (*curr_id->operand_loc[m]))
>> + fatal_insn ("unable to generate reloads for:",
>> + curr_insn);
>
> Same here (and below) :-)
Yeah, I like that. Thanks.
Peter
Ping^2 Re: [PATCH v3 0/6] [MIPS] Reorganize the loongson march and extensions instructions set
Ping ? On Fri, Oct 19, 2018 at 2:19 PM Paul Hua wrote: > > Ping? > > I'd like check in those patches before stage3. > > Thanks, > > On Tue, Oct 16, 2018 at 10:49 AM Paul Hua wrote: > > > > Hi: > > > > The original version of patches were here: > > https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00099.html > > > > This is a update version. please review, thanks. > > > > This series patches reorganize the Loongson -march=xxx and Loongson > > extensions instructions set. For long time, the Loongson extensions > > instructions set puts under -march=loongson3a option. We can't > > disable one of them when we need. > > > > The patch (1) split Loongson MultiMedia extensions Instructions (MMI) > > from loongson3a, add -mloongson-mmi/-mno-loongson-mmi option for > > enable/disable them. > > > > The patch (2) split Loongson EXTensions (EXT) instructions from > > loongson3a, add -mloongson-ext/-mno-loongson-ext option for > > enable/disable them. > > > > The patch (3) add Loongson EXTensions R2 (EXT2) instructions support, > > add -mloongson-ext2/-mno-loongson-ext2 option for enable/disable them. > > > > The patch (4) add Loongson 3A1000 processor support. The gs464 is a > > codename of 3A1000 microarchitecture. Rename -march=loongson3a to > > -march=gs464, Keep -march=loongson3a as an alias of -march=gs464 for > > compatibility. > > > > The patch (5) add Loongson 3A2000/3A3000 processor support. Include > > Loongson MMI, EXT, EXT2 instructions set. > > > > The patch (6) add Loongson 2K1000 processor support. Include Loongson > > MMI, EXT, EXT2 and MSA instructions set. > > > > The binutils patch has been upstreamed. > > > > There are six patches in this set, as follows. > > 1) 0001-MIPS-Add-support-for-loongson-mmi-instructions.patch > > 2) 0002-MIPS-Add-support-for-Loongson-EXT-istructions.patch > > 3) 0003-MIPS-Add-support-for-Loongson-EXT2-istructions.patch > > 4) 0004-MIPS-Add-support-for-Loongson-3A1000-proccessor.patch > > 5) 0005-MIPS-Add-support-for-Loongson-3A2000-3A3000-proccess.patch > > 6) 0006-MIPS-Add-support-for-Loongson-2K1000-proccessor.patch > > > > All patchs test under mips64el-linux-gnu no new regressions. > > > > Ok for commit ? > > > > Thanks, > > Paul Hua
Trying to debug a testsuite failure
In running the gcc testsuite on pdp11, I get some failures like this: collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 exit status compilation terminated. compiler exited with status 1 FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions While those tests flags are not terribly useful on a small memory platform like pdp11, I wouldn't expect a failure like that. Some tests with those flags do pass. The real issue is that collect2 is apparently failing for no visible reason and without any helpful explanation of what it's trying to do. Any hints on how I might debug this? paul
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
Hi peter,
On Mon, Oct 22, 2018 at 06:40:58PM -0500, Peter Bergner wrote:
> --- gcc/function.c(revision 265399)
> +++ gcc/function.c(working copy)
> @@ -6453,6 +6453,13 @@ match_asm_constraints_1 (rtx_insn *insn,
> || !general_operand (input, GET_MODE (output)))
> continue;
>
> + /* If we have a matching constraint and both operands are hard
> registers,
> + then they must be the same hard register. */
> + if (HARD_REGISTER_P (output)
> + && HARD_REGISTER_P (input)
> + && REGNO (output) != REGNO (input))
You need to test for REG_P (input) before you can HARD_REGISTER_P (input)
or REGNO (input).
> + fatal_insn ("unable to fixup asm constraints for:", insn);
"impossible constraints"? There are some more of those already. Or you
could describe the actual problem even?
> + /* Operands don't match. Make sure the two operands
> +are not two different explicit hard registers. */
> + if (HARD_REGISTER_P (*curr_id->operand_loc[nop])
> + && HARD_REGISTER_P (*curr_id->operand_loc[m]))
> + fatal_insn ("unable to generate reloads for:",
> + curr_insn);
Same here (and below) :-)
Segher
Re: [PATCH, rs6000] Don't use deprecated __vector long in intrinsic compatibility headers
Hi! On Mon, Oct 22, 2018 at 01:33:18PM -0500, Bill Schmidt wrote: > We should never use __vector long in the intrinsics compatibility headers, > since this has different meanings on 32- and 64-bit targets. This patch > corrects a number of places where this previously slipped through. > --- gcc/config/rs6000/emmintrin.h (revision 265389) > +++ gcc/config/rs6000/emmintrin.h (working copy) > @@ -888,7 +888,8 @@ _mm_cvtpd_epi32 (__m128d __A) > > #ifdef _ARCH_PWR8 >temp = vec_mergeo (temp, temp); > - result = (__v4si)vec_vpkudum ((__vector long)temp, (__vector long)vzero); > + result = (__v4si)vec_vpkudum ((__vector long long)temp, > + (__vector long long)vzero); The old code had this as well, but there should be a space after a cast. Okay for trunk with or without that fixed up. Thanks! Segher
[PATCH] correct max alignment check in symtab.c
GCC was hitting an ICE on some pdp11 tests due to a typo in a max alignment
check.
Committed as obvious.
paul
ChangeLog:
2018-10-22 Paul Koning
* symtab.c (symtab_node::increase_alignment): Correct max
alignment check.
Index: symtab.c
===
--- symtab.c(revision 265403)
+++ symtab.c(working copy)
@@ -2205,7 +2205,7 @@ increase_alignment_1 (symtab_node *n, void *v)
void
symtab_node::increase_alignment (unsigned int align)
{
- gcc_assert (can_increase_alignment_p () && align < MAX_OFILE_ALIGNMENT);
+ gcc_assert (can_increase_alignment_p () && align <= MAX_OFILE_ALIGNMENT);
ultimate_alias_target()->call_for_symbol_and_aliases (increase_alignment_1,
(void *)(size_t) align,
true);
Re: [PATCH, rs6000] Use explicit casts for vec_sel argument 3 in intrinsic headers
Hi Bill,
On Mon, Oct 22, 2018 at 01:29:15PM -0500, Bill Schmidt wrote:
> The vec_sel intrinsic is overloaded for multiple types. There are a
> couple of cases in our intrinsic compatibility headers where the types
> used don't match any allowable type signature. GCC is able to correctly
> infer which matching built-in function is meant, but not all compilers
> can. For compatibility, cast the third parameter correctly in the
> source code.
> --- gcc/config/rs6000/emmintrin.h (revision 265389)
> +++ gcc/config/rs6000/emmintrin.h (working copy)
> @@ -1766,7 +1766,7 @@ _mm_sll_epi64 (__m128i __A, __m128i __B)
>shmask = lshift < shmax;
>result = vec_vsld ((__v2du) __A, lshift);
>result = (__v2du) vec_sel ((__v2df) shmask, (__v2df) result,
> - (__v2df) shmask);
> + (vector unsigned long long) shmask);
shmask already is a proper type, just delete the cast? (And then fit this
on one line).
> --- gcc/config/rs6000/xmmintrin.h (revision 265389)
> +++ gcc/config/rs6000/xmmintrin.h (working copy)
> @@ -458,7 +458,7 @@ extern __inline __m128 __attribute__((__gnu_inline
> _mm_min_ps (__m128 __A, __m128 __B)
> {
>__m128 m = (__m128) vec_vcmpgtfp ((__v4sf) __B, (__v4sf) __A);
> - return vec_sel (__B, __A, m);
> + return vec_sel (__B, __A, (vector unsigned int)m);
m should not be type __m128, but maybe __v4si? The cast of the vec_vcmpgtfp
result can go away as well then, maybe.
Segher
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
On 10/22/18 6:40 PM, Peter Bergner wrote: > On 10/22/18 3:58 PM, Jeff Law wrote: >> On 10/19/18 4:39 PM, Peter Bergner wrote: >>> Jeff, maybe once Segher commits his patch, can you give this patch a try >>> on your testers? >> Once committed to the trunk it's automatically picked up :-) In fact, >> commits to the trunk are triggers, though in reality there's *always* >> something changing from one day to the next in the various relevant >> repos (gcc, binutils, linux kernel, glibc & newlib). >> >> It's only testing patches that aren't on the trunk that require manual >> intervention. > > I meant could you give *my* patch a try once Segher's combine patch hit trunk. > It didn't really make sense to try my patch before his patch hit trunk, since > my patch was catching some illegal insn constraint usage. Bah, my bootstrap failed and I need to make a small change. Let me do that and verify my bootstraps get all the way thru before I give you the updated patch. Sorry. Peter
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
On 10/22/18 3:58 PM, Jeff Law wrote:
> On 10/19/18 4:39 PM, Peter Bergner wrote:
>> Jeff, maybe once Segher commits his patch, can you give this patch a try
>> on your testers?
> Once committed to the trunk it's automatically picked up :-) In fact,
> commits to the trunk are triggers, though in reality there's *always*
> something changing from one day to the next in the various relevant
> repos (gcc, binutils, linux kernel, glibc & newlib).
>
> It's only testing patches that aren't on the trunk that require manual
> intervention.
I meant could you give *my* patch a try once Segher's combine patch hit trunk.
It didn't really make sense to try my patch before his patch hit trunk, since
my patch was catching some illegal insn constraint usage.
That said, here is an updated patch I'd like you to try now that Segher's
patch is on trunk. It's basically the same patch as before, but using
HARD_REGISTER_P suggested by Segher and another change that catches more
illegal constraint usage, this time matching constraints that don't match,
but where the user has incorrectly forced register usage to different hard
regs. We used to incorrectly reload one of the hard coded operands and go
on our merry way. Now we throw an error:
bergner@pike:~/gcc/BUGS/PR87507$ cat ice6.i
long foo (void)
{
register long arg asm("r3");
register long var asm("r4");
asm ("bla %0 %1" : "=r"(arg) : "0"(var));
return arg;
}
bergner@pike:~/gcc/BUGS/PR87507$
/home/bergner/gcc/build/gcc-fsf-mainline-pr87507-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr87507-debug/gcc -O2 -S ice6.i
ice6.i: In function ‘foo’:
ice6.i:7:1: error: unable to fixup asm constraints for:
7 | }
| ^
(insn 5 2 11 2 (parallel [
(set (reg/v:DI 3 3 [ arg ])
(asm_operands:DI ("bla %0 %1") ("=r") 0 [
(reg/v:DI 4 4 [ var ])
]
[
(asm_input:DI ("0") ice6.i:5)
]
[] ice6.i:5))
(clobber (reg:SI 76 ca))
]) "ice6.i":5:3 -1
(expr_list:REG_DEAD (reg/v:DI 4 4 [ var ])
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil
during RTL pass: asmcons
ice6.i:7:1: internal compiler error: in match_asm_constraints_1, at
function.c:6461
I'm currently bootstrapping and regtesting this on powerpc64le-linux,
x86_64-linux
and s390x-linux. If you could throw it on your testers to test the other
arches,
that would be great!
Peter
* function.c (match_asm_constraints_1): Catch illegal inline asm
constraint usage.
* lra-constraints.c (process_alt_operands): Abort on illegal hard
register usage. Prefer reloading non hard register operands.
Index: gcc/function.c
===
--- gcc/function.c (revision 265399)
+++ gcc/function.c (working copy)
@@ -6453,6 +6453,13 @@ match_asm_constraints_1 (rtx_insn *insn,
|| !general_operand (input, GET_MODE (output)))
continue;
+ /* If we have a matching constraint and both operands are hard registers,
+then they must be the same hard register. */
+ if (HARD_REGISTER_P (output)
+ && HARD_REGISTER_P (input)
+ && REGNO (output) != REGNO (input))
+ fatal_insn ("unable to fixup asm constraints for:", insn);
+
/* We can't do anything if the output is also used as input,
as we're going to overwrite it. */
for (j = 0; j < ninputs; j++)
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c (revision 265399)
+++ gcc/lra-constraints.c (working copy)
@@ -2146,9 +2146,15 @@ process_alt_operands (int only_alternati
}
else
{
- /* Operands don't match. Both operands must
- allow a reload register, otherwise we
- cannot make them match. */
+ /* Operands don't match. Make sure the two operands
+ are not two different explicit hard registers. */
+ if (HARD_REGISTER_P (*curr_id->operand_loc[nop])
+ && HARD_REGISTER_P (*curr_id->operand_loc[m]))
+ fatal_insn ("unable to generate reloads for:",
+ curr_insn);
+
+ /* Both operands must allow a reload register,
+ otherwise we cannot make them match. */
if (curr_alt[m] == NO_REGS)
break;
/* Retroactively mark the operand we had to
@@ -2910,18 +2916,28 @@ process_alt_operands (int only_alternati
if (first_conflict_j < 0)
first_conflict_j = j;
last_conflict_j = j;
+ /* Both
Re: [PATCH, rs6000 2/2] Add compatible implementations of x86 SSSE3 intrinsics
On Mon, Oct 22, 2018 at 01:26:11PM -0500, Paul Clarke wrote: > Target tests for the intrinsics defined in pmmintrin.h, copied from > gcc.target/i386. > > Tested on POWER8 ppc64le and ppc64 (-m64 and -m32, the latter only reporting > 16 new unsupported tests), and also by forcing -mcpu=power7 on ppc64. Why are they unsupported? lp64? Why do many of those tests require lp64 anyway? It's not obvious to me. You tested on a >=p8 (with a compiler defaulting to that, too) I hope ;-) Segher
Re: [PATCH, rs6000 1/2] Add compatible implementations of x86 SSSE3 intrinsics
Hi Paul,
On Mon, Oct 22, 2018 at 01:25:57PM -0500, Paul Clarke wrote:
> This is a follow-on to earlier commits for adding compatibility
> implementations of x86 intrinsics for PPC64LE. This patch adds
> the 32 x86 intrinsics from ("SSSE3").
> +extern __inline __m64 __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
You could make this fit on a line by wrapping before the __attribute__.
This is true for previous patches as well of course, but it kind of
annoys me in this one.
> +_mm_alignr_pi8 (__m64 __A, __m64 __B, unsigned int __count)
> +{
> + if (__count < 16)
> + {
Indentation is broken here and elsewhere in this file. Please fix.
if (...)
{
blabla;
blabla;
}
else
{
blabla;
blabla;
}
> +__v2du __C = {__B, __A};
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> +const __v4su __shift = {__count << 3, 0, 0, 0};
> +__C = (__v2du) vec_sro ((__v16qu)__C,(__v16qu) __shift);
Space after cast. Space after comma.
> +#else
> +const __v4su __shift = { 0, 0, 0, __count << 3 };
Sometimes you put spaces inside {} and sometimes not. Please choose one?
Common style is with.
This is okay for trunk if made a bit more readable (by following the usual
coding style rules, say ;-) )
Segher
Re: [[C++ PATCH]] Implement C++2a P0330R2 - Literal Suffixes for ptrdiff_t and size_t
On Mon, 22 Oct 2018, Jason Merrill wrote: > > I'm thinking of making this feature available as an extension to all of > > C/C++ perhaps with appropriate pedwarn. > > > > Opinions? > > That seems reasonable to me, but Joseph will need to weigh in about C. A C extension would seem reasonable, if documented as such in the manual (and with pedwarns tested in the testsuite, etc.). (The patch is also missing invoke.texi updates for the new command-line option, in any case.) -- Joseph S. Myers jos...@codesourcery.com
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #21 from Harald van Dijk --- (In reply to Segher Boessenkool from comment #20) > That is still not what I said, so don't pretend I did please. > > Those are also not false positives: in all these cases, the program does > in fact skip some initialisation. "Pretend"? When you misrepresented my words, I did not accuse you of any type of deception, I assumed it was simply a misunderstanding and responded accordingly. I'd appreciate the same treatment from you. You made an ambiguous comment which I did not recognise as ambiguous at the time. You wrote: > -Wall please, unless there are frequent false positives. [...] "False positive" can be interpreted in two ways. It can be read as a false positive wrt -Wjump-misses-init, meaning a warning where no initialisation is jumped over. It turns out this is what you meant. It can also be read as I did, which is a false positive wrt -Wall, which is documented as: > This enables all the warnings about constructions that some users > consider questionable, and that are easy to avoid (or modify to > prevent the warning), even in conjunction with macros. [...] A false positive here would mean that the warning is either about a construct that users do not consider questionable, or that is not easy to avoid. I was responding based on the assumption that this is what you meant. Initialisation is commonly jumped over in large bodies of C code, which is a good indication that it is not largely considered questionable, and of the cases I'd found, although all can be worked around to suppress the warning, quite a lot of them would get a lot uglier. It did not even scan to me that you might be saying that the only reason you'd not propose -Wjump-misses-init be included in -Wall is if -Wjump-misses-init doesn't do what it's supposed to. > But, it seems -Wjump-misses-init is not what you want; you do not want a > warning for jumping over initialisers, it warns for a lot of harmless code. > What you want is a warning that only warns if the var is (potentially) used > without initialisation? Yes, at least for -Wall. Since -Wjump-misses-init triggers too often for commonly used C patterns, I do not think it is appropriate to include it in -Wall. At the same time, for the originally reported code, it does seem like *some* warning at -Wall would be appropriate. A warning about the use of the potentially-uninitialised variable, as clang does, seems sensible to me.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #1 from Romain Geissler --- Note: this is the source of the following error when linking with ld.lld 7.0: ld.lld: error: corrupt input file: version definition index 0 for symbol _libssh2_ntohu32 is out of bounds >>> defined in >>> /projects/combld/delivery/continuous/components.osp/osp/SSH2/18-0-0-0/lib/x86_64-2.6.32-v4/Debug/libssh2.so Don't know if this particular behavior is a ld.lld bug though, I actually don't expect these symbols to be even defined in the final libssh2.so.
[Bug lto/87698] New: [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 Bug ID: 87698 Summary: [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, Is it expected that a shared library where each .o file has been built with -flto -ffat-lto-objects has more symbol relocation (absolute symbol relocations) than the very same shared library built with -flto -ffat-lto-objects ? With gcc 8.2.1 20181011 I have the following symbols defined in the case of fat lto objects when building libssh2 (https://github.com/libssh2/libssh2): /opt/1A/toolchain/x86_64-2.6.32-v4/bin/readelf -a ~combld/delivery/continuous/components.osp/osp/SSH2/18-0-0-0/lib/x86_64-2.6.32-v4/Debug/libssh2.so|grep ABS 138: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_session_set_bloc 142: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_store_str 143: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_sha1_init 149: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_next 152: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_comp_methods 154: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_ntohu64 155: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_init_aes_ctr 159: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_sha1_verify 163: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_first 168: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_base64_encode 170: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_new_private_ 172: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_pub_priv_keyfile 178: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_locate 179: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_kex_exchange 186: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_transport_read 187: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_extended 188: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_read 191: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_sha1_verify 194: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_burn 198: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_ntohu32 200: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_userauth_publick 203: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_receive_ 204: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new_private_ 205: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_pub_priv_keyfile 206: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_sha1_sign 209: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_free 215: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_init 217: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_write 223: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_htonu32 224: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_close 228: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_send 230: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_forward_ 232: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new_private 235: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_sha256_init 236: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_recv 245: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_md5_init 247: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_requirev 250: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_process_ 251: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_require 260: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_add 264: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_wait_socket 265: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_ask 267: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_cipher_init 271: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_sha1_sign 272: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_error_flags 273: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_new_private 275: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new 282: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_error 285:
Re: Port of gccgo to GNU/Hurd
On Mon, 2018-10-22 at 11:15 +0200, Svante Signell wrote:
> Hello,
>
> As advised by the Debian gcc maintainer Matthias Klose and golang
> developer Ian Lance Taylor (Cc:ed) I'm (re-)submitting the patches
> for the port of gccgo to GNU/Hurd.
>
> The 13 patches are:
Due to some editing errors this patch had to be updated:
> src_libgo_go_syscall_syscall_gnu_test.go.diff
Thanks!libgo/ChangeLog
2018-10-20 Svante Signell
* libgo/go/syscall/syscall_gnu_test.go: New file,
derived from syscall_unix_test.go. Flock_t members
Type and Whence are int32 instead of int16.
Index: gcc-snapshot-20181019-1.1/src/libgo/go/syscall/syscall_gnu_test.go
===
--- /dev/null
+++ gcc-snapshot-20181019-1.1/src/libgo/go/syscall/syscall_gnu_test.go
@@ -0,0 +1,357 @@
+// Copyright 2013 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+// This file is identical to syscall_unix_test.go except that
+// Flock_t members Type and Whence are int32 instead of int16.
+
+// +build gnu
+
+package syscall_test
+
+import (
+ "flag"
+ "fmt"
+ "internal/testenv"
+ "io"
+ "io/ioutil"
+ "net"
+ "os"
+ "os/exec"
+ "path/filepath"
+ "runtime"
+ "syscall"
+ "testing"
+ "time"
+)
+
+// Tests that below functions, structures and constants are consistent
+// on all Unix-like systems.
+func _() {
+ // program scheduling priority functions and constants
+ var (
+ _ func(int, int, int) error = syscall.Setpriority
+ _ func(int, int) (int, error) = syscall.Getpriority
+ )
+ const (
+ _ int = syscall.PRIO_USER
+ _ int = syscall.PRIO_PROCESS
+ _ int = syscall.PRIO_PGRP
+ )
+
+ // termios constants
+ const (
+ _ int = syscall.TCIFLUSH
+ _ int = syscall.TCIOFLUSH
+ _ int = syscall.TCOFLUSH
+ )
+
+ // fcntl file locking structure and constants
+ var (
+ _ = syscall.Flock_t{
+ Type: int32(0),
+ Whence: int32(0),
+ Start: int64(0),
+ Len:int64(0),
+ Pid:int32(0),
+ }
+ )
+ const (
+ _ = syscall.F_GETLK
+ _ = syscall.F_SETLK
+ _ = syscall.F_SETLKW
+ )
+}
+
+// TestFcntlFlock tests whether the file locking structure matches
+// the calling convention of each kernel.
+// On some Linux systems, glibc uses another set of values for the
+// commands and translates them to the correct value that the kernel
+// expects just before the actual fcntl syscall. As Go uses raw
+// syscalls directly, it must use the real value, not the glibc value.
+// Thus this test also verifies that the Flock_t structure can be
+// roundtripped with F_SETLK and F_GETLK.
+func TestFcntlFlock(t *testing.T) {
+ if runtime.GOOS == "darwin" && (runtime.GOARCH == "arm" || runtime.GOARCH == "arm64") {
+ t.Skip("skipping; no child processes allowed on iOS")
+ }
+ flock := syscall.Flock_t{
+ Type: syscall.F_WRLCK,
+ Start: 31415, Len: 271828, Whence: 1,
+ }
+ if os.Getenv("GO_WANT_HELPER_PROCESS") == "" {
+ // parent
+ tempDir, err := ioutil.TempDir("", "TestFcntlFlock")
+ if err != nil {
+ t.Fatalf("Failed to create temp dir: %v", err)
+ }
+ name := filepath.Join(tempDir, "TestFcntlFlock")
+ fd, err := syscall.Open(name, syscall.O_CREAT|syscall.O_RDWR|syscall.O_CLOEXEC, 0)
+ if err != nil {
+ t.Fatalf("Open failed: %v", err)
+ }
+ defer os.RemoveAll(tempDir)
+ defer syscall.Close(fd)
+ if err := syscall.Ftruncate(fd, 1<<20); err != nil {
+ t.Fatalf("Ftruncate(1<<20) failed: %v", err)
+ }
+ if err := syscall.FcntlFlock(uintptr(fd), syscall.F_SETLK, ); err != nil {
+ t.Fatalf("FcntlFlock(F_SETLK) failed: %v", err)
+ }
+ cmd := exec.Command(os.Args[0], "-test.run=^TestFcntlFlock$")
+ cmd.Env = append(os.Environ(), "GO_WANT_HELPER_PROCESS=1")
+ cmd.ExtraFiles = []*os.File{os.NewFile(uintptr(fd), name)}
+ out, err := cmd.CombinedOutput()
+ if len(out) > 0 || err != nil {
+ t.Fatalf("child process: %q, %v", out, err)
+ }
+ } else {
+ // child
+ got := flock
+ // make sure the child lock is conflicting with the parent lock
+ got.Start--
+ got.Len++
+ if err := syscall.FcntlFlock(3, syscall.F_GETLK, ); err != nil {
+ t.Fatalf("FcntlFlock(F_GETLK) failed: %v", err)
+ }
+ flock.Pid = int32(syscall.Getppid())
+ // Linux kernel always set Whence to 0
+ flock.Whence = 0
+ if got.Type == flock.Type && got.Start == flock.Start && got.Len == flock.Len && got.Pid == flock.Pid && got.Whence == flock.Whence {
+ os.Exit(0)
+ }
+ t.Fatalf("FcntlFlock got %v, want %v", got, flock)
+ }
+}
+
+// TestPassFD tests passing a file descriptor over a Unix socket.
+//
+// This test involved both a parent and child process. The parent
+// process is invoked as a normal test, with "go test", which then
+// runs the child process by running the current test binary with args
+// "-test.run=^TestPassFD$" and an environment variable used to signal
+// that the test should become the child process instead.
+func TestPassFD(t *testing.T) {
+ testenv.MustHaveExec(t)
+
+ if
[Bug c++/87697] New: Casting a base class to derived gives no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697 Bug ID: 87697 Summary: Casting a base class to derived gives no warning Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jynelson at email dot sc.edu Target Milestone: --- Created attachment 44881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44881=edit The preprocessed source Casting a base class to a derived class gives no warning, even with -Wall -Werror enabled. I've been told on IRC that this sort of cast is undefined behaviour according to spec if neither class is virtual. If that is the case, it would be nice to have a warning. If that isn't the case, there are several more questions that arise, like `why does c1 have access to c2` and `why can the const value c2::x be accessed without be initialized`? $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) $ g++ -Wall -Werror inheritance.cc $ ./a.out constructor 1 c2: 0
Re: [[C++ PATCH]] Implement C++2a P0330R2 - Literal Suffixes for ptrdiff_t and size_t
On 10/21/18 4:39 PM, Ed Smith-Rowland wrote: All, This patch implements C++2a proposal P0330R2 Literal Suffixes for ptrdiff_t and size_t*. It's not official yet but looks very likely to pass. It is incomplete because I'm looking for some opinions. (We also might wait 'till it actually passes). I don't mind putting it in before it passes so long as you keep track of the proposal's progress -- I just discovered that the string UDL template proposal we implemented for C++14 wasn't actually accepted, so we need to pedwarn about it. This paper takes the direction of a language change rather than a library change through C++11 literal operators. This was after feedback on that paper after a few iterations. As coded in this patch, integer suffixes involving 'z' are errors in C and warnings for C++ <= 17 (in addition to the usual warning about implementation suffixes shadowing user-defined ones). OTOH, the 'z' suffix is not currently legal - it can't break currently-correct code in any C/C++ dialect. furthermore, I suspect the language direction was chosen to accommodate a similar addition to C20. I'm thinking of making this feature available as an extension to all of C/C++ perhaps with appropriate pedwarn. Opinions? That seems reasonable to me, but Joseph will need to weigh in about C. Jason
[Bug web/87696] gcc-patches mail archive does not show attachments clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87696 --- Comment #1 from Andrew Pinski --- Raw format still has that information. I think this is just an artifact of how to display attachments and nothing is lost really.
Re: [PATCH] add simple attribute introspection
On 10/13/18 8:19 PM, Martin Sebor wrote:
+ oper = cp_parser_type_id (parser);
+ parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
+
+ if (cp_parser_parse_definitely (parser))
+{
+ /* If all went well, set OPER to the type. */
+ cp_decl_specifier_seq decl_specs;
+
+ /* Build a trivial decl-specifier-seq. */
+ clear_decl_specs (_specs);
+ decl_specs.type = oper;
+
+ /* Call grokdeclarator to figure out what type this is. */
+ oper = grokdeclarator (NULL,
+_specs,
+TYPENAME,
+/*initialized=*/0,
+/*attrlist=*/NULL);
+}
Doesn't grokdeclarator here give you back the same type you already had
from cp_parser_type_id? The latter already calls grokdeclarator.
I don't know why cp_parser_sizeof_operand does this, either. Try
removing it from both places?
+ /* Consume the comma if it's there. */
+ if (!cp_parser_require (parser, CPP_COMMA, RT_COMMA))
+{
+ parens.require_close (parser);
I think you want cp_parser_skip_to_closing_parenthesis for error
recovery, rather than require_close.
+ if (tree attr = cp_parser_gnu_attribute_list (parser, /*exactly_one=*/true))
+{
+ if (oper != error_mark_node)
+ {
+ /* Fold constant expressions used in attributes first. */
+ cp_check_const_attributes (attr);
+
+ /* Finally, see if OPER has been declared with ATTR. */
+ ret = has_attribute (atloc, oper, attr, default_conversion);
+ }
+}
+ else
+{
+ error_at (atloc, "expected identifier");
+ cp_parser_skip_to_closing_parenthesis (parser, true, false, false);
+}
+
+ parens.require_close (parser);
I think the require_close should be in the valid case, since *skip*
already consumes a closing paren.
+is valuated. The @var{type-or-expression} argument is subject to the same
evaluated
Jason
Re: [PATCH 4/6] [ARC] Add peephole rules to combine store/loads into double store/loads
On 22 October 2018 19:49:35 CEST, Andrew Burgess wrote: >* Claudiu Zissulescu [2018-10-10 11:00:14 +0300]: >> --- a/gcc/config/arc/arc.c >> +++ b/gcc/config/arc/arc.c >> @@ -10803,6 +10803,169 @@ arc_cannot_substitute_mem_equiv_p (rtx) >>return true; >> } >> >> +/* Checks whether the operands are valid for use in an LDD/STD >> + instruction. Assumes that RT, RT2, and RN are REG. This is >> + guaranteed by the patterns. Assumes that the address in the base >> + register RN is word aligned. Pattern guarantees that both memory >> + accesses use the same base register, the offsets are constants >> + within the range, and the gap between the offsets is 4. If >preload >> + complete then check that registers are legal. WBACK indicates >> + whether address is updated. */ > >You've got tabs instead of whitespace inside both this comment block, >and others within this patch. It should be period and two whitespace >at the end of each sentence. See contrib/check_GNU_style.py Also: s/If preload/If reload/ thanks,
[Bug web/87696] New: gcc-patches mail archive does not show attachments clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87696 Bug ID: 87696 Summary: gcc-patches mail archive does not show attachments clearly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- See, for example, https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01360.html . The original mail contained one gzipped attachment (due to the size restrictions) and seven test cases. The web entry shows the attachment as separate file (which is OK) and loses all information about where one attachment starts and the other ends, and what they were originally called.
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 --- Comment #4 from Tiago Macarios --- Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=39363
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
On 10/19/2018 05:16 PM, Peter Bergner wrote:
Vlad, Jeff and Segher,
I think I have determined what is happening with the aarch64 test case that
is failing after my r264897 commit. It appears my patch is just exposing
an issue in lra-constraints.c:process_alt_operands() when processing an insn
with early clobber operands. Jeff & Segher, I have reverted all of my
previous patches we were making to lra-lives.c for the analysis below and
am just using straight trunk revision 264897 (ie, my last patch).
...
Secondly, I don't think it's ever legal to reload an operand
that has been hard coded by the user to a hard register via a register asm
definition like in the test case above.
Yes, if a variable declared as an asm variable, the asm insn should use
its hard register. That is what people expect and that is what the GCC
documentation about asm says. In most cases, reload of such asm variable
hard registers do not happen as they satisfy the constraints except for
this complicated earlyclobber case you found.
With that in mind, what do people think of the patch below? This fixes the
AARCH64 test case. However, it ICE's on the following test case:
long foo (long arg)
{
register long var asm("x0");
asm("bla %0 %1" : "+"(var) : "r"(arg));
return var;
}
...but that is due to a combine bug where combine replaces the use of
"arg"'s pseudo in the inline asm with the incoming argument reg x0 which
should be illegal. Ie, it's taking a valid inline asm and creating an
invalid one since the earlyclobber op and non-matching op have both
been forced to use the same hard reg. Segher has a combine patch to
stop that which he is going to submit (commit?) soon. With my patch,
we are also now able to catch the following user error, when before we
could not:
I think usage of hard registers in RTL should be minimal. Any their
propagation besides RA creates a risk for RA work and probably does not
improve the final code.
...
Thoughts? I'll note that this does not fix the S390 bugs, since those seem
to be due to problems with early clobber operands and "matching" constraint
operands. I'm still working on that and hope to have something soon.
I think your initial patch triggered a bug in RA. Your patch looks a
reasonable solution for me. But the patch touches a very sensitive code
in LRA (I don't remember when a change in
lra-constraints.c:process_alt_operands worked completely fine at the
first iteration). So it would be nice to test it on many targets before
committing.
Peter, thank you for continuing your work on these RA issues.
I am currently bootstrapping this on s390x just to make sure I don't break
anything there, before debugging the existing s390x issue(s). I can't test
this on aarch64 or arm, other than knowing my aarch64 cross doesn't ICE on
the test case above.
Peter
* lra-constraints.c (process_alt_operands): Abort on illegal hard
register usage. Prefer reloading non hard register operands.
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c (revision 264897)
+++ gcc/lra-constraints.c (working copy)
@@ -2904,18 +2904,29 @@ process_alt_operands (int only_alternati
if (first_conflict_j < 0)
first_conflict_j = j;
last_conflict_j = j;
+ /* Both the earlyclobber operand and conflicting operand
+ cannot both be hard registers. */
+ if (REGNO (operand_reg[i]) < FIRST_PSEUDO_REGISTER
+ && operand_reg[j] != NULL_RTX
+ && REGNO (operand_reg[j]) < FIRST_PSEUDO_REGISTER)
+ fatal_insn ("unable to generate reloads for:", curr_insn);
}
if (last_conflict_j < 0)
continue;
- /* If earlyclobber operand conflicts with another
-non-matching operand which is actually the same register
-as the earlyclobber operand, it is better to reload the
-another operand as an operand matching the earlyclobber
-operand can be also the same. */
- if (first_conflict_j == last_conflict_j
- && operand_reg[last_conflict_j] != NULL_RTX
- && ! curr_alt_match_win[last_conflict_j]
- && REGNO (operand_reg[i]) == REGNO (operand_reg[last_conflict_j]))
+
+ /* If an earlyclobber operand conflicts with another non-matching
+operand (ie, they have been assigned the same hard register),
+then it is better to reload the other operand, as there may
+exist yet another operand with a matching constraint associated
+with the earlyclobber operand. However, if one of the operands
+is an explicit use of a hard register, then we must reload the
+other non-hard register operand. */
+ if (REGNO (operand_reg[i]) < FIRST_PSEUDO_REGISTER
+ ||
Re: [PATCH] combine: Do not combine moves from hard registers
Hi Jeff, On Mon, Oct 22, 2018 at 02:52:12PM -0600, Jeff Law wrote: > I know we've gone back and forth on this stuff through the years, > particularly for targets with likely-to-spilled classes that are used > for register passing/return values. Right, there already was code to not copy to a pseudo for such registers, and this patch extends it to all hard (but not fixed) registers. That reduces code quality quite a bit though, because the move itself can often be combine. For that, this now adds an extra copy to a fresh pseudo, and that fixes this. (cc:ing Alan who did the previous attempt I remember). > I'm certainly willing to go with this as general guidance. I wouldn't > be surprised if we find that things like CSE, fwprop and other passes > need twiddling over time to mimick what you're doing in combine. Yes that could well be. I think fwprop is fine, but there could well be other passes. The asm problem in PR87600 no longer triggers, but it could be those passes stay away from asm, or something like that. Segher
Re: [patch, fortran] Implement FINDLOC
Hi Dominique,
With your patch, compiling the following test
program logtest3
implicit none
logical :: x = .true.
integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, &
back=x)
end program logtest3
gives an ICE
I sometimes wonder where you get all these test cases from...
Anyway, the attached patch fixes this, plus the print *, instead
of test for return values, plus the whitespace issues mentioned
by Bernhard. Patch gzipped this time to let it go through to
gcc-patches.
OK for trunk?
Regards
Thomas
p15.diff.gz
Description: application/gzip
! { dg-do compile }
! Test errors in findloc.
program main
integer, dimension(4) :: a
logical, dimension(3) :: msk
a = [2,4,6,8]
print *,findloc(a) ! { dg-error "Missing actual argument" }
print *,findloc(a,value=.true.) ! { dg-error "must be in type conformance to argument" }
print *,findloc(a,23,dim=6) ! { dg-error "is not a valid dimension index" }
print *,findloc(a,-42,dim=2.0) ! { dg-error "must be INTEGER" }
print *,findloc(a,6,msk) ! { dg-error "Different shape for arguments 'array' and 'mask'" }
print *,findloc(a,6,kind=98) ! { dg-error "Invalid kind for INTEGER" }
end program main
! { dg-do run }
! Various tests with findloc.
program main
implicit none
real, dimension(2,2) :: a, b
integer, dimension(2,3) :: c
logical, dimension(2,2) :: lo
integer, dimension(:), allocatable :: e
a = reshape([1.,2.,3.,4.], shape(a))
b = reshape([1.,2.,1.,2.], shape(b))
lo = .true.
if (any(findloc(a, 5.) /= [0,0])) stop 1
if (any(findloc(a, 5., back=.true.) /= [0,0])) stop 2
if (any(findloc(a, 2.) /= [2,1])) stop 2
if (any(findloc(a, 2. ,back=.true.) /= [2,1])) stop 3
if (any(findloc(a,3.,mask=lo) /= [1,2])) stop 4
if (any(findloc(a,3,mask=.true.) /= [1,2])) stop 5
lo(1,2) = .false.
if (any(findloc(a,3.,mask=lo) /= [0,0])) stop 6
if (any(findloc(b,2.) /= [2,1])) stop 7
if (any(findloc(b,2.,back=.true.) /= [2,2])) stop 8
if (any(findloc(b,1.,mask=lo,back=.true.) /= [1,1])) stop 9
if (any(findloc(b,1.,mask=.false.) /= [0,0])) stop 10
c = reshape([1,2,2,2,-9,6], shape(c))
if (any(findloc(c,value=2,dim=1) /= [2,1,0])) stop 11
if (any(findloc(c,value=2,dim=2) /= [2,1])) stop 12
end program main
! { dg-do run }
! Various tests with findloc with character variables.
program main
character(len=2) :: a(3,3), c(3,3), d(3,4)
character(len=3) :: b(3,3)
integer :: ret(2)
integer :: i,j
character(len=3) :: s
logical :: lo
logical, dimension(3,4) :: msk
data a /"11", "21", "31", "12", "22", "32", "13", "23", "33" /
data b /"11 ", "21 ", "31 ", "12 ", "22 ", "32 ", "13 ", "23 ", "33 " /
if (any(findloc(a,"11 ") /= [1,1])) stop 1
ret = findloc(b,"31")
do j=1,3
do i=1,3
write(unit=s,fmt='(2I1," ")') i,j
ret = findloc(b,s)
if (b(ret(1),ret(2)) /= s) stop 2
end do
end do
if (any(findloc(b(::2,::2),"13") /= [1,2])) stop 3
do j=1,3
do i=1,3
write(unit=c(i,j),fmt='(I2)') 2+i-j
end do
end do
if (any(findloc(c," 1") /= [1,2])) stop 4
if (any(findloc(c," 1", back=.true.) /= [2,3])) stop 5
if (any(findloc(c," 1", back=.true., mask=.false.) /= [0,0])) stop 6
lo = .true.
if (any(findloc(c," 2", dim=1) /= [1,2,3])) stop 7
if (any(findloc(c," 2",dim=1,mask=lo) /= [1,2,3])) stop 8
if (any(findloc(c," 2", dim=1,back=.true.) /= [1,2,3])) stop 9
if (any(findloc(c," 2",dim=1,mask=lo,back=.true.) /= [1,2,3])) stop 10
do j=1,4
do i=1,3
if (j<= i) then
d(i,j) = "AA"
else
d(i,j) = "BB"
end if
end do
end do
print '(4A3)', transpose(d)
if (any(findloc(d,"AA") /= [1,1])) stop 11
if (any(findloc(d,"BB") /= [1,2])) stop 12
msk = .true.
if (any(findloc(d,"AA", mask=msk) /= [1,1])) stop 11
if (any(findloc(d,"BB", mask=msk) /= [1,2])) stop 12
if (any(findloc(d,"AA", dim=1) /= [1,2,3,0])) stop 13
if (any(findloc(d,"BB", dim=1) /= [0,1,1,1])) stop 14
if (any(findloc(d,"AA", dim=2) /= [1,1,1])) stop 15
if (any(findloc(d,"BB", dim=2) /= [2,3,4])) stop 16
if (any(findloc(d,"AA", dim=1,mask=msk) /= [1,2,3,0])) stop 17
if (any(findloc(d,"BB", dim=1,mask=msk) /= [0,1,1,1])) stop 18
if (any(findloc(d,"AA", dim=2,mask=msk) /= [1,1,1])) stop 19
if (any(findloc(d,"BB", dim=2,mask=msk) /= [2,3,4])) stop 20
if (any(findloc(d,"AA", dim=1, back=.true.) /= [3,3,3,0])) stop 21
if (any(findloc(d,"AA", dim=1, back=.true., mask=msk) /= [3,3,3,0])) stop 22
if (any(findloc(d,"BB", dim=2, back=.true.) /= [4,4,4])) stop 23
if (any(findloc(d,"BB", dim=2, back=.true.,mask=msk) /= [4,4,4])) stop 24
msk(1,:) = .false.
print '(4L3)', transpose(msk)
if (any(findloc(d,"AA", dim=1,mask=msk) /= [2,2,3,0])) stop 21
if (any(findloc(d,"BB", dim=2,mask=msk) /= [0,3,4])) stop 22
if (any(findloc(d,"AA", dim=2, mask=msk, back=.true.) /= [0,2,3])) stop 23
if (any(findloc(d,"AA", dim=1, mask=msk, back=.true.) /= [3,3,3,0])) stop 24
end program main
Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507
On 10/19/18 4:39 PM, Peter Bergner wrote: > On 10/19/18 4:16 PM, Peter Bergner wrote: >> Thoughts? I'll note that this does not fix the S390 bugs, since those seem >> to be due to problems with early clobber operands and "matching" constraint >> operands. I'm still working on that and hope to have something soon. > [snip] >> * lra-constraints.c (process_alt_operands): Abort on illegal hard >> register usage. Prefer reloading non hard register operands. > > I stand corrected. Using this patch, plus Segher's combine patch, I am > able to bootstrap s390x-linux. I'm running the test suite to see whether > that looks clean as well. Maybe those s390 issues were related to combine > pushing hard regs into patterns and we just weren't handling them well? > > Jeff, maybe once Segher commits his patch, can you give this patch a try > on your testers? Once committed to the trunk it's automatically picked up :-) In fact, commits to the trunk are triggers, though in reality there's *always* something changing from one day to the next in the various relevant repos (gcc, binutils, linux kernel, glibc & newlib). It's only testing patches that aren't on the trunk that require manual intervention. jeff
Re: [PATCH] combine: Do not combine moves from hard registers
On 10/22/18 2:17 PM, Segher Boessenkool wrote: > On most targets every function starts with moves from the parameter > passing (hard) registers into pseudos. Similarly, after every call > there is a move from the return register into a pseudo. These moves > usually combine with later instructions (leaving pretty much the same > instruction, just with a hard reg instead of a pseudo). > > This isn't a good idea. Register allocation can get rid of unnecessary > moves just fine, and moving the parameter passing registers into many > later instructions tends to prevent good register allocation. This > patch disallows combining moves from a hard (non-fixed) register. > > This also avoid the problem mentioned in PR87600 #c3 (combining hard > registers into inline assembler is problematic). > > Because the register move can often be combined with other instructions > *itself*, for example for setting some condition code, this patch adds > extra copies via new pseudos after every copy-from-hard-reg. > > On some targets this reduces average code size. On others it increases > it a bit, 0.1% or 0.2% or so. (I tested this on all *-linux targets). > > I'll commit this to trunk now. If there are problems, please don't > hesitate to let me know! Thanks. > > > Segher > > > 2018-10-22 Segher Boessenkool > > PR rtl-optimization/87600 > * combine.c: Add include of expr.h. > (cant_combine_insn_p): Do not combine moves from any hard non-fixed > register to a pseudo. > (make_more_copies): New function, add a copy to a new pseudo after > the moves from hard registers into pseudos. > (rest_of_handle_combine): Declare rebuild_jump_labels_after_combine > later. Call make_more_copies. I know we've gone back and forth on this stuff through the years, particularly for targets with likely-to-spilled classes that are used for register passing/return values. I'm certainly willing to go with this as general guidance. I wouldn't be surprised if we find that things like CSE, fwprop and other passes need twiddling over time to mimick what you're doing in combine. jeff
Debug unordered containers code cleanup
I plan to commit the attached patch this week if not told otherwise. This is to generalize usage of C++11 direct initialization in unordered containers. It also avoids a number of safe iterator instantiations. * include/debug/unordered_map (unordered_map<>::begin()): Use C++11 direct initialization. (unordered_map<>::end()): Likewise. (unordered_map<>::cbegin()): Likewise. (unordered_map<>::cend()): Likewise. (unordered_map<>::begin(size_type)): Likewise. (unordered_map<>::end(size_type)): Likewise. (unordered_map<>::cbegin(size_type)): Likewise. (unordered_map<>::cend(size_type)): Likewise. (unordered_map<>::emplace<>(_Args&&...)): Likewise. (unordered_map<>::emplace_hint<>(const_iterator, _Args&&...)): Likewise. (unordered_map<>::insert(const value_type&)): Likewise. (unordered_map<>::insert(value_type&&)): Likewise. (unordered_map<>::insert<>(_Pair&&)): Likewise. (unordered_map<>::insert(const_iterator, const value_type&)): Likewise. (unordered_map<>::insert(const_iterator, value_type&&)): Likewise. (unordered_map<>::insert<>(const_iterator, _Pair&&)): Likewise. (unordered_map<>::try_emplace<>(const key_type&, _Args&&...)): Likewise. (unordered_map<>::try_emplace<>(key_type&&, _Args&&...)): Likewise. (unordered_map<>::try_emplace<>(const_iterator, const key_type&, _Args&&...)): Likewise. (unordered_map<>::try_emplace<>(const_iterator, key_type&&, _Args&&...)): Likewise. (unordered_map<>::insert_or_assign<>(const key_type&, _Obj&&)): Likewise. (unordered_map<>::insert_or_assign<>(key_type&&, _Obj&&)): Likewise. (unordered_map<>::insert_or_assign<>(const_iterator, const key_type&, _Obj&&)): Likewise. (unordered_map<>::insert_or_assign<>(const_iterator, key_type&&, _Obj&&)): Likewise. (unordered_map<>::insert(note_type&&)): Likewise. (unordered_map<>::find(const key_type&)): Likewise. (unordered_map<>::equal_range(const key_type&)): Likewise. (unordered_map<>::_M_extract): New. (unordered_map<>::extract(const_iterator)): Use latter. (unordered_map<>::extract(const key_type&)): Likewise. (unordered_map<>::_M_erase): New. (unordered_map<>::erase(const key_type&)): Use latter. (unordered_map<>::erase(const_iterator)): Likewise. (unordered_map<>::erase(iterator)): Likewise. (unordered_map<>::_M_invalidate): New. (unordered_map<>::erase(const_iterator, const_iterator)): Use latter. (unordered_multimap<>::begin()): Use C++11 direct initialization. (unordered_multimap<>::end()): Likewise. (unordered_multimap<>::cbegin()): Likewise. (unordered_multimap<>::cend()): Likewise. (unordered_multimap<>::begin(size_type)): Likewise. (unordered_multimap<>::end(size_type)): Likewise. (unordered_multimap<>::cbegin(size_type)): Likewise. (unordered_multimap<>::cend(size_type)): Likewise. (unordered_multimap<>::emplace<>(_Args&&...)): Likewise. (unordered_multimap<>::emplace_hint<>(const_iterator, _Args&&...)): Likewise. (unordered_multimap<>::insert(const value_type&)): Likewise. (unordered_multimap<>::insert(const_iterator, const value_type&)): Likewise. (unordered_multimap<>::insert(const_iterator, value_type&&)): Likewise. (unordered_multimap<>::insert<>(_Pair&&)): Likewise. (unordered_multimap<>::insert<>(const_iterator, _Pair&&)): Likewise. (unordered_multimap<>::insert(note_type&&)): Likewise. (unordered_multimap<>::insert(const_iterator, note_type&&)): Likewise. (unordered_multimap<>::find(const key_type&)): Likewise. (unordered_multimap<>::equal_range(const key_type&)): Likewise. (unordered_multimap<>::_M_extract): New. (unordered_multimap<>::extract(const_iterator)): Use latter. (unordered_multimap<>::extract(const key_type&)): Likewise. (unordered_multimap<>::_M_erase): New. (unordered_multimap<>::erase(const_iterator)): Likewise. (unordered_multimap<>::erase(iterator)): Likewise. (unordered_multimap<>::_M_invalidate): New. (unordered_multimap<>::erase(const key_type&)): Use latter. (unordered_multimap<>::erase(const_iterator, const_iterator)): Likewise. * include/debug/unordered_set (unordered_set<>::begin()): Use C++11 direct initialization. (unordered_set<>::end()): Likewise. (unordered_set<>::cbegin()): Likewise. (unordered_set<>::cend()): Likewise. (unordered_set<>::begin(size_type)): Likewise. (unordered_set<>::end(size_type)): Likewise. (unordered_set<>::cbegin(size_type)): Likewise. (unordered_set<>::cend(size_type)): Likewise. (unordered_set<>::emplace<>(_Args&&...)): Likewise. (unordered_set<>::emplace_hint<>(const_iterator, _Args&&...)): Likewise. (unordered_set<>::insert(const value_type&)): Likewise. (unordered_set<>::insert(value_type&&)): Likewise. (unordered_set<>::insert(const_iterator, const value_type&)): Likewise. (unordered_set<>::insert(const_iterator, value_type&&)):
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #10 from Yury Gribov --- Let me know if issue persists, otherwise I'll close in couple of days.
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 Jonathan Wakely changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Jonathan Wakely --- The description of what the warning is supposed to do is still incredibly vague and unspecified.
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #9 from Yury Gribov --- Author: ygribov Date: Mon Oct 22 20:26:32 2018 New Revision: 265399 URL: https://gcc.gnu.org/viewcvs?rev=265399=gcc=rev Log: 2018-10-22 Yury Gribov gcc/ PR tree-optimization/87633 * match.pd: Do not generate unordered integer comparisons. gcc/testsuite/ PR tree-optimization/87633 * g++.dg/pr87633.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr87633.C Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Mon Oct 22 20:23:39 2018 New Revision: 265398 URL: https://gcc.gnu.org/viewcvs?rev=265398=gcc=rev Log: combine: Do not combine moves from hard registers On most targets every function starts with moves from the parameter passing (hard) registers into pseudos. Similarly, after every call there is a move from the return register into a pseudo. These moves usually combine with later instructions (leaving pretty much the same instruction, just with a hard reg instead of a pseudo). This isn't a good idea. Register allocation can get rid of unnecessary moves just fine, and moving the parameter passing registers into many later instructions tends to prevent good register allocation. This patch disallows combining moves from a hard (non-fixed) register. This also avoid the problem mentioned in PR87600 #c3 (combining hard registers into inline assembler is problematic). Because the register move can often be combined with other instructions *itself*, for example for setting some condition code, this patch adds extra copies via new pseudos after every copy-from-hard-reg. On some targets this reduces average code size. On others it increases it a bit, 0.1% or 0.2% or so. (I tested this on all *-linux targets). PR rtl-optimization/87600 * combine.c: Add include of expr.h. (cant_combine_insn_p): Do not combine moves from any hard non-fixed register to a pseudo. (make_more_copies): New function, add a copy to a new pseudo after the moves from hard registers into pseudos. (rest_of_handle_combine): Declare rebuild_jump_labels_after_combine later. Call make_more_copies. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
Re: [RFC] GCC support for live-patching
Hi, thanks for the comments. > > thanks for the proposal. The others have already expressed some of my > worries and remarks, but I think it would be only right to write them > again. Especially since I am part of the team responsible for > implementation and maintenance of live patches here at SUSE, we use kGraft > and we prepare everything manually (compared to kpatch and ksplice). One question here, what’s the major benefit to prepare the patches manually? > >> 1. A study of Kernel live patching schemes. >> >> Three major kernel live patching tools: https://lwn.net/Articles/734765/ >> >> * ksplice: http://www.ksplice.com/doc/ksplice.pdf >> * kpatch:https://lwn.net/Articles/597123/ >>https://github.com/dynup/kpatch >> * kGraft: >> https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf >> >> In the above, ksplice and kpatch can automatically generate binary patches >> as following: >> >> * a collection of tools which convert a source diff patch to a patch >> module. They work by compiling the kernel both with and without the source >> patch, comparing the binaries, and generating a binary patch module which >> includes new binary versions of the functions to be replaced. >> >> on the other hand, kGraft offers a way to create patches entirely by hand. >> The source of the patch is a single C file, easy to review, easy to >> maintain. >> >> In addition to kGraft, there are other live patching tools that prefer >> creating patches by hand for the similar reason. >> >> The compiler support is mainly for the above live patching tools that create >> patches entirely by hand. the major purpose is: >> >> * control patch code size and debug complexity; >> * keep good run time performance; >> >> 2. the major problems of compiler in live patching: >> >> For the live patching schemes that create patches by hand, when patching >> one function, there might a list of functions that will be impacted by >> this patched function due to compiler optimization/analyses (mainly IPA >> optimization/analyses), a complete patch will include the patched function >> and all impacted functions. Usually, there are two major factors to be >> considered in such live patching schemes: >> >> * patch code size, one major factor is the length of the list >> of impacted functions; >> * run time performance. >> >> If we want to control the patch code size, to make the list of impacted >> functions minimum, we have to disable corresponding compiler optimizations >> as much as possible. > > Andi already talked about it and I, too, do not understand your worry > about patch code size. First, it has never been so bad here. Yes, > sometimes the function closure gets bigger due to optimizations and > inlining. I've considered it as nothing else than a lack of better > tooling, because it is indeed something which could be improved a lot. > Nicolai (CCed) works on a potential solution. It is also one of the topics > at LPC miniconf in Vancouver. > > Second, the idea to disable inlining would not fly at SUSE. I can't > imagine to even propose it. The kernel heavily relies on the feature. The > optimizations are a different story and some of those certainly could be > disabled with no harm caused. > > So let me ask, what is your motivation behind this? Is there a real > problem you're trying to solve? It may have been mentioned somewhere and I > missed it. the major functionality we want is: to Only enable static inlining for live patching for one of our internal customers. the major purpose is to control the patch code size explosion and debugging complexity due to too much inlining of global functions for the specific application. therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from different users. So far, from the feedback, I see that among the 4 levels of control, none, only-inline-static, inline, and inline-clone, “none” and “inline” are NOT needed at all. however, -flive-patching = [only-inline-static | inline-clone] are necessary. > >> On the other hand, in order to keep good run time performance, we need to >> keep the compiler optimization as much as possible. >> >> So, there should be some tradeoff between these two factors. >> >> The following are two major categories of compiler optimizations >> we should considered: >> >> A. compiler optimizations/analyses that extract ipa info from >> a routine's body, and use such info to guide other optimization. >> >> Since the body of the routine might be changed for live patching, >> the ipa info extracted from the body of the routine also changes, >> as a result, all the routines that directly or indirectly utilize >> the ipa info from this routine are in the list of the impacted >> routines. >> >> Most of the IPA analyses and optimization belong to this category. >> >> Although theoretically the
[PATCH] combine: Do not combine moves from hard registers
On most targets every function starts with moves from the parameter
passing (hard) registers into pseudos. Similarly, after every call
there is a move from the return register into a pseudo. These moves
usually combine with later instructions (leaving pretty much the same
instruction, just with a hard reg instead of a pseudo).
This isn't a good idea. Register allocation can get rid of unnecessary
moves just fine, and moving the parameter passing registers into many
later instructions tends to prevent good register allocation. This
patch disallows combining moves from a hard (non-fixed) register.
This also avoid the problem mentioned in PR87600 #c3 (combining hard
registers into inline assembler is problematic).
Because the register move can often be combined with other instructions
*itself*, for example for setting some condition code, this patch adds
extra copies via new pseudos after every copy-from-hard-reg.
On some targets this reduces average code size. On others it increases
it a bit, 0.1% or 0.2% or so. (I tested this on all *-linux targets).
I'll commit this to trunk now. If there are problems, please don't
hesitate to let me know! Thanks.
Segher
2018-10-22 Segher Boessenkool
PR rtl-optimization/87600
* combine.c: Add include of expr.h.
(cant_combine_insn_p): Do not combine moves from any hard non-fixed
register to a pseudo.
(make_more_copies): New function, add a copy to a new pseudo after
the moves from hard registers into pseudos.
(rest_of_handle_combine): Declare rebuild_jump_labels_after_combine
later. Call make_more_copies.
---
gcc/combine.c | 50 ++
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/gcc/combine.c b/gcc/combine.c
index 256b5a4..3ff1760 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -99,6 +99,7 @@ along with GCC; see the file COPYING3. If not see
#include "explow.h"
#include "insn-attr.h"
#include "rtlhooks-def.h"
+#include "expr.h"
#include "params.h"
#include "tree-pass.h"
#include "valtrack.h"
@@ -2348,8 +2349,7 @@ cant_combine_insn_p (rtx_insn *insn)
dest = SUBREG_REG (dest);
if (REG_P (src) && REG_P (dest)
&& ((HARD_REGISTER_P (src)
- && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src))
- && targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO (src
+ && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src)))
|| (HARD_REGISTER_P (dest)
&& ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (dest))
&& targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO
(dest))
@@ -14969,11 +14969,53 @@ dump_combine_total_stats (FILE *file)
total_attempts, total_merges, total_extras, total_successes);
}
+/* Make pseudo-to-pseudo copies after every hard-reg-to-pseudo-copy, because
+ the reg-to-reg copy can usefully combine with later instructions, but we
+ do not want to combine the hard reg into later instructions, for that
+ restricts register allocation. */
+static void
+make_more_copies (void)
+{
+ basic_block bb;
+
+ FOR_EACH_BB_FN (bb, cfun)
+{
+ rtx_insn *insn;
+
+ FOR_BB_INSNS (bb, insn)
+{
+ if (!NONDEBUG_INSN_P (insn))
+continue;
+
+ rtx set = single_set (insn);
+ if (!set)
+ continue;
+ rtx src = SET_SRC (set);
+ rtx dest = SET_DEST (set);
+ if (GET_CODE (src) == SUBREG)
+ src = SUBREG_REG (src);
+ if (!(REG_P (src) && HARD_REGISTER_P (src)))
+ continue;
+ if (TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src)))
+ continue;
+
+ rtx new_reg = gen_reg_rtx (GET_MODE (dest));
+ rtx_insn *insn1 = gen_move_insn (new_reg, src);
+ rtx_insn *insn2 = gen_move_insn (dest, new_reg);
+ emit_insn_after (insn1, insn);
+ emit_insn_after (insn2, insn1);
+ delete_insn (insn);
+
+ insn = insn2;
+ }
+}
+}
+
/* Try combining insns through substitution. */
static unsigned int
rest_of_handle_combine (void)
{
- int rebuild_jump_labels_after_combine;
+ make_more_copies ();
df_set_flags (DF_LR_RUN_DCE + DF_DEFER_INSN_RESCAN);
df_note_add_problem ();
@@ -14982,7 +15024,7 @@ rest_of_handle_combine (void)
regstat_init_n_sets_and_refs ();
reg_n_sets_max = max_reg_num ();
- rebuild_jump_labels_after_combine
+ int rebuild_jump_labels_after_combine
= combine_instructions (get_insns (), max_reg_num ());
/* Combining insns may have turned an indirect jump into a
--
1.8.3.1
Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules
On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote: > So I did some further investigation comparing the ULP error. > > With the formula that Wilco Dijkstra provided, there are cases where > the substitution is super precise. > With floats: > with input : = 9.9940395355224609375000e-01 > sinh: before: = 2.89631005859375e+03 > sinh: after : = 2.896309326171875000e+03 > sinh: mpfr : = 2.89630924626497842670468162463283783344599446025119e+03 > ulp err befr: = 3 > ulp err aftr: = 0 > > With doubles: > with input : = 9.99888977697537484345957636833190917969e-01 > sinh: before: = 6.710886400029802322387695312500e+07 > sinh: after : = 6.71088632549419403076171875e+07 > sinh: mpfr : = 6.710886344120645523071287770030292885894208e+07 > ulp err befr: = 3 > ulp err aftr: = 0 > > *However*, there are cases where some error shows up. The biggest ULP > error that I could find was 2. > > With floats: > with input : = 9.99968349933624267578125000e-01 > sinh: before: = 1.2568613433837890625000e+02 > sinh: after : = 1.2568614959716796875000e+02 > sinh: mpfr : = 1.25686137592274042266452526368087062890399889097864e+02 > ulp err befr: = 0 > ulp err aftr: = 2 > > With doubles: > with input : = 9.999463651256803586875321343541145324707031e-01 > sinh: before: = 9.65520209507428342476487159729003906250e+05 > sinh: after : = 9.6552020950742810964584350585937500e+05 > sinh: mpfr : = 9.65520209507428288553227922831618987450806468855883e+05 > ulp err befr: = 0 > ulp err aftr: = 2 > > And with FMA we have the same results showed above. (super precise > cases, and maximum ULP error equal 2). > > So maybe update the patch with the following rules? >* If FMA is available, then compute 1 - x*x with it. >* If FMA is not available, then do the dijkstra substitution when |x| > > 0.5. So I think the runtime math libraries shoot for .5 ULP (yes, they don't always make it, but that's their goal). We should probably have the same goal. Going from 0 to 2 ULPs would be considered bad. So ideally we'd have some way to distinguish between the cases where we actually improve things (such as in your example). I don't know if that's possible. jeff
[Bug other/87695] New: Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 Bug ID: 87695 Summary: Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560. Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: mgruehs at gmx dot de Target Milestone: --- what does this message want to tell me? Arduino: 1.8.7 (Windows Store 1.8.15.0) (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)" C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\tools-builder -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -built-in-libraries C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\libraries -libraries C:\Users\SAMAMOFA\Documents\Arduino\libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -ide-version=10807 -build-path C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_build_439479 -warnings=none -build-cache C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_cache_930089 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -verbose C:\Users\SAMAMOFA\Documents\Arduino\Lokschuppen4Tore_Servo_Taster_LED\Lokschuppen4Tore_Servo_Taster_LED.ino C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\arduino-builder -compile -logger=machine -hardware C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\tools-builder -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -built-in-libraries C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\libraries -libraries C:\Users\SAMAMOFA\Documents\Arduino\libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -ide-version=10807 -build-path C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_build_439479 -warnings=none -build-cache C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_cache_930089 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -verbose C:\Users\SAMAMOFA\Documents\Arduino\Lokschuppen4Tore_Servo_Taster_LED\Lokschuppen4Tore_Servo_Taster_LED.ino Using board 'mega' from platform in folder: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\arduino\avr Using core 'arduino' from platform in folder: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\arduino\avr Detecting libraries used... "C:\\Program Files\\WindowsApps\\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\\hardware\\tools\\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=1600L -DARDUINO=10807 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR "-IC:\\Program
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Done.
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Mon Oct 22 20:01:56 2018 New Revision: 265397 URL: https://gcc.gnu.org/viewcvs?rev=265397=gcc=rev Log: PR testsuite/87694 * g++.dg/concepts/memfun-err.C: Make it a compile test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
[committed] Make g++.dg/concepts/memfun-err.C compile-only
This test checks compile-time errors, so there's no point in trying to
actually run it.
Committed as obvious.
2018-10-22 Marek Polacek
PR testsuite/87694
* g++.dg/concepts/memfun-err.C: Make it a compile test.
--- gcc/testsuite/g++.dg/concepts/memfun-err.C
+++ gcc/testsuite/g++.dg/concepts/memfun-err.C
@@ -1,4 +1,4 @@
-// { dg-do run { target c++17 } }
+// { dg-do compile { target c++17 } }
// { dg-options "-fconcepts" }
[Bug c++/55254] Warn for implicit conversion from int to char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254 --- Comment #3 from Eric Gallager --- Should this go under the existing -Wconversion or a new flag? If the latter, I'll make this block the new-warning meta-bug.
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 Eric Gallager changed: What|Removed |Added Blocks||87403 --- Comment #4 from Eric Gallager --- This warning would be new if added. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #11 from Eric Gallager --- (In reply to Martin Liška from comment #10) > Agree with Joseph, but it's a low priority on my list. It's kind of error > recovery and as soon you fix the first warning you should not see the second > one. I prefer fixing things in order of how difficult the fix is, and adding a second return (while pointless, redundant, and unnecessary) is often easier than tracking down where the code's original author declared the undeclared identifiers.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #5 from Jozef Lawrynowicz --- (In reply to Richard Biener from comment #4) Thanks for the pointers. > What happens if you make the attribute work for a MODE_INT union with a > MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode? > > Is there > a generic way to query SImode for PSImode as defined in > > PARTIAL_INT_MODE (SI, 20, PSI); > > ? Or does one need to compare MODE_SIZE? I believe you just have to compare MODE_SIZE as I did below. > Can there be multiple non-partial integer modes with the same size? Currently for the targets using PARTIAL_INT_MODE there is only a one-to-one mapping from the "full" mode to the partial mode. But where it can get tricky is when examining the BITSIZE of a partial int mode, as depending on the context, the bitsize could be the bitsize of the SI mode or the true bitsize of the PSImode i.e. the precision. I tried this (there may well be a neater way): diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index 4416b50..74f6a76 100644 --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -1280,7 +1280,11 @@ handle_transparent_union_attribute (tree *node, tree name, tree first = first_field (type); if (first == NULL_TREE || DECL_ARTIFICIAL (first) - || TYPE_MODE (type) != DECL_MODE (first)) + || (TYPE_MODE (type) != DECL_MODE (first) + && !(GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT + && GET_MODE_CLASS (DECL_MODE(first)) == MODE_PARTIAL_INT + && known_eq (GET_MODE_BITSIZE (TYPE_MODE (type)), + GET_MODE_BITSIZE (DECL_MODE (first)) goto ignored; } It fixes most of those failing DejaGNU tests, except pr34885.c ends up ICE-ing at "-O3 -g". during RTL pass: final^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c: In function 'send':^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c:9:1: internal compiler error: Segmentation fault^M 0xb58f4f crash_signal^M ../../gcc/toplev.c:325^M 0x7bf92d gen_subprogram_die^M ../../gcc/dwarf2out.c:23270^M 0x7c1c5b gen_decl_die^M ../../gcc/dwarf2out.c:26197^M 0x7c3f9e dwarf2out_decl^M ../../gcc/dwarf2out.c:26765^M 0x7d707e dwarf2out_function_decl^M ../../gcc/dwarf2out.c:26780^M 0x83e757 rest_of_handle_final^M ../../gcc/final.c:4681^M 0x83e757 execute^M ../../gcc/final.c:4723^M I haven't investigated the above ICE as the below alternative approach fixes the issue and offers codegen benefits. diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index 58a3aa3..6449f16 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -1844,10 +1844,15 @@ compute_record_mode (tree type) } /* If we only have one real field; use its mode if that mode's size - matches the type's size. This only applies to RECORD_TYPE. This - does not apply to unions. */ + matches the type's size. This generally only applies to RECORD_TYPE. + As an exception, if the union will be passed by reference then it is + acceptable to use the mode of the widest field for the mode of the + union. */ poly_uint64 type_size; - if (TREE_CODE (type) == RECORD_TYPE + if (((TREE_CODE (type) == RECORD_TYPE) + || (TREE_CODE (type) == UNION_TYPE + && targetm.calls.pass_by_reference (pack_cumulative_args (NULL), + mode, type, 0))) && mode != VOIDmode && poly_int_tree_p (TYPE_SIZE (type), _size) && known_eq (GET_MODE_BITSIZE (mode), type_size)) The codegen benefits are that the target might have instructions to specifically operate on the partial int mode, which it can use if the mode of the union is set to this partial int mode. So for msp430 if the widest type in a union is __int20 (PSImode), then allowing the union mode to be PSImode results in fewer instructions being used to manipulate the union, compared to if the union mode was SImode. I'll go ahead and test the second patch, unless there is a reason not to allow non-MODE_INT unions. If, for example, we'd rather not have unions be MODE_FLOAT I could always restrict the above logic further to only allow the union mode to be set to a MODE_PARTIAL_INT in addition to the currently allowable MODE_INT.
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-22 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Yes. It's a pre-existing thing, my recent patch didn't change that, but I'll fix it.
[Bug testsuite/87694] New: [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694
Bug ID: 87694
Summary: [9 regression] problem in g++.dg/concepts/memfun-err.C
starting with r263343
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
Shouldn't this test case be a dg-compile and not a dg-run given it is looking
for compilation errors?
// { dg-do run { target c++17 } }
// { dg-options "-fconcepts" }
UNSUPPORTED: g++.dg/concepts/memfun-err.C -std=gnu++98
UNSUPPORTED: g++.dg/concepts/memfun-err.C -std=gnu++14
Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++17 -fconcepts
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./memfun-err.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++17 -fconcepts
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./memfun-err.exe
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:27:8:
error: no declaration matches 'void S1::g2() requires (D)()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:23:10:
note: candidate is: 'void S1::g2() requires (C)()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:18:10:
note: 'struct S1' defined here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C: In
function 'int main()':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:34:9:
error: no matching function for call to 'S1::f1()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:19:10:
note: candidate: 'void S1::f1() requires (C)() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:19:10:
note: constraints not satisfied
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: within 'template concept bool C() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: 'int' is not a class
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:35:9:
error: no matching function for call to 'S1::g1()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:20:10:
note: candidate: 'void S1::g1() requires (C)() and true [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:20:10:
note: constraints not satisfied
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: within 'template concept bool C() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: 'int' is not a class
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:36:10:
error: no matching function for call to 'S1::h1(int)'
Kernel build cc1: error: code model kernel does not support 32 bit mode
Hello together, I dont know if i am on the right mailing list. When i build my custom kernel 4.19+ with gcc 9 (actual svn snapshot) i got the following Error: cc1: error: code model kernel does not support 32 bit. I use ubuntu 18.10 With gcc 8.2 no problems. Any suggestion for this problem ? Best regards Damian
Re: [PATCH] Fix PR 86572
On 10/22/2018 09:08 AM, Bernd Edlinger wrote: Hi! This makes c_strlen avoid an unsafe strlen folding of const arguments with non-const offset. Currently a negative out of bounds offset makes the strlen function return an extremely large number, and at the same time, prevents the VRP machinery, to determine the correct range if the strlen function in this case. Fixed by doing the whole computation in size_t and casting the result back to ssize_t. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? In general, I view folding to a "safe" value as done in this patch (and as Richard suggests in his comment on the bug) far preferable -- as in far safer/more secure -- to avoiding folding in these cases (currently the prevailing strategy). If there is consensus on adopting this approach for strlen I'd like to see it applied in other such cases as well as a matter of policy. Some other similar examples to consider include: * calling other built-ins on such arrays, including strnlen, memchr/strchr, and strpbrk * indexing into such an array (note that accesses at constant out-of-bounds indices into constant arrays are already folded to zero, although that may be an accidental rather than a conscious decision made to avoid the worst kind of fallout). None of these is currently folded to a safe value. GCC calls the library functions for the built-ins in the first bullet when the argument is a constant string with a non-constant offset, even though it could fold them. At some point it would be also helpful to try to get consensus on whether emitting a trap in these cases (perhaps under an option) is something to start moving toward, as we discussed at Cauldron. Martin
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #14 from coypu --- Also, after these two patches, my own build of arm--netbsdelf is failing from this: configure: error: Pthreads are required to build libgomp Looking at config.log, the error is actually: configure:15118: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/ -B/usr/local/arm--netbsdelf/bin/ -B/usr/local/arm--netbsdelf/lib/ -isystem /usr/local/arm--netbsdelf/include -isystem /usr/local/arm--netbsdelf/sys-include --sysroot=/home/fly/shark/destdir.shark/ -o conftest -g -O2 conftest.c -lpthread >&5 /home/fly/shark/destdir.shark/usr/lib/libpthread.so: undefined reference to `__modsi3@GCC_3.0' collect2: error: ld returned 1 exit status I'm not sure what is the cause of that.
[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627 --- Comment #5 from Alexander Monakov --- I've spent some time looking at this again, and I couldn't find a way to preserve REG_EQUIV notes (it's actually unclear what REG_EQUIV means precisely). What I think could help in simple cases like this one, and might also be helpful in other situations, is to have mem_attrs indicate that memory does not escape. RTL CSE would not need to invalidate such MEMs when processing a call.
[PATCH, rs6000] Don't use deprecated __vector long in intrinsic compatibility headers
Hi,
We should never use __vector long in the intrinsics compatibility headers,
since this has different meanings on 32- and 64-bit targets. This patch
corrects a number of places where this previously slipped through.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2018-10-22 Bill Schmidt
Jinsong Ji
* config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Change deprecated
__vector long to __vector long long.
(_mm_cvtpd_ps): Likewise.
(_mm_cvttpd_epi32): Likewise.
(_mm_cvtpi32_pd): Likewise.
(_mm_unpackhi_epi64): Likewise.
(_mm_unpacklo_epi64): Likewise.
Index: gcc/config/rs6000/emmintrin.h
===
--- gcc/config/rs6000/emmintrin.h (revision 265389)
+++ gcc/config/rs6000/emmintrin.h (working copy)
@@ -888,7 +888,8 @@ _mm_cvtpd_epi32 (__m128d __A)
#ifdef _ARCH_PWR8
temp = vec_mergeo (temp, temp);
- result = (__v4si)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
+ result = (__v4si)vec_vpkudum ((__vector long long)temp,
+ (__vector long long)vzero);
#else
{
const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
@@ -922,7 +923,8 @@ _mm_cvtpd_ps (__m128d __A)
#ifdef _ARCH_PWR8
temp = vec_mergeo (temp, temp);
- result = (__v4sf)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
+ result = (__v4sf)vec_vpkudum ((__vector long long)temp,
+ (__vector long long)vzero);
#else
{
const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
@@ -950,7 +952,8 @@ _mm_cvttpd_epi32 (__m128d __A)
#ifdef _ARCH_PWR8
temp = vec_mergeo (temp, temp);
- result = (__v4si)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
+ result = (__v4si)vec_vpkudum ((__vector long long)temp,
+ (__vector long long)vzero);
#else
{
const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
@@ -986,7 +989,7 @@ _mm_cvtpi32_pd (__m64 __A)
temp = (__v4si)vec_splats (__A);
tmp2 = (__v2di)vec_unpackl (temp);
- result = vec_ctf ((__vector signed long)tmp2, 0);
+ result = vec_ctf ((__vector signed long long)tmp2, 0);
return (__m128d)result;
}
#endif
@@ -1289,7 +1292,8 @@ _mm_unpackhi_epi32 (__m128i __A, __m128i __B)
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_unpackhi_epi64 (__m128i __A, __m128i __B)
{
- return (__m128i) vec_mergel ((__vector long)__A, (__vector long)__B);
+ return (__m128i) vec_mergel ((__vector long long)__A,
+ (__vector long long)__B);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
@@ -1313,7 +1317,8 @@ _mm_unpacklo_epi32 (__m128i __A, __m128i __B)
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_unpacklo_epi64 (__m128i __A, __m128i __B)
{
- return (__m128i) vec_mergeh ((__vector long)__A, (__vector long)__B);
+ return (__m128i) vec_mergeh ((__vector long long)__A,
+ (__vector long long)__B);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
[PATCH, rs6000] Use explicit casts for vec_sel argument 3 in intrinsic headers
Hi,
The vec_sel intrinsic is overloaded for multiple types. There are a
couple of cases in our intrinsic compatibility headers where the types
used don't match any allowable type signature. GCC is able to correctly
infer which matching built-in function is meant, but not all compilers
can. For compatibility, cast the third parameter correctly in the
source code.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2018-10-22 Bill Schmidt
Jinsong Ji
* config/rs6000/emmintrin.h (_mm_sll_epi64): Explicitly cast third
argument of vec_sel to vector unsigned long long.
* config/rs6000/xmmintrin.h (_mm_min_ps): Explicitly cast third
argument of vec_sel to vector unsigned int.
Index: gcc/config/rs6000/emmintrin.h
===
--- gcc/config/rs6000/emmintrin.h (revision 265389)
+++ gcc/config/rs6000/emmintrin.h (working copy)
@@ -1766,7 +1766,7 @@ _mm_sll_epi64 (__m128i __A, __m128i __B)
shmask = lshift < shmax;
result = vec_vsld ((__v2du) __A, lshift);
result = (__v2du) vec_sel ((__v2df) shmask, (__v2df) result,
- (__v2df) shmask);
+(vector unsigned long long) shmask);
return (__m128i) result;
}
Index: gcc/config/rs6000/xmmintrin.h
===
--- gcc/config/rs6000/xmmintrin.h (revision 265389)
+++ gcc/config/rs6000/xmmintrin.h (working copy)
@@ -458,7 +458,7 @@ extern __inline __m128 __attribute__((__gnu_inline
_mm_min_ps (__m128 __A, __m128 __B)
{
__m128 m = (__m128) vec_vcmpgtfp ((__v4sf) __B, (__v4sf) __A);
- return vec_sel (__B, __A, m);
+ return vec_sel (__B, __A, (vector unsigned int)m);
}
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
[PATCH, rs6000 2/2] Add compatible implementations of x86 SSSE3 intrinsics
Target tests for the intrinsics defined in pmmintrin.h, copied from
gcc.target/i386.
Tested on POWER8 ppc64le and ppc64 (-m64 and -m32, the latter only reporting
16 new unsupported tests), and also by forcing -mcpu=power7 on ppc64.
[gcc/testsuite]
2018-10-22 Paul A. Clarke
* gcc.target/powerpc/sse3-check.h: New file.
* gcc.target/powerpc/ssse3-vals.h: New file.
* gcc.target/powerpc/ssse3-pabsb.c: New file.
* gcc.target/powerpc/ssse3-pabsd.c: New file.
* gcc.target/powerpc/ssse3-pabsw.c: New file.
* gcc.target/powerpc/ssse3-palignr.c: New file.
* gcc.target/powerpc/ssse3-phaddd.c: New file.
* gcc.target/powerpc/ssse3-phaddsw.c: New file.
* gcc.target/powerpc/ssse3-phaddw.c: New file.
* gcc.target/powerpc/ssse3-phsubd.c: New file.
* gcc.target/powerpc/ssse3-phsubsw.c: New file.
* gcc.target/powerpc/ssse3-phsubw.c: New file.
* gcc.target/powerpc/ssse3-pmaddubsw.c: New file.
* gcc.target/powerpc/ssse3-pmulhrsw.c: New file.
* gcc.target/powerpc/ssse3-pshufb.c: New file.
* gcc.target/powerpc/ssse3-psignb.c: New file.
* gcc.target/powerpc/ssse3-psignd.c: New file.
* gcc.target/powerpc/ssse3-psignw.c: New file.
Index: gcc/testsuite/gcc.target/powerpc/ssse3-check.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-check.h
b/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-check.h
new file mode 10644
--- /dev/null (revision 0)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-check.h (working copy)
@@ -0,0 +1,43 @@
+#include
+#include
+
+#include "m128-check.h"
+
+/* define DEBUG replace abort with printf on error. */
+//#define DEBUG 1
+
+#define TEST ssse3_test
+
+static void ssse3_test (void);
+
+static void
+__attribute__ ((noinline))
+do_test (void)
+{
+ ssse3_test ();
+}
+
+int
+main ()
+{
+#ifdef __BUILTIN_CPU_SUPPORTS__
+ /* Most SSE intrinsic operations can be implemented via VMX
+ instructions, but some operations may be faster / simpler
+ using the POWER8 VSX instructions. This is especially true
+ when we are transferring / converting to / from __m64 types.
+ The direct register transfer instructions from POWER8 are
+ especially important. So we test for arch_2_07. */
+ if (__builtin_cpu_supports ("arch_2_07"))
+{
+ do_test ();
+#ifdef DEBUG
+ printf ("PASSED\n");
+#endif
+}
+#ifdef DEBUG
+ else
+printf ("SKIPPED\n");
+#endif
+#endif /* __BUILTIN_CPU_SUPPORTS__ */
+ return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/ssse3-vals.h
===
diff --git a/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-vals.h
b/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-vals.h
new file mode 10644
--- /dev/null (revision 0)
+++ b/trunk/gcc/testsuite/gcc.target/powerpc/ssse3-vals.h (working copy)
@@ -0,0 +1,60 @@
+/* Routine to check correctness of the results */
+static int
+chk_128 (int *v1, int *v2)
+{
+ int i;
+ int n_fails = 0;
+
+ for (i = 0; i < 4; i++)
+if (v1[i] != v2[i])
+ n_fails += 1;
+
+ return n_fails;
+}
+
+static int vals [256] __attribute__ ((aligned(16))) =
+{
+ 0x, 0x, 0x, 0x, 0x5be800ee, 0x4f2d7b15,
+ 0x409d9291, 0xdd95f27f, 0x423986e3, 0x21a4d2cd, 0xa7056d84, 0x4f4e5a3b,
+ 0x, 0x, 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x, 0x, 0x,
+ 0x73ef0244, 0xcd836329, 0x847f634f, 0xa7e3abcf, 0xb4c14764, 0x1ef42c06,
+ 0x504f29ac, 0x4ae7ca73, 0xaddde3c9, 0xf63ded2e, 0xa5d3553d, 0xa52ae05f,
+ 0x6fd3c83a, 0x7dc2b300, 0x76b05de7, 0xea8ebae5, 0x549568dd, 0x172f0358,
+ 0x917eadf0, 0x796fb0a7, 0xb39381af, 0xd0591d61, 0x731d2f17, 0xbc4b6f5d,
+ 0x8ec664c2, 0x3c199c19, 0x9c81db12, 0x6d85913b, 0x486107a9, 0xab6f4b26,
+ 0x5630d37c, 0x20836e85, 0x40d4e746, 0xdfbaba36, 0xbeacaa69, 0xb3c84083,
+ 0x8a688eb4, 0x08cde481, 0x66e7a190, 0x74ee1639, 0xb3942a19, 0xe0c40471,
+ 0x9b789489, 0x9751207a, 0x543a1524, 0x41da7ad6, 0x614bb563, 0xf86f57b1,
+ 0x69e62199, 0x2150cb12, 0x9ed74062, 0x429471f4, 0xad28502b, 0xf2e2d4d5,
+ 0x45b6ce09, 0xaaa5e649, 0xb46da484, 0x0a637515, 0xae7a3212, 0x5afc784c,
+ 0x776cfbbe, 0x9c542bb2, 0x64193aa8, 0x16e8a655, 0x4e3d2f92, 0xe05d7b72,
+ 0x89854ebc, 0x8c318814, 0xb81e76e0, 0x3f2625f5, 0x61b44852, 0x5209d7ad,
+ 0x842fe317, 0xd3cfcca1, 0x8d287cc7, 0x80f0c9a8, 0x4215f4e5, 0x563993d6,
+ 0x5d627433, 0xc4449e35, 0x5b4fe009, 0x3ef92286, 0xacbc8927, 0x549ab870,
+ 0x9ac5b959, 0xed8f1c91, 0x7ecf02cd, 0x989c0e8b, 0xa31d6918, 0x1dc2bcc1,
+ 0x99d3f3cc, 0x6857acc8, 0x45d7324a, 0xaebdf2e6, 0x7af2f2ae, 0x09716f73,
+ 0x7816e694, 0xc65493c0, 0x9f7e87bc, 0xaa96cd40, 0xbfb5bfc6, 0x01a2cce7,
+ 0x5f1d8c46, 0x45303efb, 0xb24607c3, 0xef2009a7, 0xba873753, 0xbefb14bc,
+ 0x74e53cd3, 0x70124708, 0x6eb4bdbd, 0xf3ba5e43, 0x4c94085f,
[PATCH, rs6000 1/2] Add compatible implementations of x86 SSSE3 intrinsics
This is a follow-on to earlier commits for adding compatibility
implementations of x86 intrinsics for PPC64LE. This patch adds
the 32 x86 intrinsics from ("SSSE3").
(Patch 2/2 adds tests for these intrinsics, and briefly describes
the tests performed.)
./gcc/ChangeLog:
2018-10-22 Paul A. Clarke
* config/rs6000/tmmintrin.h: New file.
* config.gcc (powerpc*-*-*): Add tmmintrin.h to extra_headers.
Index: gcc/config/rs6000/tmmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/tmmintrin.h
b/trunk/gcc/config/rs6000/tmmintrin.h
new file mode 10644
--- /dev/null (revision 0)
+++ b/trunk/gcc/config/rs6000/tmmintrin.h (working copy)
@@ -0,0 +1,460 @@
+/* Copyright (C) 2003-2018 Free Software Foundation, Inc.
+
+ This file is part of GCC.
+
+ GCC 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.
+
+ GCC 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
+
Re: [PATCH] Default to an ARM cpu that exists
On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
> I think strongarm would be a better choice. I'm not aware of anyone
> running NetBSD on Arm8 cpus.
>
> Otherwise, this is fine with a suitable ChangeLog entry.
>
> R.
I hope this is OK. Thanks!
Maya Rashish
PR target/86383
* config.gcc (arm*-*-*): Change default -mcpu to strongarm.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 720e6a737..23e2e85c8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3987,7 +3987,7 @@ case "${target}" in
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi
- target_cpu_cname=${target_cpu_cname:-arm6}
+ target_cpu_cname=${target_cpu_cname:-strongarm}
with_cpu=${with_cpu:-$target_cpu_cname}
;;
Re: [PATCH] add simple attribute introspection
Jason,
Do you have any suggestions for the C++ parts or are they good
enough to commit (with the expectation that I'll add template
handling later)?
The last patch is here:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00811.html
Martin
On 10/16/2018 05:19 PM, Jeff Law wrote:
On 10/13/18 6:19 PM, Martin Sebor wrote:
Attached is an updated/enhanced patch with many more tests
and the suggested documentation tweak. It also restores
the handling of empty attributes that the first revision
inadvertently removed from the C parser.
The tests are much more comprehensive now but still not
exhaustive. I have added warning for the mode attribute
that cannot be supported. Enumerator attributes aren't
detected in C because they are folded to constants before
they reach the built-in, and label attributes aren't handled
yet either in C or in C++. Supporting those will take a minor
enhancement. I haven only added handful of test cases for
x86_64 target attributes, The built-in is not exercised
for any other target yet. I don't expect any surprises
there. Either it will work or (where the attributes aren't
hanging off a node) it will return false. Supporting those
will have to wait until the later (I think the best way is
to add a callback to struct attribute_spec to let each back
end query a node for the properties unique to such attributes
analogously to attribute vector_size).
I haven't done any work on supporting templates. I would
like to but I don't expect to be able to get it done before
stage 1 is over (I have another feature I need to finish,
the one that prompted this work to begin with). I think
the new built-in is quite useful even without template
support.
I've kept the name __builtin_has_attribute: it is close to
the __has_attribute macro, and I think that's fine because
the built-in's purpose is very close to that of the macro.
Martin
gcc-builtin-has-attribute.diff
gcc/c/ChangeLog:
* c-parser.c (c_parser_has_attribute_expression): New function.
(c_parser_attribute): New function.
(c_parser_attributes): Move code into c_parser_attribute.
(c_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
gcc/c-family/ChangeLog:
* c-attribs.c (type_for_vector_size): New function.
(type_valid_for_vector_size): Same.
(handle_vector_size_attribute): Move code to the functions above
and call them.
(validate_attribute, has_attribute): New functions.
* c-common.h (has_attribute): Declare.
(rid): Add RID_HAS_ATTRIBUTE_EXPRESSION.
* c-common.c (c_common_resword): Same.
gcc/cp/ChangeLog:
* cp-tree.h (cp_check_const_attributes): Declare.
* decl2.c (cp_check_const_attributes): Declare extern.
* parser.c (cp_parser_has_attribute_expression): New function.
(cp_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
(cp_parser_gnu_attribute_list): Add argument.
gcc/ChangeLog:
* doc/extend.texi (Other Builtins): Add __builtin_has_attribute.
gcc/testsuite/ChangeLog:
* c-c++-common/builtin-has-attribute-2.c: New test.
* c-c++-common/builtin-has-attribute-3.c: New test.
* c-c++-common/builtin-has-attribute-4.c: New test.
* c-c++-common/builtin-has-attribute.c: New test.
* gcc.dg/builtin-has-attribute.c: New test.
* gcc/testsuite/gcc.target/i386/builtin-has-attribute.c: New test.
Generally looks OK except for a nit mentioned below. I don't mind
iterating a bit on the details here over time. Give Jason a few days to
chime in on the C++ side.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8ffb0cd..dcf4747 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2649,8 +2649,9 @@ explicit @code{externally_visible} attributes are still
necessary.
@cindex @code{flatten} function attribute
Generally, inlining into a function is limited. For a function marked with
this attribute, every call inside this function is inlined, if possible.
-Whether the function itself is considered for inlining depends on its size and
-the current inlining parameters.
+Functions declared with attribute @code{noinline} and similar are not
+inlined. Whether the function itself is considered for inlining depends
+on its size and the current inlining parameters.
Guessing this was from another doc patch that I think has already been
approved :-)
@@ -11726,6 +11728,33 @@ check its compatibility with @var{size}.
@end deftypefn
+@deftypefn {Built-in Function} bool __builtin_has_attribute
(@var{type-or-expression}, @var{attribute})
+The @code{__builtin_has_attribute} function evaluates to an integer constant
+expression equal to @code{true} if the symbol or type referenced by
+the @var{type-or-expression} argument has been declared with
+the @var{attribute} referenced by the second argument. Neither argument
+is valuated. The @var{type-or-expression} argument is subject to the same
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
Hi Rainer,
On 10/9/18 3:05 PM, Rainer Orth wrote:
> Hi Bernd,
>
>>> * The merge-all-constants-2.c test doesn't FAIL on Solaris/SPARC with
>>> /bin/as, although it lacks string merging support, too. The assembler
>>> output contains
>>>
>>> .section".rodata"
>>>
>>> so the pattern currently used to check for .rodata is too
>>> restrictive. There is assembler syntax beyond gas on x86 ;-)
>>>
>>
>> For the test that failed with the quotes around .rodata. I think
>> instead of looking for a end of line immediately after .rodata, it
>> would be sufficient to make sure it does not continue with .str, so
>> could you please try to add something like the following to your patch?
>>
>> Index: gcc/testsuite/gcc.dg/merge-all-constants-2.c
>> ===
>> --- gcc/testsuite/gcc.dg/merge-all-constants-2.c (revision 264888)
>> +++ gcc/testsuite/gcc.dg/merge-all-constants-2.c (working copy)
>> @@ -5,4 +5,4 @@
>>const char str2[37] = "0123456789abcdefghijklmnopqrstuvwxyz";
>>const char str3[10] = "0123456789abcdefghijklmnopqrstuvwxyz";
>>
>> -/* { dg-final { scan-assembler-not "\\.rodata\[\n\r\]" } } */
>> +/* { dg-final { scan-assembler-not "\\.rodata\[^.]" } } */
>
> to do this; I've temporarily disabled the string_merging requirement in
> the test and ran it on sparc-sun-solaris2.11:
>
> * With as (no string merging), there's
>
> .section".rodata"
>
>in the output and I get the expected
>
> FAIL: gcc.dg/merge-all-constants-2.c scan-assembler-not \\.rodata[^.]
>
> * With gas however (string merging supported), the output has the usual
>
> .section.rodata.str1.8,"aMS",@progbits,1
>
>and the test PASSes.
>
which is okay, right?
Bernd.
[Bug c/87693] New: ICE in thread_around_empty_blocks, at tree-ssa-threadedge.c:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87693
Bug ID: 87693
Summary: ICE in thread_around_empty_blocks, at
tree-ssa-threadedge.c:984
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc 5, at -O[s123] :
$ cat z1.c
void f (void);
void g (void);
void h (int a)
{
void *p, **q;
if (a)
p = (void *)f;
else
p = (void *)g;
q = (void *)p;
if (*q == (void *)0)
goto *p;
L0:
return;
}
$ gcc-9-20181021 -c z1.c
$
$ gcc-9-20181021 -c z1.c -O2
during GIMPLE pass: vrp
z1.c: In function 'h':
z1.c:3:6: internal compiler error: Segmentation fault
3 | void h (int a)
| ^
0xa6de1f crash_signal
../../gcc/toplev.c:325
0xc0c3cc thread_around_empty_blocks
../../gcc/tree-ssa-threadedge.c:984
0xc0e010 thread_across_edge
../../gcc/tree-ssa-threadedge.c:1302
0xc0e945 thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, evrp_range_analyzer*, tree_node* (*)(gimple*, gimple*,
avail_exprs_stack*, basic_block_def*))
../../gcc/tree-ssa-threadedge.c:1376
0xc81428 vrp_dom_walker::after_dom_children(basic_block_def*)
../../gcc/tree-vrp.c:6508
0x113d094 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:395
0xc92e9b identify_jump_threads
../../gcc/tree-vrp.c:6563
0xc92e9b execute_vrp
../../gcc/tree-vrp.c:6699
[Bug fortran/53653] [IR Tracking] Disallow abstract/unlimited-polymorphic types in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53653 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G. Steinmetz --- Some reductions : $ cat z1.f90 program p type, abstract :: t end type class(t), allocatable :: x, z(:) allocate (z(1), source=[x]) end $ cat z2.f90 program p type t end type class(t), allocatable :: x, z(:) allocate (z(1), source=[x]) end $ gfortran-9-20181021 -c z2.f90 z2.f90:5:0: 5 |allocate (z(1), source=[x]) | internal compiler error: Segmentation fault 0xb1c86f crash_signal ../../gcc/toplev.c:325 0x5fc806 gfc_add_component_ref(gfc_expr*, char const*) ../../gcc/fortran/class.c:211 0x72dbb7 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6048 0x6bdb27 trans_code ../../gcc/fortran/trans.c:1990 0x6e51c4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6505 0x673426 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x673426 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6ba3ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/50974] ICE on invalid on function used as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- Update : No ICE with a release version 9 to 5, but when configured with --enable-checking=yes. $ cat z1.f90 program p contains real function f() f = g end real function g() end end $ gfortran-9-20181021 -c z1.f90 $ $ gfortran-9-20181021-chk -c z1.f90 z1.f90:3:0: 3 |real function f() | Error: invalid types in conversion to floating point real(kind=4) real(kind=4) (*) (void) _1 = (real(kind=4)) g; z1.f90:3:0: internal compiler error: verify_gimple failed 0xcb79bd verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5082 0x9e9b55 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:12859 0x9e9e44 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:12949 0xd20abf gimplify_all_functions ../../gcc/tree-nested.c:3405 0xd20aaf gimplify_all_functions ../../gcc/tree-nested.c:3408 0xd2a4ee lower_nested_functions(tree_node*) ../../gcc/tree-nested.c:3425 0x827310 cgraph_node::analyze() ../../gcc/cgraphunit.c:673 0x82a799 analyze_functions ../../gcc/cgraphunit.c:1126 0x82b892 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2833
Re: [PATCH 4/6] [ARC] Add peephole rules to combine store/loads into double store/loads
* Claudiu Zissulescu [2018-10-10 11:00:14 +0300]:
> Simple peephole rules which combines multiple ld/st instructions into
> 64-bit load/store instructions. It only works for architectures which
> are having double load/store option on.
>
> gcc/
> Claudiu Zissulescu
>
> * config/arc/arc-protos.h (gen_operands_ldd_std): Add.
> * config/arc/arc.c (operands_ok_ldd_std): New function.
> (mem_ok_for_ldd_std): Likewise.
> (gen_operands_ldd_std): Likewise.
> * config/arc/arc.md: Add peephole2 rules for std/ldd.
> ---
> gcc/config/arc/arc-protos.h | 1 +
> gcc/config/arc/arc.c| 163
> gcc/config/arc/arc.md | 67 +++
> 3 files changed, 231 insertions(+)
>
> diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
> index 24bea6e1efb..55f8ed4c643 100644
> --- a/gcc/config/arc/arc-protos.h
> +++ b/gcc/config/arc/arc-protos.h
> @@ -46,6 +46,7 @@ extern int arc_return_address_register (unsigned int);
> extern unsigned int arc_compute_function_type (struct function *);
> extern bool arc_is_uncached_mem_p (rtx);
> extern bool arc_lra_p (void);
> +extern bool gen_operands_ldd_std (rtx *operands, bool load, bool commute);
> #endif /* RTX_CODE */
>
> extern unsigned int arc_compute_frame_size (int);
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 18dd0de6af7..9bc69e9fbc9 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -10803,6 +10803,169 @@ arc_cannot_substitute_mem_equiv_p (rtx)
>return true;
> }
>
> +/* Checks whether the operands are valid for use in an LDD/STD
> + instruction. Assumes that RT, RT2, and RN are REG. This is
> + guaranteed by the patterns. Assumes that the address in the base
> + register RN is word aligned. Pattern guarantees that both memory
> + accesses use the same base register, the offsets are constants
> + within the range, and the gap between the offsets is 4. If preload
> + complete then check that registers are legal. WBACK indicates
> + whether address is updated. */
You've got tabs instead of whitespace inside both this comment block,
and others within this patch. It should be period and two whitespace
at the end of each sentence.
> +
> +static bool
> +operands_ok_ldd_std (rtx rt, rtx rt2, rtx rn ATTRIBUTE_UNUSED,
> + HOST_WIDE_INT offset)
Why have the RN parameter at all? I took a quick look through patches
5/6 and don't see any additional changes to this function, we should
probably just drop this at this point.
> +{
> + unsigned int t, t2;
> +
> + if (!reload_completed)
> +return true;
> +
> + if (!(SMALL_INT_RANGE (offset, (GET_MODE_SIZE (DImode) - 1) & -4,
Couldn't we use (~0x3) instead of -4? Maybe I'm just feeling slow
today, but the bit pattern for negative numbers don't just pop into my
head like those for positive numbers.
> + (offset & (GET_MODE_SIZE (DImode) - 1) & 3
> + ? 0 : -(-GET_MODE_SIZE (DImode) | -4) >> 1
> +return false;
> +
> + t = REGNO (rt);
> + t2 = REGNO (rt2);
> +
> + if ((t2 == 63)
Can we use PROGRAM_COUNTER_REGNO here?
> + || (t % 2 != 0)/* First destination register is not even. */
> + || (t2 != t + 1))
> + return false;
> +
> + return true;
> +}
> +
> +/* Helper for gen_operands_ldd_std. Returns true iff the memory
> + operand MEM's address contains an immediate offset from the base
> + register and has no side effects, in which case it sets BASE and
> + OFFSET accordingly. */
> +
> +static bool
> +mem_ok_for_ldd_std (rtx mem, rtx *base, rtx *offset)
> +{
> + rtx addr;
> +
> + gcc_assert (base != NULL && offset != NULL);
> +
> + /* TODO: Handle more general memory operand patterns, such as
> + PRE_DEC and PRE_INC. */
> +
> + if (side_effects_p (mem))
> +return false;
> +
> + /* Can't deal with subregs. */
> + if (GET_CODE (mem) == SUBREG)
> +return false;
> +
> + gcc_assert (MEM_P (mem));
> +
> + *offset = const0_rtx;
> +
> + addr = XEXP (mem, 0);
> +
> + /* If addr isn't valid for DImode, then we can't handle it. */
> + if (!arc_legitimate_address_p (DImode, addr,
> + reload_in_progress || reload_completed))
> +return false;
> +
> + if (REG_P (addr))
> +{
> + *base = addr;
> + return true;
> +}
> + else if (GET_CODE (addr) == PLUS || GET_CODE (addr) == MINUS)
> +{
> + *base = XEXP (addr, 0);
> + *offset = XEXP (addr, 1);
> + return (REG_P (*base) && CONST_INT_P (*offset));
> +}
> +
> + return false;
> +}
> +
> +/* Called from peephole2 to replace two word-size accesses with a
> + single LDD/STD instruction. Returns true iff we can generate a new
> + instruction sequence. That is, both accesses use the same base
> + register and the gap between constant offsets is 4. OPERANDS are
> + the operands found
Re: [PATCH 5/6] [ARC] Refurbish and improve prologue/epilogue functions.
* Claudiu Zissulescu [2018-10-10 11:00:15 +0300]:
> Reimplement how prologue and epilogue is emitted to accomodate
> enter/leave instructions, as well as improving the size of the
> existing techinques.
>
> The following modifications are added:
>
> - millicode thunk calls can be now selected regardless of the
> optimization level. However they are enabled for size optimizations
> by default. Also, the millicode optimization is turned off when we
> compile for long jumps.
>
> - the compiler is able to use enter/leave instructions for prologue
> and epilogue. As these instructions are not ABI compatible we gurad
> them under a switch (i.e., -mcode-density-frame). When this option
> is on, the compiler will try emitting enter/leave instructions, if
> not, then millicode thunk calls (if enabled), and latter the regular
> push/pop instructions.
>
> - The prologue/epilogue is now optimized to use pointer walks, hence
> improving the chance to have push_s/pop_s instructions emitted. It
> also tries to combine the stack adjustments with load/store
> operations.
>
> gcc/
> x-xx-xx Claudiu Zissulescu
>
> * common/config/arc/arc-common.c (arc_option_optimization_table):
> Millicode optimization is default on for size optimizations.
> * config/arc/arc-protos.h (arc_check_multi): New function.
> * config/arc/arc.c (RTX_OK_FOR_OFFSET_P): Rearange.
> (arc_override_options): Disable millicode when long calls option
> is on.
> (arc_frame_info): Change it from int to bool.
> (arc_compute_frame_size): Clean up.
> (arc_save_restore): Remove.
> (frame_save_reg): New function.
> (frame_restore_reg): Likewise.
> (arc_enter_leave_p): Likewise.
> (arc_save_callee_saves): Likewise.
> (arc_restore_callee_saves): Likewise.
> (arc_save_callee_enter): Likewise.
> (arc_restore_callee_leave): Likewise.
> (arc_save_callee_milli): Likewise.
> (arc_restore_callee_milli): Likewise.
> (arc_expand_prologue): Reimplement to emit enter/leave
> instructions.
> (arc_expand_epilogue): Likewise.
> (arc_check_multi): New function.
> * config/arc/arc.md (push_multi_fp): New pattern.
> (push_multi_fp_blink): Likewise.
> (pop_multi_fp): Likewise.
> (pop_multi_fp_blink): Likewise.
> (pop_multi_fp_ret): Likewise.
> (pop_multi_fp_blink_ret): Likewise.
> * config/arc/arc.opt (mmillicode): Update option.
> (mcode-density-frame): New option.
> * config/arc/predicates.md (push_multi_operand): New predicate.
> (pop_multi_operand): Likewise.
> * doc/invoke.texi (ARC): Update ARC options information.
>
> gcc/testsuite
> x-xx-xx Claudiu Zissulescu
>
> * gcc.target/arc/firq-1.c: Update test.
> * gcc.target/arc/firq-3.c: Likewise.
> * gcc.target/arc/firq-4.c: Likewise.
> * gcc.target/arc/interrupt-6.c: Likewise.
In principle this is fine. There's missing comments, and magic
constants, and other miscellaneous formatting issues throughout the
patch.
I ran out of steam about half way through arc.c but you'll see the
pattern by then :)
Thanks
Andrew
> ---
> gcc/common/config/arc/arc-common.c |1 +
> gcc/config/arc/arc-protos.h|1 +
> gcc/config/arc/arc.c | 1266 +---
> gcc/config/arc/arc.md | 172 +++
> gcc/config/arc/arc.opt | 10 +-
> gcc/config/arc/predicates.md | 12 +
> gcc/doc/invoke.texi| 18 +-
> gcc/testsuite/gcc.target/arc/firq-1.c |8 +-
> gcc/testsuite/gcc.target/arc/firq-3.c | 14 +-
> gcc/testsuite/gcc.target/arc/firq-4.c | 12 +-
> gcc/testsuite/gcc.target/arc/interrupt-6.c |2 +-
> 11 files changed, 1054 insertions(+), 462 deletions(-)
>
> diff --git a/gcc/common/config/arc/arc-common.c
> b/gcc/common/config/arc/arc-common.c
> index 578431a279d..2872388de2c 100644
> --- a/gcc/common/config/arc/arc-common.c
> +++ b/gcc/common/config/arc/arc-common.c
> @@ -59,6 +59,7 @@ static const struct default_options
> arc_option_optimization_table[] =
> { OPT_LEVELS_SIZE, OPT_mq_class, NULL, 1 },
> { OPT_LEVELS_SIZE, OPT_mcase_vector_pcrel, NULL, 1 },
> { OPT_LEVELS_SIZE, OPT_msize_level_, NULL, 3 },
> +{ OPT_LEVELS_SIZE, OPT_mmillicode, NULL, 1 },
> { OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
> { OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_msize_level_, NULL, 0 },
> { OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_malign_call, NULL, 1 },
> diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
> index 55f8ed4c643..6450b6a014e 100644
> --- a/gcc/config/arc/arc-protos.h
> +++ b/gcc/config/arc/arc-protos.h
> @@ -47,6 +47,7 @@ extern unsigned int arc_compute_function_type (struct
> function *);
> extern bool arc_is_uncached_mem_p (rtx);
> extern bool arc_lra_p (void);
>
[Bug middle-end/87692] New: Reuse guard variable for multiple initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87692
Bug ID: 87692
Summary: Reuse guard variable for multiple initializations
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
int produce1();
int produce2(int ) noexcept;
auto test() {
static int val1 = produce1();
static int val2 = produce2(val1); // noexcept
return val2 + val2;
}
For the above example two guard variables are generated: for `val1` and `val2`.
However the `val2` initialization always succeeds and may not happen before
`val1` initialization.
So instead of having two variables, `val2` could reuse the guard variable for
`val1`.
Using one variable has advantages: less code is generated and no need in
multiple guard variables checks.
Such optimization will reduce the code size and improve overall performance.
"match.pd" (was: Can support TRUNC_DIV_EXPR, TRUNC_MOD_EXPR in GCC vectorization/scalar evolution -- and/or linearization?)
Hi!
Thanks for all your comments already! I continued looked into this for a
bit (but then got interrupted by a higher-priority task). Regarding this
one specifically:
On Fri, 12 Oct 2018 21:14:11 +0200, Marc Glisse wrote:
> On Fri, 12 Oct 2018, Thomas Schwinge wrote:
>
> > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > also present when running the following code through the vectorizer:
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > {
> >int j = tmp / N_I;
> >int i = tmp % N_I;
> >a[j][i] = 0;
> > }
> >
> > ... whereas the following variant (obviously) does vectorize:
> >
> >int a[NJ * NI];
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > a[tmp] = 0;
>
> I had a quick look at the difference, and a[j][i] remains in this form
> throughout optimization. If I write instead *((*(a+j))+i) = 0; I get
>
>j_10 = tmp_17 / 1025;
>i_11 = tmp_17 % 1025;
>_1 = (long unsigned int) j_10;
>_2 = _1 * 1025;
>_3 = (sizetype) i_11;
>_4 = _2 + _3;
>
> or for a power of 2
>
>j_10 = tmp_17 >> 10;
>i_11 = tmp_17 & 1023;
>_1 = (long unsigned int) j_10;
>_2 = _1 * 1024;
>_3 = (sizetype) i_11;
>_4 = _2 + _3;
>
> and in both cases we fail to notice that _4 = (sizetype) tmp_17; (at least
> I think that's true).
>
> So there are missing match.pd transformations in addition to whatever
> scev/ivdep/other work is needed.
With a very simplistic "match.pd" rule (not yet any special cases
checking etc.):
diff --git gcc/match.pd gcc/match.pd
index b36d7ccb5dc3..4c23116308da 100644
--- gcc/match.pd
+++ gcc/match.pd
@@ -5126,3 +5126,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ wide_int_to_tree (sizetype, off); })
{ swap_p ? @0 : @2; }))
{ rhs_tree; })
+
+/* Given:
+
+ j = in / N_I
+ i = in % N_I
+
+ ..., fold:
+
+ out = j * N_I + i
+
+ ..., into:
+
+ out = in
+*/
+
+/* As long as only considering N_I being INTEGER_CST (which are always second
+ argument?), probably don't need ":c" variants? */
+
+(simplify
+ (plus:c
+ (mult:c
+ (trunc_div @0 INTEGER_CST@1)
+ INTEGER_CST@1)
+ (trunc_mod @0 INTEGER_CST@1))
+ (convert @0))
..., the original code:
int f1(int in)
{
int j = in / N_I;
int i = in % N_I;
int out = j * N_I + i;
return out;
}
... gets simplified from ("div-mod-0.c.027t.objsz1"):
f1 (int in)
{
int out;
int i;
int j;
int _1;
int _6;
:
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_return <_6>
}
... to ("div-mod-0.c.028t.ccp1"):
f1 (int in)
{
int out;
int i;
int j;
int _1;
:
gimple_assign
gimple_assign
gimple_assign
gimple_return
}
(The three dead "gimple_assign"s get eliminated later on.)
So, that works.
However, it doesn't work yet for the original construct that I'd ran
into, which looks like this:
[...]
int i;
int j;
[...]
signed int .offset.5_2;
[...]
unsigned int .offset.7_23;
unsigned int .iter.0_24;
unsigned int _25;
unsigned int _26;
[...]
unsigned int .iter.0_32;
[...]
:
# gimple_phi <.offset.5_2, .offset.5_21(8), .offset.5_30(9)>
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
[...]
Resolving the "a[j][i] = 123" we'll need to look into later.
As Marc noted above, with that changed into "*(*(a + j) + i) = 123", we
get:
[...]
int i;
int j;
long unsigned int _1;
long unsigned int _2;
sizetype _3;
sizetype _4;
sizetype _5;
int * _6;
[...]
signed int .offset.5_8;
[...]
unsigned int .offset.7_29;
unsigned int .iter.0_30;
unsigned int _31;
unsigned int _32;
[...]
:
# gimple_phi <.offset.5_8, .offset.5_27(8), .offset.5_36(9)>
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
[...]
Here, unless I'm confused, "_4" is supposed to be equal to ".iter.0_30",
but "match.pd" doesn't agree yet. Note the many "nop_expr"s here, which
I have not yet figured out how to handle, I suppose? I tried some things
but couldn't get it to work. Apparently the existing instances of
"(match (nop_convert @0)" and "Basic strip-useless-type-conversions /
strip_nops" rule also don't handle these; should they? Or, are in fact
here the types mixed up too much?
I hope to get some time again soon to continue looking into this, but if
anybody got any ideas, I'm all ears.
Grüße
Thomas
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #6 from Jonathan Wakely --- Since r254694 only changed all -std modes to match -std=c++17 I bisected again using -std=c++17 to find the change that really caused it, and it was indeed r246301 which first removed that null check. However, this isn't the full story, because on x86_64 we generate correct code at r246301 and r254694, even after Ville's changes removed the null check. For x86_64 everything is OK until r255268. Weird.
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 Jonathan Wakely changed: What|Removed |Added CC||tiagomacarios at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 87660 has been marked as a duplicate of this bug. ***
[Bug c++/87660] Fail to compile unique_ptr of incomplete tyoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87660 Jonathan Wakely changed: What|Removed |Added Keywords|rejects-valid | Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This is a dup *** This bug has been marked as a duplicate of bug 85552 ***
[PATCH, OpenACC] Adjustments and additions to testcases
Hi Thomas,
this patch is a collection of testcase patches we had, ready to be committed to
trunk.
I believe this only touches those parts where you can review, is this okay to
apply?
Thanks,
Chung-Lin
2018-10-22 Cesar Philippidis
gcc/testsuite/
* g++.dg/goacc/loop-1.c: New test.
* g++.dg/goacc/loop-2.c: New test.
* g++.dg/goacc/loop-3.c: New test.
2018-10-22 James Norris
Cesar Philippidis
Tom de Vries
libgomp/
* testsuite/libgomp.oacc-c-c++-common/data-2.c: Update parallel
regions to denote variables copyied in via acc enter data as
present.
* testsuite/libgomp.oacc-fortran/data-3.f90: Likewise.
* testsuite/libgomp.oacc-fortran/data-4.f90: Likewise.
* testsuite/libgomp.oacc-c-c++-common/subr.h: Reimplement.
* testsuite/libgomp.oacc-c-c++-common/subr.ptx: Regenerated PTX.
* testsuite/libgomp.oacc-c-c++-common/timer.h: Removed.
* testsuite/libgomp.oacc-c-c++-common/lib-69.c: Change async checks.
* testsuite/libgomp.oacc-c-c++-common/lib-70.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-71.c: Rework kernel i/f.
* testsuite/libgomp.oacc-c-c++-common/lib-72.c: Rework kernel i/f and
change async checks.
* testsuite/libgomp.oacc-c-c++-common/lib-73.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-74.c: Rework kernel i/f and
timing checks.
* testsuite/libgomp.oacc-c-c++-common/lib-75.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-76.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-77.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-78.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-79.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-80.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-81.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-82.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-93.c: New test.
Index: gcc/testsuite/g++.dg/goacc/loop-1.c
===
--- gcc/testsuite/g++.dg/goacc/loop-1.c (nonexistent)
+++ gcc/testsuite/g++.dg/goacc/loop-1.c (working copy)
@@ -0,0 +1,23 @@
+void
+f (int i, float j, int k)
+{
+#pragma acc parallel num_gangs (i) num_workers (i) vector_length (i)
+#pragma acc loop gang
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc parallel num_gangs (j) /* { dg-error "'num_gangs' expression must
be integral" } */
+#pragma acc loop gang
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc parallel num_workers (j) /* { dg-error "'num_workers' expression
must be integral" } */
+#pragma acc loop gang
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc parallel vector_length (j) /* { dg-error "'vector_length'
expression must be integral" } */
+#pragma acc loop gang
+ for (i = 0; i < 20; ++i)
+;
+}
Index: gcc/testsuite/g++.dg/goacc/loop-2.c
===
--- gcc/testsuite/g++.dg/goacc/loop-2.c (nonexistent)
+++ gcc/testsuite/g++.dg/goacc/loop-2.c (working copy)
@@ -0,0 +1,70 @@
+void
+f (int i, int j, int k)
+{
+#pragma acc kernels
+#pragma acc loop gang
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop gang (num: 10)
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop gang (static: 10)
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop gang (static: 5, num: 10)
+ for (i = 0; i < 20; ++i)
+;
+
+
+#pragma acc kernels
+#pragma acc loop gang (static: 5, num: 10, *) /* { dg-error "duplicate operand
to clause" } */
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop gang (static: 5, num: 10, static: *) /* { dg-error "duplicate
'num' argument" } */
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop worker (static: 234) /* { dg-error "expected 'num' before" }
*/
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop worker (num: 234)
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop worker (num: 234, num: 12) /* { dg-error "duplicate operand
to clause" } */
+ for (i = 0; i < 20; ++i)
+;
+
+#pragma acc kernels
+#pragma acc loop vector /* { dg-error "gang, worker and vector must occur in
this order in a loop nest" } */
+ for (i = 0; i < 20; ++i)
+#pragma acc loop worker
+for (j = 0; j < 25; ++j)
+ ;
+
+#pragma acc kernels
+#pragma acc loop worker (length: 20) /* { dg-error "expected 'num' before
'length'" } */
+ for (i = 0; i < 20; ++i)
+#pragma acc loop vector (length: 10)
+for (j = 0; j < 25; ++j)
+ ;
+
+#pragma acc kernels
+#pragma acc loop worker
+ for (i = 0; i < 20; ++i)
+#pragma acc loop vector
+for (j = 0; j < 25; ++j)
+ ;
+}
Index: gcc/testsuite/g++.dg/goacc/loop-3.c
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680
--- Comment #5 from Richard Biener ---
I believe this bug (and other existing dups) are about the C++ FE for array
initializers not emitting a loop for initialization but an initializer for each
element. It does that via
;; Function constexpr Bar::Bar() (null)
;; enabled by -tree-original
{
>>) >;
}
which eventually is gimplified to
Bar::Bar (struct Bar * const this)
{
this->foo[0].a = 10;
this->foo[0].b = 11;
this->foo[0].c = 12;
this->foo[0].d = 13;
this->foo[1].a = 10;
this->foo[1].b = 11;
...
via cp_gimplify_expr.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #4 from Richard Biener --- What happens if you make the attribute work for a MODE_INT union with a MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode? Is there a generic way to query SImode for PSImode as defined in PARTIAL_INT_MODE (SI, 20, PSI); ? Or does one need to compare MODE_SIZE? Can there be multiple non-partial integer modes with the same size? Thus I suggest to patch handle_transparent_union_attribute according to the above.
Re: [PATCH] Default to an ARM cpu that exists
On 22/10/2018 16:36, co...@sdf.org wrote: > On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote: >> I think strongarm would be a better choice. I'm not aware of anyone >> running NetBSD on Arm8 cpus. > > Clarifying: this is the global default for all GCC ARM targets, > not just netbsd. Is strongarm still the preferred choice? > > Thanks. > Yes, I think so. The two are architecturally compatible (and not that dissimilar in terms of optimization strategies), so StrongArm is probably a better choice for that generation. R.
Re: [PATCH] Default to an ARM cpu that exists
On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote: > I think strongarm would be a better choice. I'm not aware of anyone > running NetBSD on Arm8 cpus. Clarifying: this is the global default for all GCC ARM targets, not just netbsd. Is strongarm still the preferred choice? Thanks.
Re: [PATCH 2/4] Remove unused functions and fields.
On Mon, Oct 22, 2018 at 5:00 AM, Martin Liška wrote: > On 10/19/18 1:02 AM, Ian Lance Taylor wrote: >> On Sat, Sep 22, 2018 at 12:08 PM, marxin wrote: >>> >>> gcc/go/ChangeLog: >>> >>> 2018-09-24 Martin Liska >>> >>> * gofrontend/escape.cc (Gogo::analyze_escape): Remove >>> usage of a parameter. >>> (Gogo::assign_connectivity): Likewise. >>> (class Escape_analysis_tag): Likewise. >>> (Gogo::tag_function): Likewise. >>> * gofrontend/expressions.cc (Call_expression::do_type): Likewise. >>> * gofrontend/gogo.h (class Gogo): Likewise. >>> * gofrontend/types.cc (class Call_multiple_result_type): Likewise. >>> (Type::make_call_multiple_result_type): Likewise. >>> * gofrontend/types.h (class Type): Likewise. >>> * gofrontend/wb.cc (class Check_escape): Likewise. >>> (Gogo::add_write_barriers): Likewise. >> >> HI, unfortunately this is wrong. As described in >> gcc/go/gofrontend/README, the files in that directory are mirrored >> from a separate repository (the same is true of the files in the libgo >> directory). You should not make changes to them directly in the GCC >> repository. I have reverted these changes, as follows. Sorry. >> >> Ian >> > > Hi Ian. > > Got it. Is it possible that the removed chunks of code are somehow alive > in original repository in some conditional build? No, I doubt it, but I'd also want to consider the changes separately. There is benefit to consistency even if it leads to unused variables. Ian
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 --- Comment #4 from Corey Kosak --- To my eye it doesn't seem to be related to exceptions or initializer lists, so I don't think it's the same bug, but you all would know better than me. When I look at the .s file I see a giant sequence of the form .LC0: .long 10 .long 11 .long 12 .long 13 .long 10 .long 11 .long 12 .long 13 .long 10 .long 11 .long 12 .long 13 ... and then the constructor uses .LC0 to initialize the object with a single memcpy. Which might be a fine strategy for objects of reasonable size, but maybe there should be a size cutoff.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #3 from Jozef Lawrynowicz --- Perhaps it is sufficient to check targetm.pass_by_reference, i.e. if the struct/union with the given mode would be passed by reference, then it is ok to give the struct/union a mode outside the MODE_INT class.
[PATCH] Fix PR 86572
Hi!
This makes c_strlen avoid an unsafe strlen folding of const arguments
with non-const offset. Currently a negative out of bounds offset
makes the strlen function return an extremely large number, and
at the same time, prevents the VRP machinery, to determine the correct
range if the strlen function in this case.
Fixed by doing the whole computation in size_t and casting the
result back to ssize_t.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2018-10-22 Bernd Edlinger
PR tree-optimization/86572
* builtins.c (c_strlen): Handle negative offsets in a safe way.
testsuite:
2018-10-22 Bernd Edlinger
PR tree-optimization/86572
* gcc.dg/pr86572.c: New test.
diff -Npur gcc/builtins.c gcc/builtins.c
--- gcc/builtins.c 2018-10-21 10:41:08.0 +0200
+++ gcc/builtins.c 2018-10-22 10:45:25.846236006 +0200
@@ -734,11 +734,14 @@ c_strlen (tree src, int only_value, c_st
of the string subtract the offset from the length of the string,
and return that. Otherwise the length is zero. Take care to
use SAVE_EXPR in case the OFFSET has side-effects. */
- tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff) : byteoff;
- offsave = fold_convert (ssizetype, offsave);
+ tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff)
+ : byteoff;
+ offsave = fold_convert_loc (loc, sizetype, offsave);
tree condexp = fold_build2_loc (loc, LE_EXPR, boolean_type_node, offsave,
- build_int_cst (ssizetype, len));
- tree lenexp = size_diffop_loc (loc, ssize_int (len), offsave);
+ size_int (len));
+ tree lenexp = fold_build2_loc (loc, MINUS_EXPR, sizetype, size_int (len),
+ offsave);
+ lenexp = fold_convert_loc (loc, ssizetype, lenexp);
return fold_build3_loc (loc, COND_EXPR, ssizetype, condexp, lenexp,
build_zero_cst (ssizetype));
}
diff -Npur gcc/testsuite/gcc.dg/pr86572.c gcc/testsuite/gcc.dg/pr86572.c
--- gcc/testsuite/gcc.dg/pr86572.c 1970-01-01 01:00:00.0 +0100
+++ gcc/testsuite/gcc.dg/pr86572.c 2018-10-22 12:35:25.771640418 +0200
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+const char buf[40] = "test";
+void test (int x)
+{
+ if (__builtin_strlen (buf + x) > 4)
+__builtin_abort ();
+}
+
+/* { dg-final { scan-tree-dump-not "abort" "optimized" } } */
[PATCH] Fix PR 87672
Hi!
This fixes an ICE which was exposed by a previous patch of mine,
and a wrong transformation from strcat_chk => strcpy_chk,
which fails to adjust the object size, thus allowing too much
memory to be accessed.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2018-10-22 Bernd Edlinger
PR tree-optimization/87672
* gimple-fold.c (gimple_fold_builtin_stxcpy_chk): Gimplify.
* tree-ssa-strlen.c (handle_builtin_strcat): Adjust object size.
testsuite:
2018-08-26 Bernd Edlinger
PR tree-optimization/87672
* gcc.dg/pr87672.c: New test.
diff -Npur gcc/gimple-fold.c gcc/gimple-fold.c
--- gcc/gimple-fold.c 2018-10-21 20:46:25.0 +0200
+++ gcc/gimple-fold.c 2018-10-22 08:36:19.347227227 +0200
@@ -2715,6 +2715,7 @@ gimple_fold_builtin_stxcpy_chk (gimple_s
return false;
gimple_seq stmts = NULL;
+ len = force_gimple_operand (len, , true, NULL_TREE);
len = gimple_convert (, loc, size_type_node, len);
len = gimple_build (, loc, PLUS_EXPR, size_type_node, len,
build_int_cst (size_type_node, 1));
diff -Npur gcc/tree-ssa-strlen.c gcc/tree-ssa-strlen.c
--- gcc/tree-ssa-strlen.c 2018-10-21 20:46:25.0 +0200
+++ gcc/tree-ssa-strlen.c 2018-10-22 12:45:58.167144749 +0200
@@ -2605,12 +2605,19 @@ handle_builtin_strcat (enum built_in_fun
if (endptr)
dst = fold_convert_loc (loc, TREE_TYPE (dst), unshare_expr (endptr));
else
-dst = fold_build2_loc (loc, POINTER_PLUS_EXPR,
- TREE_TYPE (dst), unshare_expr (dst),
+dst = fold_build2_loc (loc, POINTER_PLUS_EXPR, TREE_TYPE (dst), dst,
fold_convert_loc (loc, sizetype,
unshare_expr (dstlen)));
dst = force_gimple_operand_gsi (gsi, dst, true, NULL_TREE, true,
GSI_SAME_STMT);
+ if (objsz)
+{
+ objsz = fold_build2_loc (loc, MINUS_EXPR, TREE_TYPE (objsz), objsz,
+ fold_convert_loc (loc, TREE_TYPE (objsz),
+ unshare_expr (dstlen)));
+ objsz = force_gimple_operand_gsi (gsi, objsz, true, NULL_TREE, true,
+ GSI_SAME_STMT);
+}
if (dump_file && (dump_flags & TDF_DETAILS) != 0)
{
fprintf (dump_file, "Optimizing: ");
diff -Npur gcc/testsuite/gcc.dg/pr87672.c gcc/testsuite/gcc.dg/pr87672.c
--- gcc/testsuite/gcc.dg/pr87672.c 1970-01-01 01:00:00.0 +0100
+++ gcc/testsuite/gcc.dg/pr87672.c 2018-10-22 11:27:27.260549463 +0200
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+char buf[40];
+void test (int x)
+{
+ __builtin_strcpy (buf, "test");
+ __builtin___strcat_chk (buf, "postfix" + x, sizeof (buf));
+}
+
+/* { dg-final { scan-tree-dump "memcpy_chk.*, 36\\)" "optimized" } } */
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 44880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44880=edit transparent_union.patch
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #1 from Jozef Lawrynowicz --- The issue is that the union is considered to have size of 32 bits (the in-memory size of __int20), so unless mode_for_size as called by compute_record_mode (both in stor-layout.c) is explicitly told to look for a mode of class MODE_PARTIAL_INT, then a size of 32 will always return MODE_INT. In this case, the union will have TYPE_MODE of SImode, but its field is PSImode, so transparent_union has no effect. As was explained on the GCC mailing list (https://gcc.gnu.org/ml/gcc/2018-05/msg00218.html), in general we want to ensure that the class of a union is MODE_INT, as some ABIs mandate that unions be passed in integer registers. For msp430, it is fine to relax this constraint and allow unions to have PSImode, as all general purpose registers are 20-bits (and msp430 doesn't pass structs/unions by value anyway). The attached patch fixes the issue by requesting a mode of class MODE_PARTIAL_INT when calling mode_for_size in compute_record_mode. However, since other targets which support MODE_PARTIAL_INT may want unions to always have class MODE_INT, I wonder if the attached patch is not appropriate. Should there perhaps be a target hook which allows/disallows MODE_PARTIAL_INT structs/unions?
Re: [PATCH] Default to an ARM cpu that exists
On 21/10/2018 05:53, co...@sdf.org wrote:
> Regarding target/86383, it wasn't sufficient to not just pick arm6 for
> netbsd, as the default -mcpu is still arm6, which also fails to build.
>
> I assume the default is expected to be the oldest support, and I think
> now that's arm8, so maybe default to that.
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 720e6a737..278c48287 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3987,7 +3987,7 @@ case "${target}" in
> TM_MULTILIB_CONFIG="$with_multilib_list"
> fi
> fi
> - target_cpu_cname=${target_cpu_cname:-arm6}
> + target_cpu_cname=${target_cpu_cname:-arm8}
> with_cpu=${with_cpu:-$target_cpu_cname}
> ;;
>
>
I think strongarm would be a better choice. I'm not aware of anyone
running NetBSD on Arm8 cpus.
Otherwise, this is fine with a suitable ChangeLog entry.
R.
[Bug c/87691] New: transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
Bug ID: 87691
Summary: transparent_union attribute does not work with
MODE_PARTIAL_INT
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
msp430-elf uses the partial int type __int20 for pointers in the large memory
model. __int20 has PSImode, with bitsize of 20.
A few DejaGNU tests fail when built with -mlarge for msp430-elf, when
transparent unions are used containing pointers.
These are:
- gcc.c-torture/compile/pr34885.c
- gcc.dg/transparent-union-{1,2,3,4,5}.c
Consider the following C source code:
typedef union {
__int20 a;
} union_a __attribute__ ((__transparent_union__));
Compiling produces a warning:
> msp430-elf-gcc -S testcase.c
> warning: 'transparent_union' attribute ignored [-Wattributes]
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #20 from Segher Boessenkool --- That is still not what I said, so don't pretend I did please. Those are also not false positives: in all these cases, the program does in fact skip some initialisation. But, it seems -Wjump-misses-init is not what you want; you do not want a warning for jumping over initialisers, it warns for a lot of harmless code. What you want is a warning that only warns if the var is (potentially) used without initialisation?
Re: [RFC] GCC support for live-patching
On Thu, 18 Oct 2018, Qing Zhao wrote: > Hi, > > After more detailed study of GCC’s IPA optimizations, further study of the > current available kernel live patching schemes and > other live-patching user’s request, I came up with the following initial > proposal in GCC to mainly support live-patching users who > manually create patches. > > Please take a look at the writeup, and let me know your opinions and > suggestions. Hi, thanks for the proposal. The others have already expressed some of my worries and remarks, but I think it would be only right to write them again. Especially since I am part of the team responsible for implementation and maintenance of live patches here at SUSE, we use kGraft and we prepare everything manually (compared to kpatch and ksplice). [...] > 1. A study of Kernel live patching schemes. > > Three major kernel live patching tools: https://lwn.net/Articles/734765/ > > * ksplice: http://www.ksplice.com/doc/ksplice.pdf > * kpatch:https://lwn.net/Articles/597123/ > https://github.com/dynup/kpatch > * kGraft: > https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf > > In the above, ksplice and kpatch can automatically generate binary patches > as following: > >* a collection of tools which convert a source diff patch to a patch > module. They work by compiling the kernel both with and without the source > patch, comparing the binaries, and generating a binary patch module which > includes new binary versions of the functions to be replaced. > > on the other hand, kGraft offers a way to create patches entirely by hand. > The source of the patch is a single C file, easy to review, easy to > maintain. > > In addition to kGraft, there are other live patching tools that prefer > creating patches by hand for the similar reason. > > The compiler support is mainly for the above live patching tools that create > patches entirely by hand. the major purpose is: > > * control patch code size and debug complexity; > * keep good run time performance; > > 2. the major problems of compiler in live patching: > > For the live patching schemes that create patches by hand, when patching > one function, there might a list of functions that will be impacted by > this patched function due to compiler optimization/analyses (mainly IPA > optimization/analyses), a complete patch will include the patched function > and all impacted functions. Usually, there are two major factors to be > considered in such live patching schemes: > > * patch code size, one major factor is the length of the list > of impacted functions; > * run time performance. > > If we want to control the patch code size, to make the list of impacted > functions minimum, we have to disable corresponding compiler optimizations > as much as possible. Andi already talked about it and I, too, do not understand your worry about patch code size. First, it has never been so bad here. Yes, sometimes the function closure gets bigger due to optimizations and inlining. I've considered it as nothing else than a lack of better tooling, because it is indeed something which could be improved a lot. Nicolai (CCed) works on a potential solution. It is also one of the topics at LPC miniconf in Vancouver. Second, the idea to disable inlining would not fly at SUSE. I can't imagine to even propose it. The kernel heavily relies on the feature. The optimizations are a different story and some of those certainly could be disabled with no harm caused. So let me ask, what is your motivation behind this? Is there a real problem you're trying to solve? It may have been mentioned somewhere and I missed it. > On the other hand, in order to keep good run time performance, we need to > keep the compiler optimization as much as possible. > > So, there should be some tradeoff between these two factors. > > The following are two major categories of compiler optimizations > we should considered: > > A. compiler optimizations/analyses that extract ipa info from > a routine's body, and use such info to guide other optimization. > > Since the body of the routine might be changed for live patching, > the ipa info extracted from the body of the routine also changes, > as a result, all the routines that directly or indirectly utilize > the ipa info from this routine are in the list of the impacted > routines. > > Most of the IPA analyses and optimization belong to this category. > > Although theoretically the impacted routine list from such ipa > phases could be computed, the list might be huge. Such huge list > of impacted routine might explode the patch code size too much. > > Therefore, it might be more pratical to just completely disable such > ipa optimizations/analyses. > > B. Inlining, and all optimizaitons that internally create clone. > for example, cloning, ipa-sra, partial inlining, etc. > We can track the effect and impacted
[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #2 from Alex Bradbury ---
Better example demonstrating the problem exists for returns too:
$ cat foo.c
struct float_struct { float v; };
struct char_struct { char v; };
struct float_struct callee(float, char);
float caller(struct float_struct fs, struct char_struct cs) {
return callee(fs.v, cs.v).v;
}
$ ./riscv32-unknown-elf-gcc -march=rv64i -mabi=lp64 -S -o - foo.c -O2
.file "foo.c"
.option nopic
.text
.align 2
.globl caller
.type caller, @function
caller:
addisp,sp,-16
andia1,a1,0xff
sd ra,8(sp)
callcallee
ld ra,8(sp)
addisp,sp,16
jr ra
.size caller, .-caller
.ident "GCC: (GNU) 9.0.0 20180922 (experimental)"
[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690 --- Comment #1 from Alex Bradbury --- It's clear from the example but I made a typo in the explanation due to a last minute change in my example. char is unsigned, so the value in char_struct is zero-extended as we expect.
[Bug target/87690] New: [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
Bug ID: 87690
Summary: [RISCV][ABI] GCC fails to sign-extend floats passed in
the lp64 ABI
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The RISC-V PSABI documentation specifies the following for the base/integer
calling convention:
1) When passed in registers, scalars narrower than XLEN bits are widened
according to the sign of their type up to 32 bits, then sign-extended to XLEN
bits.
2) Floating-point reals are passed the same way as integers of the same size
3) For aggregates, bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined.
i.e. when XLEN=64, floats should be sign-extended when passed in GPRs.
In the following example, the top 54 bits in the GPR for char_struct and the
top 32 bits in the GPR for float_struct are undefined. Therefore, the compiler
should insert an explicit sign extension in both cases.
$ cat foo.c
struct float_struct { float v; };
struct char_struct { char v; };
struct float_struct callee(float, char);
struct float_struct caller(struct float_struct fs, struct char_struct cs) {
return callee(fs.v, cs.v);
}
It does for the char, but not for the float. This is not compliant with the
specified ABI:
./riscv32-unknown-elf-gcc -march=rv64i -mabi=lp64 -S -o - foo.c -O2
.file "foo.c"
.option nopic
.text
.align 2
.globl caller
.type caller, @function
caller:
andia1,a1,0xff
tailcallee
.size caller, .-caller
.ident "GCC: (GNU) 9.0.0 20180922 (experimental)"
Note: this is a compiler build from one month ago. I can't see any commits
since then that fix this, and unfortunately I seem unable to build
gas+newlib+gcc in a combined tree currently which I usually do for a rapid
build in order to verify a bug (Error: non-constant .uleb128 is not supported).
Re: [PATCH 15/25] Don't double-count early-clobber matches.
On 04/10/2018 21:39, Richard Sandiford wrote:
OK with that change if it works, thanks.
Thanks, here's what I've committed.
Andrew
Don't double-count early-clobber matches.
Given a pattern with a number of operands:
(match_operand 0 "" "=")
(match_operand 1 "" " v0")
(match_operand 2 "" " v0")
(match_operand 3 "" " v0")
GCC will currently increment "reject" once, for operand 0, and then decrement
it once for each of the other operands, ending with reject == -2 and an
assertion failure. If there's a conflict then it might try to decrement reject
yet again.
Incidentally, what these patterns are trying to achieve is an allocation in
which operand 0 may match one of the other operands, but may not partially
overlap any of them. Ideally there'd be a better way to do this.
In any case, it will affect any pattern in which multiple operands may (or
must) match an early-clobber operand.
The patch only allows a reject-- when one has not already occurred, for that
operand.
2018-10-22 Andrew Stubbs
gcc/
* lra-constraints.c (process_alt_operands): New local array,
matching_early_clobber. Check matching_early_clobber before
decrementing reject, and set matching_early_clobber after.
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 774d1ff..3b355a8 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1969,6 +1969,7 @@ process_alt_operands (int only_alternative)
if (!TEST_BIT (preferred, nalt))
continue;
+ bool matching_early_clobber[MAX_RECOG_OPERANDS];
curr_small_class_check++;
overall = losers = addr_losers = 0;
static_reject = reject = reload_nregs = reload_sum = 0;
@@ -1980,6 +1981,7 @@ process_alt_operands (int only_alternative)
fprintf (lra_dump_file,
"Staticly defined alt reject+=%d\n", inc);
static_reject += inc;
+ matching_early_clobber[nop] = 0;
}
reject += static_reject;
early_clobbered_regs_num = 0;
@@ -2175,7 +2177,11 @@ process_alt_operands (int only_alternative)
"%d Matching earlyclobber alt:"
" reject--\n",
nop);
- reject--;
+ if (!matching_early_clobber[m])
+ {
+reject--;
+matching_early_clobber[m] = 1;
+ }
}
/* Otherwise we prefer no matching
alternatives because it gives more freedom
@@ -2921,15 +2927,11 @@ process_alt_operands (int only_alternative)
curr_alt_dont_inherit_ops[curr_alt_dont_inherit_ops_num++]
= last_conflict_j;
losers++;
- /* Early clobber was already reflected in REJECT. */
- lra_assert (reject > 0);
if (lra_dump_file != NULL)
fprintf
(lra_dump_file,
"%d Conflict early clobber reload: reject--\n",
i);
- reject--;
- overall += LRA_LOSER_COST_FACTOR - 1;
}
else
{
@@ -2953,17 +2955,21 @@ process_alt_operands (int only_alternative)
}
curr_alt_win[i] = curr_alt_match_win[i] = false;
losers++;
- /* Early clobber was already reflected in REJECT. */
- lra_assert (reject > 0);
if (lra_dump_file != NULL)
fprintf
(lra_dump_file,
"%d Matched conflict early clobber reloads: "
"reject--\n",
i);
+ }
+ /* Early clobber was already reflected in REJECT. */
+ if (!matching_early_clobber[i])
+ {
+ lra_assert (reject > 0);
reject--;
- overall += LRA_LOSER_COST_FACTOR - 1;
+ matching_early_clobber[i] = 1;
}
+ overall += LRA_LOSER_COST_FACTOR - 1;
}
if (lra_dump_file != NULL)
fprintf (lra_dump_file, " alt=%d,overall=%d,losers=%d,rld_nregs=%d\n",
Re: [PATCH] Switch conversion: support any ax + b transformation (PR tree-optimization/84436).
On Mon, Oct 22, 2018 at 04:08:53PM +0200, Martin Liška wrote:
> Very valid question. I hope as long as I calculate the linear function
> values in wide_int (get via wi::to_wide (switch_element)), then it should
> overflow in the same way as original tree type arithmetic. I have a test-case
> with
> overflow: gcc/testsuite/gcc.dg/tree-ssa/pr84436-4.c.
>
> Do you have any {over,under)flowing test-cases that I should add to
> test-suite?
I'm worried that the calculation you emit into the code could invoke UB at
runtime, even if there was no UB in the original code, and later GCC passes
would optimize with the assumption that UB doesn't occur.
E.g. if the multiplication overflows for one or more of the valid values in
the switch and then the addition adds a negative value so that the end
result is actually representable.
Jakub
Re: [PATCH] Switch conversion: support any ax + b transformation (PR tree-optimization/84436).
On 10/22/18 4:17 PM, Alexander Monakov wrote: > On Mon, 22 Oct 2018, Martin Liška wrote: > >> On 10/11/18 3:03 PM, Jakub Jelinek wrote: >>> On Thu, Oct 11, 2018 at 02:56:14PM +0200, Martin Liška wrote: As seen in the PR, switch conversion can do better when we return equal numbers based on index value. I implemented more than that, more precisely I support all linear transformation based on index value. It's the same what clang is capable of. >>> >>> Not a review, just a question, do you check for overflows while computing >>> it? Or force the arithmetics to be performed in a type with defined >>> overflow. It would be bad to introduced UB... >> >> Very valid question. I hope as long as I calculate the linear function >> values in wide_int (get via wi::to_wide (switch_element)), then it should >> overflow in the same way as original tree type arithmetic. I have a >> test-case with >> overflow: gcc/testsuite/gcc.dg/tree-ssa/pr84436-4.c. > > Sorry I missed this the first time around. Note the testcase should use > 'signed > char', otherwise it depends on whether plain 'char' is signed or not. Good observation, I'll fix that. > > I think this is the kind of invalid transformation Jakub was concerned about, > the transformation introduces signed multiplication that overflows and assumes > it would wrap around. About this, using TYPE_OVERFLOW_WRAPS (which relies on flag_wrapv) should be enough? Martin > > Alexander >
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #10 from Tom de Vries --- (In reply to Richard Biener from comment #9) > (In reply to Jonathan Wakely from comment #8) > > There's no such thing as 8.2.2, the next release will be 8.3.0, see > > https://gcc.gnu.org/develop.html#num_scheme > > > > Tom, is it time to backport this from trunk to gcc-7-branch and > > gcc-8-branch? > > Yeah, I think so. Ok, I'm on it.
[Bug rtl-optimization/87678] Redundant vmovss with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678 --- Comment #2 from Segher Boessenkool --- This is a much more general problem in combine. In general it only tries once, and it only tries the fully simplified form, including known bit values etc.
Re: [PATCH] Switch conversion: support any ax + b transformation (PR tree-optimization/84436).
On Mon, 22 Oct 2018, Martin Liška wrote: > On 10/11/18 3:03 PM, Jakub Jelinek wrote: > > On Thu, Oct 11, 2018 at 02:56:14PM +0200, Martin Liška wrote: > >> As seen in the PR, switch conversion can do better when we return equal > >> numbers > >> based on index value. I implemented more than that, more precisely I > >> support all linear > >> transformation based on index value. It's the same what clang is capable > >> of. > > > > Not a review, just a question, do you check for overflows while computing > > it? Or force the arithmetics to be performed in a type with defined > > overflow. It would be bad to introduced UB... > > Very valid question. I hope as long as I calculate the linear function > values in wide_int (get via wi::to_wide (switch_element)), then it should > overflow in the same way as original tree type arithmetic. I have a test-case > with > overflow: gcc/testsuite/gcc.dg/tree-ssa/pr84436-4.c. Sorry I missed this the first time around. Note the testcase should use 'signed char', otherwise it depends on whether plain 'char' is signed or not. I think this is the kind of invalid transformation Jakub was concerned about, the transformation introduces signed multiplication that overflows and assumes it would wrap around. Alexander
