[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 Jakub Jelinek changed: What|Removed |Added Attachment #47069|0 |1 is obsolete|| --- Comment #26 from Jakub Jelinek --- Created attachment 47070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47070&action=edit gcc10-prereload-splitters.patch Updated patch for the pre-reload splitters, which uses a new predicate and additionally removes constraints and attributes from those define_insn_and_split that had them (most of them didn't), because nothing will really look at constraints before reload and similarly for enabled etc. attributes.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #27 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #26) > Created attachment 47070 [details] > gcc10-prereload-splitters.patch > > Updated patch for the pre-reload splitters, which uses a new predicate and > additionally removes constraints and attributes from those > define_insn_and_split that had them (most of them didn't), because nothing > will really look at constraints before reload and similarly for enabled etc. > attributes. FYI, these constraints were used in the past (when combine was allowed to propagate hard registers into combined insn) to prevent reload failures, where reload was not able to e.g. reload wrong hard reg in the place of count reg in the shift insn pattern to %ecx. Nowadays, constraints in the patterns of pre-reload insn_and_split are not necessary anymore, and can be removed together with ix86_legitimate_combined_insn target hook.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #28 from Jakub Jelinek --- Author: jakub Date: Sat Oct 19 12:46:57 2019 New Revision: 277203 URL: https://gcc.gnu.org/viewcvs?rev=277203&root=gcc&view=rev Log: PR target/92140 * config/i386/predicates.md (int_nonimmediate_operand): New special predicate. * config/i386/i386.md (*add3_eq, *add3_ne, *add3_eq_0, *add3_ne_0, *sub3_eq, *sub3_ne, *sub3_eq_1, *sub3_eq_0, *sub3_ne_0): New define_insn_and_split patterns. * gcc.target/i386/pr92140.c: New test. * gcc.c-torture/execute/pr92140.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr92140.c trunk/gcc/testsuite/gcc.target/i386/pr92140.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 91368, which changed state.
Bug 91368 Summary: Implement P1301R4: [[nodiscard("with reason")]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91368
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91368 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Implemented in r277200.
[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91368 --- Comment #4 from JeanHeyd Meneide --- 🎉!!
[Bug c++/92158] New: Enum warning when -1 enum converted to unsigned int or int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
Bug ID: 92158
Summary: Enum warning when -1 enum converted to unsigned int or
int
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Could warnings for this be added for C and C++?
I tested on godbolt trunk today 19 Oct 2019.
There isn't any warning output when 'a_t' is converted to 'int'. Or even if it
was converted to an 'unsigned int'
https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
//-O2 -Wall -Wextra -Wconversion -Werror
#include
typedef enum
{
a = -1
} a_t;
a_t f()
{
return a;
}
int main()
{
int b = f();
return b;
}
[Bug c++/92159] New: -Wenum-conversion for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92159
Bug ID: 92159
Summary: -Wenum-conversion for C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Bug 60591 added -Wenum-conversion for C
Could this be added for C++ too?
#1 with x86-64 gcc (trunk)
cc1plus: error: command-line option '-Wenum-conversion' is valid for C/ObjC but
not for C++ [-Werror]
cc1plus: all warnings being treated as errors
Compiler returned: 1
Test case
enum xpto
{
A = 0,
B = 1,
X = 512
};
extern void print (unsigned int);
unsigned char bar (enum xpto a)
{
return a;
}
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
--- Comment #19 from Jonny Grant ---
(In reply to Eric Gallager from comment #18)
> (In reply to Jonny Grant from comment #17)
> > Hello Joseph
> >
> > This was the test case I created. There isn't any warning output when 'a_t'
> > is converted to 'int'. Or even if it was converted to an 'unsigned int'
> >
> > https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
> >
> >
> > //-O2 -Wall -Wextra -Wconversion -Werror
> >
> > #include
> > typedef enum
> > {
> > a = -1
> > } a_t;
> >
> > a_t f()
> > {
> > return a;
> > }
> >
> > int main()
> > {
> > int b = f();
> > return b;
> > }
>
> While it's true that g++ prints no warnings for that testcase, I think
> that's material for a separate bug. The original bug here was just to add
> -Wenum-conversion for the C front-end, which has now been done, so I'm
> closing this. Feel free to open new bugs for any missed cases.
ok, I added
Bug 92159 to add -Wenum-conversion for C++
Bug 92158 my enum test case for C and C++
[Bug ipa/92160] New: The control variable of TLS variable alias be removed when use emutls(--enable-tls=no)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92160
Bug ID: 92160
Summary: The control variable of TLS variable alias be removed
when use emutls(--enable-tls=no)
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: unclepom at sina dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
--- tls.c -
TLS int oldname = 7;
extern TLS int newname __attribute__((alias("oldname")));
---
The control variable "__emutls_v.newname" will be removed, because
tree-emutls.c:new_emutls_decl not copy "externally_visible" flag.
The patch below may fix this bug.
--- a/tree-emutls.c 2019-01-01 20:31:55.0 +0800
+++ b/tree-emutls.c 2019-10-19 22:54:40.478401699 +0800
@@ -345,6 +345,7 @@
n = varpool_node::create_alias (to, t->decl);
n->resolve_alias (t);
+ n->externally_visible = t->externally_visible;
}
return to;
}
../gcc-9.2.0/configure -v --enable-languages=c,c++
--prefix=/home/pom/Documents/Work/LiBox/gcc-out --with-gcc-major-version-only
--program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-default-pie --with-system-zlib
--with-target-system-zlib --disable-werror -with-abi=m64 --disable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --enable-tls=no
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jerry DeLisle --- As far as I can tell, fixed on trunk.
[Bug fortran/92113] [8 regression] r276673 causes segfault in gfortran.dg/pr51434.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
CC||koenigni at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
It is not clear to me what is going on here.
I have spent quite some time trying to find the revision
which fixed the bug for gcc 9 and gcc 10, without success;
I am getting contradictory results when I try to bisect.
Bisecting with trunk led to failures up to recent revisions,
compiling the compiler again led to something which now works (??).
The only thing I can find is, if I revert the patch on current gcc 8,
I get a diff with -fdump-tree-optimized-uid
--- ARTIFICIAL/pr51434.f90.232t.optimized 2019-10-19 16:06:31.580900454
+
+++ READONLY/pr51434.f90.232t.optimized 2019-10-19 16:06:23.961105008 +
@@ -18,7 +18,7 @@
{
unsigned long ivtmp.25D.2274;
unsigned long ivtmp.20D.2269;
- static struct a cD.2212 = {.mD.2189=5, .tD.2191={"a", "b", "c", "d", "e", "
", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " "}};
+ static struct a cD.2212;
static integer(kind=4)D.3 options.3D.2226[7] = {68, 8191, 0, 1, 1, 0, 31};
character(kind=1)D.17 pretmp_6;
character(kind=1)D.17 pretmp_14
which certainly looks very suspicious.
The fact that this seems to depend on random (?) circumstances, and
depend on optimization levels, may point to a problem with
declaring different variables for the same thing, this time with
an initializer. However, I am not sure how to debug this...
[Bug fortran/91926] assumed rank optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91926 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Oct 19 16:44:06 2019 New Revision: 277204 URL: https://gcc.gnu.org/viewcvs?rev=277204&root=gcc&view=rev Log: 2019-10-19 Paul Thomas PR fortran/91926 * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Revert the change made on 2019-10-05. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/ISO_Fortran_binding.c
Re: (ARM) Wrong conditional codes when paired with tst instruction
On 18/10/2019 19:43, AlwaysTeachingable . wrote:
> The following C code:
> unsigned int wrong(unsigned int n){
> return (n%2) ? 0 : 42;
> }
>
> should return 42 when n is odd and 0 when n is even.
No. Your code returns 42 when n is even.
It's equivalent to "return ((n%2) != 0) ? 0 : 42;"
Now it's more obvious that when n is odd the expression is true so
returns 0.
>
> But ARM gcc 8.2 with -O3 produces following assembly:
>
> tst r0, #1
> moveq r0, #42
> movne r0, #0
> bx lr
Which, of course, is exactly what your source code asked for.
>
> tst r0,#1 sets Z=1 iff r0 is even, and moveq r0,#42 executes iff Z=1,
> therefore
> it sets r0 to 42 when r0 is even, which is wrong given the C code above (
> it should return 0 ).
>
R.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #29 from Segher Boessenkool --- (In reply to Uroš Bizjak from comment #27) > FYI, these constraints were used in the past (when combine was allowed to > propagate hard registers into combined insn) to prevent reload failures, > where reload was not able to e.g. reload wrong hard reg in the place of > count reg in the shift insn pattern to %ecx. Nowadays, constraints in the > patterns of pre-reload insn_and_split are not necessary anymore, and can be > removed together with ix86_legitimate_combined_insn target hook. combine still propagates hard registers. The only thing it does not combine is single-set register-register copies from a non-fixed hard register; everything else with hard registers it still does, like if the *destination* of the move is a hard reg (e.g., in the function return value). Does it help the i386 port if we disallow a hard reg dest as well? RA should be able to handle that just fine as well. This still will not get rid of *all* (non-fixed) hard registers, you still can get them from explicit register variables, and target code (or even generic code) can still put some in non-copies, which combine will happily propagate further.
[Bug fortran/92113] [8 regression] r276673 causes segfault in gfortran.dg/pr51434.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113 --- Comment #3 from Segher Boessenkool --- I don't understand that Fortran code correctly, but it seems to me that ARTIFICIAL code is the correct one, so you shouldn't have reverted this patch, and that may just be a red herring even?
[Bug c/92096] segmentation fault in 'example_labels' building gcc trunk on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096 --- Comment #3 from Roger Orr --- A binary chop shows the fault starts with r276878.
[Bug c++/90159] Poor warning for an ambiguous reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90159 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-20 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed.
