[Bug tree-optimization/79002] Weird c++ assembly code generated for tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79002 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-01-05 00:00:00 |2021-7-27 Component|c++ |tree-optimization --- Comment #6 from Andrew Pinski --- Still happens on the trunk. The first tailr does not detect the tail recursion but the second one does.
[Bug target/39821] 120% slowdown with vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
--- Comment #9 from Hongtao.liu ---
(In reply to Richard Biener from comment #8)
> I've pushed the change that makes us run into ix86_multiplication_cost but
> as said that doesn't differentiate highpart or widening multiply yet and
> thus we're now missing optimizations because of too conservative costing.
For MULT_HIGHPART_EXPR, x86 only have pmulhw, it's probably ok to go into
ix86_multiplication_cost.
For WIDEN_MULT_EXPR, we need a separate cost function which should also accept
sign info since we have pmuludq under sse2 but pmuldq under sse4.1.
.i.e we should vectorize udotproduct under sse2, but sdotprodoct under sse4.1
#include
uint64_t udotproduct(uint32_t *v1, uint32_t *v2, int order)
{
uint64_t accum = 0;
while (order--)
accum += (uint64_t) *v1++ * *v2++;
return accum;
}
#include
int64_t sdotproduct(int32_t *v1, int32_t *v2, int order)
{
int64_t accum = 0;
while (order--)
accum += (int64_t) *v1++ * *v2++;
return accum;
}
[Bug c++/68842] Better error output when template needed before dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68842 Andrew Pinski changed: What|Removed |Added CC||soko.slav at yandex dot ru --- Comment #4 from Andrew Pinski --- *** Bug 90495 has been marked as a duplicate of this bug. ***
[Bug c++/90495] Incorrect parsing of a()->b construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90495 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- (In reply to Marek Polacek from comment #1) > Changed in r236221. Not a bug: the fix is to use the template > disambiguator. > > But the diagnostics is pretty awful so I'll confirm the PR for that part. That would make this a dup of PR 68842 . *** This bug has been marked as a duplicate of bug 68842 ***
[Bug c++/60531] template function not resolved when comparing functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531 Andrew Pinski changed: What|Removed |Added CC||roman.perepelitsa at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 71382 has been marked as a duplicate of this bug. ***
[Bug c++/71382] Unary plus doesn't work with pointers to instantiations of function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71382 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is a dup of bug 60531 which is fixed in GCC 10+. The testcase is already there for this case even. *** This bug has been marked as a duplicate of bug 60531 ***
[Bug c++/70608] Braced initializer in default argument misses friendship
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70608 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Ever confirmed|0 |1 Last reconfirmed||2021-07-28 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
--- Comment #3 from Steve Kargl ---
On Mon, Jul 26, 2021 at 07:15:53PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
>
> --- Comment #2 from kargl at gcc dot gnu.org ---
> Created attachment 51207
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51207=edit
> Diff that implements F2018 NON_RECURSIVE and makes things recursive by
> default.
>
Better patch.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 413c7a75e0c..35ab2655a3b 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6353,6 +6353,17 @@ gfc_match_prefix (gfc_typespec *ts)
found_prefix = true;
}
+ if (gfc_match ("non_recursive% ") == MATCH_YES)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018, "NON_RECURSIVE procedure at %C"))
+ goto error;
+
+ if (!gfc_add_non_recursive (_attr, NULL))
+ goto error;
+
+ found_prefix = true;
+ }
+
/* IMPURE is a somewhat special case, as it needs not set an actual
attribute but rather only prevents ELEMENTAL routines from being
automatically PURE. */
@@ -6381,6 +6392,15 @@ gfc_match_prefix (gfc_typespec *ts)
goto error;
}
+ /* If neither NON_RECURSIVE nor RECURSIVE has been seen and the F2018
+ standard is in play, then mark the the procedure as recursive. */
+ if ((gfc_option.allow_std & GFC_STD_F2018)
+ && !current_attr.non_recursive && !current_attr.recursive)
+{
+ if (!gfc_add_recursive (_attr, NULL))
+ goto error;
+}
+
/* At this point, the next item is not a prefix. */
gcc_assert (gfc_matching_prefix);
@@ -6447,6 +6467,9 @@ copy_prefix (symbol_attribute *dest, locus *where)
if (current_attr.recursive && !gfc_add_recursive (dest, where))
return false;
+ if (current_attr.non_recursive && !gfc_add_non_recursive (dest, where))
+return false;
+
return true;
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index f4a50d74f14..72ed9c6ee3d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -842,7 +842,7 @@ typedef struct
unsigned is_iso_c:1; /* Symbol is from iso_c_binding. */
/* Function/subroutine attributes */
- unsigned sequence:1, elemental:1, pure:1, recursive:1;
+ unsigned sequence:1, elemental:1, pure:1, recursive:1, non_recursive:1;
unsigned unmaskable:1, masked:1, contained:1, mod_proc:1, abstract:1;
/* Set if this is a module function or subroutine. Note that it is an
@@ -3223,6 +3223,7 @@ bool gfc_add_sequence (symbol_attribute *, const char *,
locus *);
bool gfc_add_elemental (symbol_attribute *, locus *);
bool gfc_add_pure (symbol_attribute *, locus *);
bool gfc_add_recursive (symbol_attribute *, locus *);
+bool gfc_add_non_recursive (symbol_attribute *, locus *);
bool gfc_add_function (symbol_attribute *, const char *, locus *);
bool gfc_add_subroutine (symbol_attribute *, const char *, locus *);
bool gfc_add_volatile (symbol_attribute *, const char *, locus *);
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 6d61bf4982b..f456a02847c 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -410,24 +410,24 @@ gfc_check_function_type (gfc_namespace *ns)
bool
gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
{
- static const char *dummy = "DUMMY", *save = "SAVE", *pointer = "POINTER",
-*target = "TARGET", *external = "EXTERNAL", *intent = "INTENT",
-*intent_in = "INTENT(IN)", *intrinsic = "INTRINSIC",
-*intent_out = "INTENT(OUT)", *intent_inout = "INTENT(INOUT)",
-*allocatable = "ALLOCATABLE", *elemental = "ELEMENTAL",
-*privat = "PRIVATE", *recursive = "RECURSIVE",
-*in_common = "COMMON", *result = "RESULT", *in_namelist = "NAMELIST",
-*publik = "PUBLIC", *optional = "OPTIONAL", *entry = "ENTRY",
-*function = "FUNCTION", *subroutine = "SUBROUTINE",
-*dimension = "DIMENSION", *in_equivalence = "EQUIVALENCE",
-*use_assoc = "USE ASSOCIATED", *cray_pointer = "CRAY POINTER",
-*cray_pointee = "CRAY POINTEE", *data = "DATA", *value = "VALUE",
-*volatile_ = "VOLATILE", *is_protected = "PROTECTED",
-*is_bind_c = "BIND(C)", *procedure = "PROCEDURE",
-*proc_pointer = "PROCEDURE POINTER", *abstract = "ABSTRACT",
-*asynchronous = "ASYNCHRONOUS", *codimension = "CODIMENSION",
-*contiguous = "CONTIGUOUS", *generic = "GENERIC", *automatic =
"AUTOMATIC",
-*pdt_len = "LEN", *pdt_kind = "KIND";
+ static const char *abstract = "ABSTRACT", *allocatable = "ALLOCATABLE",
+*asynchronous = "ASYNCHRONOUS", *automatic = "AUTOMATIC",
+*codimension = "CODIMENSION", *contiguous = "CONTIGUOUS",
+*cray_pointee = "CRAYPOINTEE", *cray_pointer = "CRAYPOINTER",
+*data = "DATA", *dimension = "DIMENSION", *dummy = "DUMMY",
+*elemental = "ELEMENTAL", *entry = "ENTRY", *external = "EXTERNAL",
+*function = "FUNCTION", *generic = "GENERIC",
[Bug c++/64696] [C++14] braced-init-list does not respect designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64696 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid, wrong-code --- Comment #2 from Andrew Pinski --- (In reply to Jason Merrill from comment #1) > G++ implements issue 1467, so the only bug is with the designated > initializer, which is an extension for C compatibility. Well not exactly an extension only more :). It was added for C++20. Anyways this seems fixed on the trunk.
[Bug c++/69059] [C++14] Invalid rejection of expression as not-a-constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69059 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- I can't reproduce this on released versions of GCC. GCC 5.5.0 works and GCC 6.1.0 works
[Bug c++/68678] [5 Regression] Initialization of pointer by constant expression using static ctor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68678 Andrew Pinski changed: What|Removed |Added Known to work||4.8.5, 6.0 Resolution|--- |FIXED Target Milestone|--- |6.0 Summary|Initialization of pointer |[5 Regression] |by constant expression |Initialization of pointer |using static ctor. |by constant expression ||using static ctor. Known to fail||4.9.0, 5.5.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 6.
[Bug libfortran/101317] Bind(C): improve error checking in CFI_* functions declared in ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317 --- Comment #2 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:e78480ad0983cf75813af5e02d68cdad09e441e9 commit r12-2555-ge78480ad0983cf75813af5e02d68cdad09e441e9 Author: Sandra Loosemore Date: Thu Jul 15 08:48:45 2021 -0700 Bind(c): Improve error checking in CFI_* functions This patch adds additional run-time checking for invalid arguments to CFI_establish and CFI_setpointer. It also changes existing messages throughout the CFI_* functions to use PRIiPTR to format CFI_index_t values instead of casting them to int and using %d (which may not work on targets where int is a smaller type), simplifies wording of some messages, and fixes issues with capitalization, typos, and the like. Additionally some coding standards problems such as >80 character lines are addressed. 2021-07-24 Sandra Loosemore PR libfortran/101317 libgfortran/ * runtime/ISO_Fortran_binding.c: Include . (CFI_address): Tidy error messages and comments. (CFI_allocate): Likewise. (CFI_deallocate): Likewise. (CFI_establish): Likewise. Add new checks for validity of elem_len when it's used, plus type argument and extents. (CFI_is_contiguous): Tidy error messages and comments. (CFI_section): Likewise. Refactor some repetitive code to make it more understandable. (CFI_select_part): Likewise. (CFI_setpointer): Likewise. Check that source is not an unallocated allocatable array or an assumed-size array. gcc/testsuite/ * gfortran.dg/ISO_Fortran_binding_17.f90: Fix typo in error message patterns.
[Bug libfortran/101310] Bind(C): CFI_section seems confused by pointer arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310 --- Comment #3 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:b4a9bc7856ee1d3ff98b04402334a362540af2cf commit r12-2554-gb4a9bc7856ee1d3ff98b04402334a362540af2cf Author: Sandra Loosemore Date: Sat Jul 17 16:12:18 2021 -0700 Bind(c): Fix bugs in CFI_section CFI_section was incorrectly adjusting the base pointer for the result array twice in different ways. It was also overwriting the array dimension info in the result descriptor before computing the base address offset from the source descriptor, which caused problems if the two descriptors are the same. This patch fixes both problems and makes the code simpler, too. A consequence of this patch is that the result array is now 0-based in all dimensions instead of starting at the numbering to match the first element of the source array. The Fortran standard only specifies the shape of the result array, not its lower bounds, so this is permitted and probably less confusing for users as well as implementors. 2021-07-17 Sandra Loosemore PR libfortran/101310 libgfortran/ * runtime/ISO_Fortran_binding.c (CFI_section): Fix the base address computation and simplify the code. gcc/testsuite/ * gfortran.dg/ISO_Fortran_binding_1.c (section_c): Remove incorrect assertions.
[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:a3b350f1799a1c0f9e2ece5b817a537fe42f0d2d commit r12-2553-ga3b350f1799a1c0f9e2ece5b817a537fe42f0d2d Author: Sandra Loosemore Date: Thu Jul 8 12:00:57 2021 -0700 Fix ISO_Fortran_binding.h paths in gfortran testsuite ISO_Fortran_binding.h is now generated in the libgfortran build directory where it is on the default include path. Adjust includes in the gfortran testsuite not to include an explicit path pointing at the source directory. 2021-07-27 Sandra Loosemore gcc/testsuite/ PR libfortran/101305 * gfortran.dg/ISO_Fortran_binding_1.c: Adjust include path. * gfortran.dg/ISO_Fortran_binding_10.c: Likewise. * gfortran.dg/ISO_Fortran_binding_11.c: Likewise. * gfortran.dg/ISO_Fortran_binding_12.c: Likewise. * gfortran.dg/ISO_Fortran_binding_15.c: Likewise. * gfortran.dg/ISO_Fortran_binding_16.c: Likewise. * gfortran.dg/ISO_Fortran_binding_17.c: Likewise. * gfortran.dg/ISO_Fortran_binding_18.c: Likewise. * gfortran.dg/ISO_Fortran_binding_3.c: Likewise. * gfortran.dg/ISO_Fortran_binding_5.c: Likewise. * gfortran.dg/ISO_Fortran_binding_6.c: Likewise. * gfortran.dg/ISO_Fortran_binding_7.c: Likewise. * gfortran.dg/ISO_Fortran_binding_8.c: Likewise. * gfortran.dg/ISO_Fortran_binding_9.c: Likewise. * gfortran.dg/PR94327.c: Likewise. * gfortran.dg/PR94331.c: Likewise. * gfortran.dg/bind_c_array_params_3_aux.c: Likewise. * gfortran.dg/iso_fortran_binding_uint8_array_driver.c: Likewise. * gfortran.dg/pr93524.c: Likewise.
[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 --- Comment #5 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:c4dc9f590181321c36d3f3ef72c50b3c47bbfe7c commit r12-2552-gc4dc9f590181321c36d3f3ef72c50b3c47bbfe7c Author: Sandra Loosemore Date: Thu Jul 8 16:38:14 2021 -0700 Bind(C): Correct sizes of some types in CFI_establish CFI_establish was failing to set the default elem_len correctly for CFI_type_cptr, CFI_type_cfunptr, CFI_type_long_double, and CFI_type_long_double_Complex. 2021-07-13 Sandra Loosemore libgfortran/ PR libfortran/101305 * runtime/ISO_Fortran_binding.c (CFI_establish): Special-case CFI_type_cptr and CFI_type_cfunptr. Correct size of long double on targets where it has kind 10.
[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 --- Comment #4 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:fef67987cf502fe322e92ddce22eea7ac46b4d75 commit r12-2551-gfef67987cf502fe322e92ddce22eea7ac46b4d75 Author: Sandra Loosemore Date: Thu Jul 8 08:21:20 2021 -0700 Bind(C): Fix type encodings in ISO_Fortran_binding.h ISO_Fortran_binding.h had many incorrect hardwired kind encodings in the definitions of the CFI_type_* macros. Additionally, not all targets support all the defined type encodings, and the Fortran standard requires those macros to have a negative value. This patch changes ISO_Fortran_binding.h to use sizeof instead of hard-coded sizes, and assembles it from fragments that reflect the set of types supported by the target. 2021-07-22 Sandra Loosemore Tobias Burnus libgfortran/ PR libfortran/101305 * ISO_Fortran_binding.h: Fix hard-coded sizes and split into... * ISO_Fortran_binding-1-tmpl.h: New file. * ISO_Fortran_binding-2-tmpl.h: New file. * ISO_Fortran_binding-3-tmpl.h: New file. * Makefile.am: Add rule for generating ISO_Fortran_binding.h. Adjust pathnames to that file. * Makefile.in: Regenerated. * mk-kinds-h.sh: New file. * runtime/ISO_Fortran_binding.c: Fix include path.
[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Keywords||accepts-invalid Target Milestone|--- |6.0 Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed in GCC 6 with r6-4886 (note this is expected because we delay simplifications until after semantics anlysis now).
[Bug middle-end/101596] vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kewen Lin --- Should be fixed on trunk.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #9 from cqwrteur --- export CFLAGS="-O3 -DNDEBUG -march=native -fno-ident -ffunction-sections -fdata-sections" export CXXFLAGS=$CFLAGS CPPFLAGS=$CFLAGS export LDFLAGS="-Wl,--gc-sections"
[Bug middle-end/101596] vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596 --- Comment #4 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:89b3c97eed75c1e7c492bc727e0016003c5809cc commit r12-2550-g89b3c97eed75c1e7c492bc727e0016003c5809cc Author: Kewen Lin Date: Tue Jul 27 22:04:22 2021 -0500 vect: Fix wrong check in vect_recog_mulhs_pattern [PR101596] As PR101596 showed, vect_recog_mulhs_pattern uses target_precision to check the scale_term is expected or not, it could be wrong when the precision of the actual used new_type larger than target_precision as shown by the example. This patch is to use precision of new_type instead of target_precision for the scale_term matching check. Bootstrapped & regtested on powerpc64le-linux-gnu P10, powerpc64-linux-gnu P8, x86_64-redhat-linux and aarch64-linux-gnu. gcc/ChangeLog: PR tree-optimization/101596 * tree-vect-patterns.c (vect_recog_mulhs_pattern): Fix wrong check by using new_type's precision instead. gcc/testsuite/ChangeLog: PR tree-optimization/101596 * gcc.target/powerpc/pr101596-1.c: New test. * gcc.target/powerpc/pr101596-2.c: Likewise. * gcc.target/powerpc/pr101596-3.c: Likewise.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #8 from cqwrteur --- He said he just adds patch for the mcf thread model. https://github.com/lhmouse/MINGW-packages-dev/blob/master/mingw-w64-gcc-git/9000-gcc-10-branch-Added-mcf-thread-model-support-from-mcfgthread.patch And he changed things in the makefile to enable -fno-ident -O3 -march=native.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #7 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > Can you provide the exact steps you are doing? > Because I think you are misunderstanding how this works. > > So if you use --host=x86_64-w64-mingw32 . > > configure:2358: checking build system type > configure:2372: result: x86_64-pc-linux-gnu > configure:2419: checking host system type > configure:2432: result: x86_64-w64-mingw32 > configure:2452: checking target system type > configure:2465: result: x86_64-w64-mingw32 > > But it uses the wrong compiler for the target libraries. > > Also I see you had built the cross compiler in the src directory: > Configured with: ./configure --disable-libstdcxx-verbose --disable-multilib > --disable-nls --enable-fully-dynamic-string --enable-languages=c,c++,lto > --enable-large-address-aware --enable-mingw-wildcard --enable-threads=mcf > --target=x86_64-w64-mingw32 > > Don't do that. A question about Canadian compiler. Does the Canadian compiler try to find the lib in the $prefix/$target/lib and include from prefix/$target/include? Does it only find libs in the cross compiler itself? Should I build libc for candian compiler or just copy files from cross compiler?
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > Can you provide the exact steps you are doing? > Because I think you are misunderstanding how this works. > > So if you use --host=x86_64-w64-mingw32 . > > configure:2358: checking build system type > configure:2372: result: x86_64-pc-linux-gnu > configure:2419: checking host system type > configure:2432: result: x86_64-w64-mingw32 > configure:2452: checking target system type > configure:2465: result: x86_64-w64-mingw32 > > But it uses the wrong compiler for the target libraries. > > Also I see you had built the cross compiler in the src directory: > Configured with: ./configure --disable-libstdcxx-verbose --disable-multilib > --disable-nls --enable-fully-dynamic-string --enable-languages=c,c++,lto > --enable-large-address-aware --enable-mingw-wildcard --enable-threads=mcf > --target=x86_64-w64-mingw32 > > Don't do that. I do not know actually, because i just reported that for my friend he does not have an account. Can you just create an account for boot...@163.com?
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #5 from Andrew Pinski --- Can you provide the exact steps you are doing? Because I think you are misunderstanding how this works. So if you use --host=x86_64-w64-mingw32 . configure:2358: checking build system type configure:2372: result: x86_64-pc-linux-gnu configure:2419: checking host system type configure:2432: result: x86_64-w64-mingw32 configure:2452: checking target system type configure:2465: result: x86_64-w64-mingw32 But it uses the wrong compiler for the target libraries. Also I see you had built the cross compiler in the src directory: Configured with: ./configure --disable-libstdcxx-verbose --disable-multilib --disable-nls --enable-fully-dynamic-string --enable-languages=c,c++,lto --enable-large-address-aware --enable-mingw-wildcard --enable-threads=mcf --target=x86_64-w64-mingw32 Don't do that.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #4 from cqwrteur --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 Also an old bug i reported 2 months ago for multilibs. However, nobody seems to read that.
[Bug c++/99969] g++ incorrectly thinks a private destructor is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99969 --- Comment #1 from Andrew Pinski --- This seems fixed since GCC 11.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #3 from cqwrteur --- Created attachment 51218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51218=edit another libgcc bug
[Bug c++/94564] C++20: Three-way comparison between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94564 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Status|NEW |RESOLVED Depends on||87699 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- This was fixed by the patch which fixed bug 87699 expectly. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 [Bug 87699] Implement CWG 1512
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #2 from cqwrteur --- looks like canadian compile is not tested frequently as native or cross is doing. It still breaks for either libgcc and libstdc++. (Some times even the gcc itself, like msdos for example) I am just helping another person who has no account to report the bug here.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #1 from cqwrteur --- Created attachment 51217 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51217=edit config.log
[Bug libgcc/101655] New: canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 Bug ID: 101655 Summary: canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 51216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51216=edit stderr messages
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid, wrong-code
--- Comment #13 from Andrew Pinski ---
Here is a run time testcase of the same issue from PR 86032:
struct Empty
{
Empty& operator=(const Empty&) = default;
};
template
class ShowType;
template<>
struct ShowType{int t = 0;};
template<>
struct ShowType{int t = 1;};
int main()
{
ShowType example;
return example.t;
}
[Bug tree-optimization/100457] [meta bug] Enabling O2 vectorization in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457 Bug 100457 depends on bug 99881, which changed state. Bug 99881 Summary: Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hongtao.liu --- Fixed in GCC12.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Andrew Pinski changed: What|Removed |Added CC||ihorelo at mail dot ru --- Comment #12 from Andrew Pinski --- *** Bug 86032 has been marked as a duplicate of this bug. ***
[Bug c++/86032] non standard copy operator is used for empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86032 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- This is dup of bug 54319 which was just debugging. *** This bug has been marked as a duplicate of bug 54319 ***
[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:872da9a6f664a06d73c987aa0cb2e5b830158a10 commit r12-2549-g872da9a6f664a06d73c987aa0cb2e5b830158a10 Author: liuhongt Date: Fri Mar 26 10:56:47 2021 +0800 Add the member integer_to_sse to processor_cost as a cost simulation for movd/pinsrd. It will be used to calculate the cost of vec_construct. gcc/ChangeLog: PR target/99881 * config/i386/i386.h (processor_costs): Add new member integer_to_sse. * config/i386/x86-tune-costs.h (ix86_size_cost, i386_cost, i486_cost, pentium_cost, lakemont_cost, pentiumpro_cost, geode_cost, k6_cost, athlon_cost, k8_cost, amdfam10_cost, bdver_cost, znver1_cost, znver2_cost, znver3_cost, btver1_cost, btver2_cost, btver3_cost, pentium4_cost, nocona_cost, atom_cost, atom_cost, slm_cost, intel_cost, generic_cost, core_cost): Initialize integer_to_sse same value as sse_op. (skylake_cost): Initialize integer_to_sse twice as much as sse_op. * config/i386/i386.c (ix86_builtin_vectorization_cost): Use integer_to_sse instead of sse_op to calculate the cost of vec_construct. gcc/testsuite/ChangeLog: PR target/99881 * gcc.target/i386/pr99881.c: New test.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 --- Comment #11 from Andrew Pinski --- For the original testcase, I think r0-98505 introduce the failure.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
--- Comment #10 from Andrew Pinski ---
It is the code in call.c that makes a difference:
if (is_really_empty_class (type, /*ignore_vptr*/true))
{
/* Avoid copying empty classes. */
val = build2 (COMPOUND_EXPR, type, arg, to);
suppress_warning (val, OPT_Wunused);
}
else if (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (as_base)))
{
if (is_std_init_list (type)
&& conv_binds_ref_to_prvalue (convs[1]))
warning_at (loc, OPT_Winit_list_lifetime,
"assignment from temporary % does "
"not extend the lifetime of the underlying array");
arg = cp_build_fold_indirect_ref (arg);
val = build2 (MODIFY_EXPR, TREE_TYPE (to), to, arg);
}
else
{
/* We must only copy the non-tail padding parts. */
tree arg0, arg2, t;
tree array_type, alias_set;
arg2 = TYPE_SIZE_UNIT (as_base);
to = cp_stabilize_reference (to);
arg0 = cp_build_addr_expr (to, complain);
array_type = build_array_type (unsigned_char_type_node,
build_index_type
(size_binop (MINUS_EXPR,
arg2, size_int (1;
alias_set = build_int_cst (build_pointer_type (type), 0);
t = build2 (MODIFY_EXPR, void_type_node,
build2 (MEM_REF, array_type, arg0, alias_set),
build2 (MEM_REF, array_type, arg, alias_set));
val = build2 (COMPOUND_EXPR, TREE_TYPE (to), t, to);
suppress_warning (val, OPT_Wunused);
}
if we do the middle one only, we get the correct type.
I won't be able to debug this any further. But I suspect because we are
lowering the AST too early, we don't do the correct type dealing here due to
the COMPOUND_EXPR.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> I think the problem is here in init.c:
> /* If the type has data but no user-provided default ctor, we need to
> zero
> out the object. */
> if (type_has_non_user_provided_default_constructor (type)
> && !is_really_empty_class (type, /*ignore_vptr*/true))
> {
> tree field_size = NULL_TREE;
> if (exp != true_exp && CLASSTYPE_AS_BASE (type) != type)
> /* Don't clobber already initialized virtual bases. */
> field_size = TYPE_SIZE (CLASSTYPE_AS_BASE (type));
> init = build_zero_init_1 (type, NULL_TREE,
> /*static_storage_p=*/false,
> field_size);
> init = build2 (INIT_EXPR, type, exp, init);
> finish_expr_stmt (init);
> }
Nope.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
--- Comment #8 from Andrew Pinski ---
I think the problem is here in init.c:
/* If the type has data but no user-provided default ctor, we need to
zero
out the object. */
if (type_has_non_user_provided_default_constructor (type)
&& !is_really_empty_class (type, /*ignore_vptr*/true))
{
tree field_size = NULL_TREE;
if (exp != true_exp && CLASSTYPE_AS_BASE (type) != type)
/* Don't clobber already initialized virtual bases. */
field_size = TYPE_SIZE (CLASSTYPE_AS_BASE (type));
init = build_zero_init_1 (type, NULL_TREE,
/*static_storage_p=*/false,
field_size);
init = build2 (INIT_EXPR, type, exp, init);
finish_expr_stmt (init);
}
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
Andrew Pinski changed:
What|Removed |Added
Known to work||4.4.7
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > Note even the following X causes an error:
> > struct X {int :1;};
> >
> > Maybe that will give a hint of where the bug is located.
>
> Which makes this a regression even :).
> The above with just one anonymous bitfield field is accepted until GCC 6.
>
> But this should give even more of what is the underlaying bug.
r6-7811 exposed the latent bug for the anonymous bitfield case (which is
expected).
The original testcase worked in 4.4.7 also.
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
Andrew Pinski changed:
What|Removed |Added
Summary|empty class causes error|[9/10/11/12 Regression]
|while non-empty does not|empty class causes error
||while non-empty does not
Target Milestone|--- |9.5
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Note even the following X causes an error:
> struct X {int :1;};
>
> Maybe that will give a hint of where the bug is located.
Which makes this a regression even :).
The above with just one anonymous bitfield field is accepted until GCC 6.
But this should give even more of what is the underlaying bug.
[Bug c++/54319] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Summary|Assignment to rvalue|empty class causes error
||while non-empty does not
--- Comment #5 from Andrew Pinski ---
Note even the following X causes an error:
struct X {int :1;};
Maybe that will give a hint of where the bug is located.
[Bug c++/72507] incorrectly accepts invalid C++11 code that tries to allocate an incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72507 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2016-07-26 00:00:00 |2021-7-27 --- Comment #1 from Andrew Pinski --- Looks like we are not instantiating A::t unless you use it directly. That is if we add: int r = A::t; The program is rejected as expected.
[Bug c++/96256] Invalid consteval call not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96256 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/zeEY9 | |6 | --- Comment #1 from Andrew Pinski --- clang crashes on this code :).
[Bug c++/52761] [C++11] Missing diagnostic for opaque unscoped enum declaration without base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52761 Andrew Pinski changed: What|Removed |Added CC||anders.granlund.0 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 67016 has been marked as a duplicate of this bug. ***
[Bug c++/67016] Redeclaration of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67016 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 52761. *** This bug has been marked as a duplicate of bug 52761 ***
[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 Andrew Pinski changed: What|Removed |Added CC||phd at phd dot re --- Comment #4 from Andrew Pinski --- *** Bug 101653 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101653] [9/10/11/12 Regression] Bad code generated when optimizing nested for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101653 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- So the loop of PR 100740 is same as this one so marking as a dup. That is both have a double loop and the inner one has loop exit which is bound by comparing of the induction variable that is counting how many times inside the loop it has happened and comparing it against in the inner loop induction variable. *** This bug has been marked as a duplicate of bug 100740 ***
[Bug tree-optimization/101653] [9/10/11/12 Regression] Bad code generated when optimizing nested for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101653 --- Comment #2 from Andrew Pinski --- Confirmed, ivcannon is turning the loops into: [local count: 79093198]: goto ; [100.00%] [local count: 357878150]: a_8 = a_11 + 1; c_14 = c_3 + 2; goto ; [100.00%] [local count: 79093198]: # _5 = PHI <123(6)> return _5; [local count: 375401868]: # c_3 = PHI <1(2), c_14(4)> # a_11 = PHI <0(2), a_8(4)> # ivtmp_20 = PHI <2(2), ivtmp_1(4)> c_6 = c_3 + 1; ivtmp_1 = ivtmp_20 - 1; if (ivtmp_1 == 0) goto ; [5.50%] else goto ; [94.50%] Removing all of the if conditions on c < a and turning it into true ...
[Bug tree-optimization/101653] [9/10/11/12 Regression] Bad code generated when optimizing nested for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101653 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Last reconfirmed||2021-07-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51 So possibly related or the same as PR101508 or PR100740
[Bug testsuite/101654] New: [12 regression] new test case UNRESOLVED problem in r12-2524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101654 Bug ID: 101654 Summary: [12 regression] new test case UNRESOLVED problem in r12-2524 Product: gcc Version: 12.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: --- g:13586172d0b70c9d7ca464fc5a2a46a8532b06d7, r12-2523 make -k check-gcc RUNTESTFLAGS="ipa.exp=gcc.dg/ipa/remref-6.c" spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled151951.cc -fdiagnostics-plain-output -S -o exceptions_enabled151951.s PASS: gcc.dg/ipa/remref-6.c (test for excess errors) gcc.dg/ipa/remref-6.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "Removed a reference" gcc.dg/ipa/remref-6.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "replaced it with LOAD" PASS: gcc.dg/ipa/remref-6.c scan-tree-dump-not optimized "builtin_exp" testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ipa/ipa.exp completed in 1 seconds === gcc Summary === # of expected passes2 # of unresolved testcases 2 commit 13586172d0b70c9d7ca464fc5a2a46a8532b06d7 (HEAD, refs/bisect/bad) Author: Martin Jambor Date: Tue Jul 27 10:02:38 2021 +0200 ipa: Adjust references to identify read-only globals
[Bug tree-optimization/101653] [9/10/11/12 Regression] Bad code generated when optimizing nested for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101653 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Summary|Bad code generated when |[9/10/11/12 Regression] Bad |optimizing nested for loops |code generated when ||optimizing nested for loops Component|c |tree-optimization Target Milestone|--- |9.5
[Bug c/101653] New: Bad code generated when optimizing nested for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101653
Bug ID: 101653
Summary: Bad code generated when optimizing nested for loops
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: phd at phd dot re
Target Milestone: ---
Not sure if this was already reported.
Bad code is generated when optimizing nested for loops:
int main(void)
{
unsigned a, b, c = 0; // issue only occurs for unsigned
for (a = 0; a < 10; a++) // upper limit for variable a doesn't really
matter
{
for (b = 0; b < 2; b++) // bug only for b < 2, no issue for other
limits
{
c++; // first iteration: a == 0, b == 0, c == 1
if (c < a) // c will *never* be smaller than a from now on
{
return 123; // and yet this is somehow reachable with -O1/2/3
}
}
}
return 0; // with -O0 this returns 0 properly
}
Affected gcc versions: 9.1+ (including 11.1 and trunk)
Not affected versions: 8.5-
Bug occurs for -O1, -O2, -O3 (return 123)
No issue for -O0 (properly returns 0)
Both C and C++ are affected.
Live demo:
https://godbolt.org/z/nanc9osq5
[Bug c++/92604] GCC accepts invalid conversion from designated initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92604 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #2 from Andrew Pinski --- Fixed for GCC 12, most likely by r12-955.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #8 from Jakub Jelinek --- Useful for what? What exactly is an advantage to require attribute at such a place? Nothing will warn if you put it there, but I don't see a rationale for requiring it.
[Bug c++/86581] constexpr variable allows uninitialized member of anonymous struct inside union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86581
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Andrew Pinski ---
GCC 10+ rejects it but does NOT say why though:
:6:13: error: 'V{V::{V{0}}}' is not a constant expression
6 | constexpr V v;
|
So keeping open for that.
(In reply to Ted Lyngmo from comment #2)
> Does this bug cover this case? This compiles with g++ but clang++ gives
> "error: constexpr union constructor does not initialize any member".
No.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #7 from Joe Perches --- What could be useful is to add yet another --extra-strict-fallthrough warning flag that would make it possible for these cases to have a warning.
[Bug c++/98440] [9/10 Regression] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 Andrew Pinski changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #5 from Andrew Pinski --- *** Bug 86633 has been marked as a duplicate of this bug. ***
[Bug c++/86633] invalid with rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86633 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- This is a dup of bug 98440. *** This bug has been marked as a duplicate of bug 98440 ***
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 --- Comment #11 from Andrew Pinski --- *** Bug 86228 has been marked as a duplicate of this bug. ***
[Bug c++/86228] ordered comparison between pointer and zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86228 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- This is a dup of bug 87699 which is fixed for GCC 11+ *** This bug has been marked as a duplicate of bug 87699 ***
[Bug c++/80380] misleading behavior with designated initializers for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80380 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- This is a dup of bug 95369. *** This bug has been marked as a duplicate of bug 95369 ***
[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/68188] Ambiguous code gets compiled successfully when class and its namespace have the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68188 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski --- Confirmed.
[Bug c++/68188] Ambiguous code gets compiled successfully when class and its namespace have the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68188 Andrew Pinski changed: What|Removed |Added CC||andreim77 at yahoo dot com --- Comment #6 from Andrew Pinski --- *** Bug 67663 has been marked as a duplicate of this bug. ***
[Bug c++/67663] ambiguous namespace/class name not reported as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67663 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 68188. *** This bug has been marked as a duplicate of bug 68188 ***
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #276 from Larkin Nickle --- Created attachment 51215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51215=edit How I'm attempting to build GCC 11.1 For what it's worth, here's exactly how I'm attempting to build 11.1. This is based on The Written Word's script from comment #246.
[Bug c++/71919] Redefinition of user-defined conversions (via typedef) shouldn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71919 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed in GCC 8+. Most likely by r8-2664 but I could be wrong.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 101584, which changed state. Bug 101584 Summary: missing -Wuninitialized with an allocated object after a built-in call https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101584] missing -Wuninitialized with an allocated object after a built-in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Sebor --- Done for GCC 12.
[Bug tree-optimization/101584] missing -Wuninitialized with an allocated object after a built-in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:6aacd901b800ee8a2a03123669b299a08aad0504 commit r12-2544-g6aacd901b800ee8a2a03123669b299a08aad0504 Author: Martin Sebor Date: Tue Jul 27 16:02:54 2021 -0600 Let -Wuninitialized assume built-ins don't change const arguments [PR101584]. PR tree-optimization/101584 - missing -Wuninitialized with an allocated object after a built-in call gcc/ChangeLog: PR tree-optimization/101584 * tree-ssa-uninit.c (builtin_call_nomodifying_p): New function. (check_defs): Call it. gcc/testsuite/ChangeLog: PR tree-optimization/101584 * gcc.dg/uninit-38.c: Remove assertions. * gcc.dg/uninit-41.c: New test.
[Bug c++/53931] [C++11] braced function style cast to reference should be prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931
--- Comment #3 from Andrew Pinski ---
typedef int &
void zip1(int x) { ir{x}; }
Also is accepted.
[Bug c++/69127] inconsistent handling of initializers of zero-length array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69127 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-27 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/60009] g++ allows copy-initialization of an array of class type from a non-braced string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60009 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84632 Resolution|--- |FIXED Target Milestone|--- |7.0 Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed in GCC 7, I cannot figure out which revision fixed it though. Note r8-7514 fixes the error message though where in GCC 7 would print out some error messages dealing with no matching of constructors.
[Bug c++/65906] using-declaration allowed for non-direct base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65906 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Andrew Pinski --- This was fixed with r7-4255: Implement P0136R1, Rewording inheriting constructors. Which makes sense.
[Bug c/101645] warn about neg of unsigned type should be added to -Wsign-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101645 John Hubbard changed: What|Removed |Added CC||jhubbard at nvidia dot com --- Comment #3 from John Hubbard --- Here are some data points in favor of adding this warning: 1) It's already desirable in a real project (Linux kernel, as Matthew pointed out), and 2) Clang has already gone there, presumably for good reasons as well. 3) Anecdote: as an experienced C programmer, I can tell you that the "b(-x)" results are rarely what a programmer would want, nor intend. (Of course, the ideal is a perfect type-safe match between input and args, but that doesn't always happen in real code.) The compiler knows enough to significantly help here, by warning. It's also possible to update the -Wsign-conversion documentation to match, if necessary, let's not forget that.
[Bug c++/101651] vector extension and element access vs C++17 constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101651
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
Here is clang's error message which is 1% wrong.
:7:16: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
constexpr auto gen () {
^
:11:18: note: subexpression not valid in a constant expression
ret[i] = ret1[0];
^
1 error generated.
Compiler returned: 1
[Bug fortran/101652] New: Audit uses of general purpose matching routine gfc_match with code %v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101652 Bug ID: 101652 Summary: Audit uses of general purpose matching routine gfc_match with code %v Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The purpose of this PR is a reminder of the discussion during the review of patches for pr101564, see https://gcc.gnu.org/pipermail/fortran/2021-July/056273.html and related mails. E.g. Fortran 2018 has: 9.2 Variable R902 variable is designator or function-reference C901 (R902) designator shall not be a constant or a subobject of a constant. C902 (R902) function-reference shall have a data pointer result. A variable is either the data object denoted by designator or the target of the pointer resulting from the evaluation of function-reference; this pointer shall be associated. ... The current implementation of gfc_match invokes gfc_match_variable when it encounters the code %v, which does not handle function-references. One possible solution is to audit the code and to replace uses of %v by %e and subsequently check using gfc_check_vardef_context.
[Bug c++/101651] vector extension and element access vs C++17 constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101651
Andrew Pinski changed:
What|Removed |Added
Summary|vector extension and|vector extension and
|element write vs C++17 |element access vs C++17
|constexpr functions |constexpr functions
--- Comment #2 from Andrew Pinski ---
So it is any vector array that matters:
#ifdef WORK
#include
typedef std::array vec;
#else
typedef char vec __attribute__((vector_size(2)));
#endif
constexpr auto gen () {
vec ret{1,2};
vec ret1{1,2};
for (int i = 0; i < sizeof(vec); ++i) {
ret[i] = ret1[0];
}
// ret1[0] =3;
// ret1[0] =ret[0];
return ret1;
};
auto m = gen();
Note clang rejects the above for non -DWORK case.
[Bug c++/101651] vector extension and element write vs C++17 constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101651 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2021-07-27 Blocks||55004 Summary|constexpr write to simd |vector extension and |vector element |element write vs C++17 ||constexpr functions --- Comment #1 from Andrew Pinski --- Confirmed. I really doubt any of the vector extensions are really supported with constexpr. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/101651] New: constexpr write to simd vector element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101651
Bug ID: 101651
Summary: constexpr write to simd vector element
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(adapted from https://stackoverflow.com/q/68517921/1918193)
#ifdef WORK
#include
typedef std::array vec;
#else
typedef char vec __attribute__((vector_size(16)));
#endif
constexpr auto gen () {
vec ret{};
for (int i = 0; i < sizeof(vec); ++i) {
ret[i] = 2;
}
return ret;
};
constexpr auto m = gen();
c.cc:9:23: in 'constexpr' expansion of 'gen()'
c.cc:9:24: error: modification of '(char [16])ret' is not a constant expression
9 | constexpr auto m = gen();
|^
However, with -DWORK to use std::array instead of the vector extension, it
compiles just fine, so there shouldn't be any strong obstacle to implement
this.
[Bug testsuite/101646] [12 regression] excess errors after r12-2533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101646 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Should be fixed now.
[Bug testsuite/101646] [12 regression] excess errors after r12-2533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101646 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7195fb01fe62a313ae5f7faede698101bdb3025 commit r12-2542-gb7195fb01fe62a313ae5f7faede698101bdb3025 Author: Jonathan Wakely Date: Tue Jul 27 21:29:10 2021 +0100 testsuite: Add missing C++ includes to tests [PR101646] These tests stopped working after some libstdc++ refactoring, because they aren't including what they use. gcc/testsuite/ChangeLog: PR testsuite/101646 * g++.dg/coroutines/pr99047.C: * g++.dg/pr71655.C:
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #6 from Jakub Jelinek --- (In reply to Nick Desaulniers from comment #5) > > Not warning in this case is a very intentional part of those design > > decisions. > > Can you provide a link to the discussion about this specific case? The discussions are on gcc-patches mailing list, look into archives from July 2016 to August or September, initially with -Wswitch-fallthrough in the subject, later -Wimplicit-fallthrough. > Is re-evaluating the decision out of the question? Yes. It is pointless to start warning about code that obviously can't do any harm, it will only alienate users that will need to mark up more code. The work Marek has done on this warning started with getting through warnings on gcc itself and on other projects and has been fine tuned on where it is essential not to warn and where false positives can be acceptable.
[Bug c/101585] [11 Regression] Bad interaction of -fsanitize=undefined and -Wvla-parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101585 Martin Sebor changed: What|Removed |Added Summary|[11/12 Regression] Bad |[11 Regression] Bad |interaction of |interaction of |-fsanitize=undefined and|-fsanitize=undefined and |-Wvla-parameters|-Wvla-parameters Known to fail|12.0| --- Comment #3 from Martin Sebor --- Fixed in GCC 12. Will backport to GCC 11.
[Bug testsuite/101646] [12 regression] excess errors after r12-2533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101646 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-07-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The first test is buggy, it needs to include to use std::exchange. The second needs to include to use std::array.
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #8 from Martin Sebor ---
The symptom in comment #6 does look similar to the problem discussed in
pr101292. I haven't debugged it yet but when developing the warning control
patch I struggled with keeping the garbage collector from collecting the global
hash map between location_t and the nowarn_spec_t struct. My suspicion is that
either the annotation on the hash_map isn't correct (it's a simple GTY("") so
it's hard to imagine what might be wrong with it), or the integration with the
garbage collector is incomplete (I had to change the hash_map definition itself
to let hash_map even compile).
[Bug target/87767] Missing AVX512 memory broadcast for constant vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #21 from H.J. Lu --- Fixed for GCC 11.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #5 from Nick Desaulniers --- > Not warning in this case is a very intentional part of those design decisions. Can you provide a link to the discussion about this specific case? Is re-evaluating the decision out of the question?
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #7 from Andrew Pinski --- (In reply to Thomas Schwinge from comment #6) > Short summary: I ran into an unexpected '0xa5a5a5a5' in > 'gcc/warning-control.cc', and a search through email archives pointed me to > PR101292, PR101204, which superficially indeed do look similar. > > Anybody got a good suggestion about how to proceed here? 0xa5a5a5a5 is written when the GC has reclaimed the memory. So the best way is to a reduced testcase using --param ggc-min-expand=0 --param ggc-min-heapsize=0 (note start with --param ggc-min-expand=1 --param ggc-min-heapsize=1 otherwise the compiler will be supper slow).
[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96779
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> This is simple, I will take.
> (for cmp (eq ne)
> (simplify
> (cmp:c @0 (negate @0))
>(if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0)))
> (cmp:c @0 { build_zero_cst (TREE_TYPE(@0)); })
>
> Should be enough.
But it is wrong for wrapping types.
For wrapping types:
-a == a -> (a << 1) == a or (a + a) == 0
But this is worse on targets which have a pattern for -a CMP a (hint aarch64).
So for wrapping types keep the -a == a is the best I think.
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
Thomas Schwinge changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
||msebor at gcc dot gnu.org
Keywords||GC
--- Comment #6 from Thomas Schwinge ---
Short summary: I ran into an unexpected '0xa5a5a5a5' in
'gcc/warning-control.cc', and a search through email archives pointed me to
PR101292, PR101204, which superficially indeed do look similar.
Anybody got a good suggestion about how to proceed here?
---
(gdb) break c-common.c:3633
Breakpoint 3 at 0xea31b5: file [...]/source-gcc/gcc/c-family/c-common.c,
line 3633.
(gdb) r
[...]
Breakpoint 3, c_common_truthvalue_conversion (location=2147537812,
expr=0x73f10550) at [...]/source-gcc/gcc/c-family/c-common.c:3635
3635 if (!warning_suppressed_p (expr, OPT_Wparentheses)
(gdb) c
Continuing.
Breakpoint 3, c_common_truthvalue_conversion (location=2147537812,
expr=0x73f105f0) at [...]/source-gcc/gcc/c-family/c-common.c:3635
3635 if (!warning_suppressed_p (expr, OPT_Wparentheses)
(gdb) c
Continuing.
Breakpoint 3, c_common_truthvalue_conversion (location=2147537909,
expr=0x73f14be0) at [...]/source-gcc/gcc/c-family/c-common.c:3635
3635 if (!warning_suppressed_p (expr, OPT_Wparentheses)
(gdb) s
warning_suppressed_p (expr=0x73f14be0, opt=OPT_Wparentheses) at
[...]/source-gcc/gcc/warning-control.cc:119
119 const nowarn_spec_t *spec = get_nowarn_spec (expr);
(gdb) s
get_nowarn_spec (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:92
92const key_type_t key = convert_to_key (expr);
(gdb) call debug_tree(expr)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x765fc690 precision:32 min max
pointer_to_this reference_to_this
>
side-effects
arg:0
tree_2
arg:0
public arg:0
[...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
[...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
arg:1
side-effects nothrow
fn
constant arg:0 >
arg:0
public arg:0
[...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
[...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
[...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
(gdb) n
94if (!get_no_warning_bit (expr) || !key)
(gdb) print key
$4 = 2147537909
(gdb) print/x key
$5 = 0x8000d3f5
(gdb) s
get_no_warning_bit (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
40return expr->base.nowarning_flag;
(gdb) finish
Run till exit from #0 get_no_warning_bit (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
0x01d18699 in get_nowarn_spec (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:94
94if (!get_no_warning_bit (expr) || !key)
Value returned is $6 = true
(gdb) n
97return nowarn_map ? nowarn_map->get (key) : NULL;
(gdb) print nowarn_map
$7 = (xint_hash_map_t *) 0x7675ae10
(gdb) finish
Run till exit from #0 get_nowarn_spec (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:97
0x01d18764 in warning_suppressed_p (expr=0x73f14be0,
opt=OPT_Wparentheses) at [...]/source-gcc/gcc/warning-control.cc:119
119 const nowarn_spec_t *spec = get_nowarn_spec (expr);
Value returned is $8 = (nowarn_spec_t *) 0x765c66d4
(gdb) print/x *$8
$9 = {m_bits = 0xa5a5a5a5}
(This is what then causes the spurious diagnostic; in a "non-faulting" build,
this is 'm_bits = 2'.)
[Bug tree-optimization/101650] (len | N) == len is transformed to len & N != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101650 --- Comment #1 from Andrew Pinski --- *** Bug 101591 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101591] (a|b) ==/!= a -> (b & ~a) ==/!= 0 on gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101591 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- (In reply to Richard Biener from comment #4) > Not sure if it is cheaper - it's one more operation on GIMPLE so (a|b) == a > looks more canonical? I agree. I filed the constant one as PR 101650 after not realizing I filed this one already too :). So this is a dup of bug 101650 really :). *** This bug has been marked as a duplicate of bug 101650 ***
[Bug tree-optimization/101650] (len | N) == len is transformed to len & N != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101650 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-07-27 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101590
[Bug tree-optimization/101650] New: (len | N) == len is transformed to len & N != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101650
Bug ID: 101650
Summary: (len | N) == len is transformed to len & N != 0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While looking at PR 101590, I noticed this one.
#include
const size_t N = 4;
bool foo(size_t len) {
size_t newlen = len | N;
return newlen == len;
}
(for cmp (NE EQ)
icmp (EQ NE)
(simplify
(cmp (bit_ior @0 INTEGER_CST@1) @0)
(icmp (bit_and @0 @1) ({ build_zero_cst (TREE_TYPE (@0)); })
)
)
This is already done for bit_and.
[Bug c++/101649] -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 --- Comment #4 from South Window --- For the user of GCC it doesn't matter whether GCC at compile times converts the literal to a double, and then notices that 32 bits of are zero, and uses a float instead, or if GCC knows right away that 0.5 (and others) don't need to be promoted. Promoting first and then completely undoing the promotion is a purely internal process, effectively a null operation that is of no interest of the user of the compiler. One of the most relevant scopes for -Wdouble-promotion is probably optimization (in particular for SIMD), where the unintended use of a double would cause a significant performance hit. But if the compiler is smart enough and is not using doubles and double instructions, and no precision is changed anywhere in the process, it should be smart enough to not through a this warning.
[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Biener from comment #1)
> > it doesn't even have to be -N, any unsigned & N <= unsigned
>
> Here are the ones which are valid:
>
> U | N < U -> false
> U & N <= U -> true
> U & N > U -> false
> U | N >= U -> true
>
> (for cmp (LT GE)
> (simplify
> (cmp (bit_ior @0 INTEGER_CST@1) @0)
> ({ constant_boolean_node (cmp == GE, type); })))
> (for cmp (LE GT)
> (simplify
> (cmp (bit_and @0 INTEGER_CST@1) @0)
> ({ constant_boolean_node (cmp == LE, type); })))
>
> I don't see an easy way to combine these two patterns though.
I forgot the check for unsigned :).
