[Bug fortran/95446] False positive for optional arguments of elemental procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446 --- Comment #2 from Martin Diehl --- many thanks for the quick reply!
[Bug libfortran/95418] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #2 from Markus Böck --- I printed the size of the struct and it yielded 36. Interestingly, using clang instead yields 32 like on Linux
[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95052 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dc8c02ca1cd18f8c22d70cf17b47125fc25ab243 commit r11-748-gdc8c02ca1cd18f8c22d70cf17b47125fc25ab243 Author: Jakub Jelinek Date: Sun May 31 10:45:21 2020 +0200 expr: Fix fallout from optimize store_expr from STRING_CST [PR95052] > Can't hurt, and debugging the assert tripping is likely a hell of a lot easier > than debugging the resultant incorrect code. So if it passes, then I'd say go > for it. Testing passed, so I've committed it with those asserts (and thankfully I've added them!) but it apparently broke Linux kernel build on arm. The problem is that if the STRING_CST is very short, while the full object has BLKmode, the short string could very well have QImode/HImode/SImode/DImode and in that case it wouldn't take the path that copies the string and then clears the remaining space, but different paths in which it will ICE because of those asserts and without those it would just emit wrong-code. The following patch fixes it by enforcing BLKmode for the string MEM, even if it is short, so that we copy it and memset the rest. 2020-05-31 Jakub Jelinek PR middle-end/95052 * expr.c (store_expr): For shortedned_string_cst, ensure temp has BLKmode. * gcc.dg/pr95052.c: New test.
[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 --- Comment #6 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:811f902b764c5a13178cbd7588e96c16b3fab504 commit r11-749-g811f902b764c5a13178cbd7588e96c16b3fab504 Author: Thomas Koenig Date: Sun May 31 10:26:40 2020 +0200 Finalization depends on the expression, not on the component. This patch fixes a 8/9/10/11 regression, where finalized types were not finalized (and deallocated), which led to memory leaks. gcc/fortran/ChangeLog: 2020-05-24 Thomas Koenig PR fortran/94361 * class.c (finalize_component): Use expr->finalized instead of comp->finalized. * gfortran.h (gfc_component): Remove finalized member. (gfc_expr): Add it here instead. gcc/testsuite/ChangeLog: 2020-05-24 Thomas Koenig PR fortran/94361 * gfortran.dg/finalize_28.f90: Adjusted free counts. * gfortran.dg/finalize_33.f90: Likewise. * gfortran.dg/finalize_34.f90: Likewise. * gfortran.dg/finalize_35.f90: New test.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #2 from Pádraig Brady ---
The test case is in bug #70462.
Copying here...
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
$ nm t.o | grep C2 || echo ABI issue
[Bug c++/95449] New: void_t does not work with some uses of vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95449
Bug ID: 95449
Summary: void_t does not work with some uses of vector_size
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dummyddd at gmail dot com
Target Milestone: ---
Created attachment 48646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48646&action=edit
Example, same as on godbolt
Since GCC 10, the default void_t implementation does not work on some
expressions with vector_size types (see attachment or
https://godbolt.org/z/72xdVZ).
void_t implementations with the CWG issue 1558 workaround still work.
GCC versions between 4.9.0 and 9.3 can compile such expressions without the
workaround (even though the fix for CWG issue 1558 wasn't required until
c++14).
I wasn't able to reduce the example more than this without getting the code to
compile in GCC 10.
Specifically, replacing "SWithSize" with
"SWithSize{ })[0])>" does work in GCC 10.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #22 from Avi Kivity --- @Iain: if you can publish your patches somewhere we can test them with our codebase and report. (if you can publish them on releases/gcc-10 that's even better).
[Bug c++/95449] void_t does not work with some uses of vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95449 Lars Bonnichsen changed: What|Removed |Added Attachment #48646|0 |1 is obsolete|| --- Comment #1 from Lars Bonnichsen --- Created attachment 48647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48647&action=edit Actually does not relate to CWG 1558
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #3 from Pádraig Brady --- I've not got a reduced example where clang is generating the call, but it could be a linker issue as the two constructors are aliased to the same address. The linker used here was lld.
[Bug target/95450] New: [10 regression] Wrong long double folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
Bug ID: 95450
Summary: [10 regression] Wrong long double folding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target Milestone: ---
Target: powerpc-*.*
$ cat test-float.c
#include
#include
union gl_long_double_union
{
struct { double hi; double lo; } dd;
long double ld;
};
const union gl_long_double_union gl_LDBL_MAX =
{ { DBL_MAX, DBL_MAX / (double)134217728UL / (double)134217728UL } };
# undef LDBL_MAX
# define LDBL_MAX (gl_LDBL_MAX.ld)
int
main ()
{
volatile long double m = LDBL_MAX;
assert (m + m > m);
}
$ gcc -O2 test-float.c
$ ./a.out
a.out: test-float.c:20: main: Assertion `m + m > m' failed.
Aborted
test-float.c.234t.optimized contains:
m ={v} 1.79769313486231580793728971405302307166001572487e+308;
but that evaluates to Inf. DBL_MAX is
1.79769313486231570814527423731704e+308L.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #23 from Iain Sandoe --- (In reply to Avi Kivity from comment #22) > @Iain: if you can publish your patches somewhere we can test them with our > codebase and report. > > (if you can publish them on releases/gcc-10 that's even better). working on collating them ready to post - and I expect them to be appropriate for back-port to 10.x.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #1 from David Malcolm ---
gcc_jit_context_dump_reproducer_to_file runs in the testsuite, and I see it
generating sane-looking reproducers (with non-empty create_code functions).
Are you calling gcc_jit_context_dump_reproducer_to_file before or after calling
gcc_jit_context_compile? (or when not calling gcc_jit_context_compile?) I
have a feeling that calling it after an unsuccessful compile might break it
("unsuccessful" in the sense of a compile that generates a non-fatal error but
doesn't crash the process).
Can you attach the result of gcc_jit_context_dump_reproducer_to_file to this
bug please?
Another thing to try might be to use gcc_jit_context_set_logfile and to attach
the resulting logfile (though you may need to flush it and close it and not
call gcc_jit_context_compile).
[Bug c++/95451] New: [8/9/10 regression] ICE for lambda capturing this and calling operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95451
Bug ID: 95451
Summary: [8/9/10 regression] ICE for lambda capturing this and
calling operator()
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max.kan...@nu-cost.com
Target Milestone: ---
The following legal code will lead to an Internal Compiler Error, see
https://godbolt.org/z/PoyMEL
struct A {
template
void function_with_lambda() {
[this](auto) {
/*this->*/operator()();
};
}
void operator()() {}
};
int main() {
A{}.function_with_lambda();
}
A simple workaround is explicitely adding "this->" before the function call.
This is familiar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86594, where
the same workaround prevents the ICE.
[Bug c++/95451] [8/9/10 regression] ICE for lambda capturing this and calling operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95451 --- Comment #1 from Max --- I just noted this is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480, although the other bug report neither mentions the workaround nor 86594. I guess I need to improve my search skills :/
[Bug ada/95452] New: Overflow Bug in GNAT Heapsort implementations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95452 Bug ID: 95452 Summary: Overflow Bug in GNAT Heapsort implementations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: cthowie at netzero dot net Target Milestone: --- TOOLCHAINS: GCC GNAT FSF 8.2 and 10.1 (perhaps also 9.2 and others (?), I have 8.2 and 10.1). ISSUE: All 3 "GNAT" implementations of Heapsort as found in the 'adainclude' directory have an arithmetic overflow bug. The affected files are: g-heasor.adb g-hesorg.adb g-hesora.adb REASON: in all 3 implementations, the nested subprogram called "Sift", inside the procedure "Sort", uses the following expression: Son := 2 * C; where "Son" and "C" are type "Positive". Note that in "g-heasor.adb" the expression is a variant with the same overflow problem: Son := C + C; Clearly, any integer type when doubled can overflow unless steps are taken to mitigate e.g., by doubling "C" using a wider type like a Long_Long_Integer and then comparing that with the surrounding loop termination condition (note that "Max", like "Son", is type Positive in the affected code): exit when Son > Max; In the current implementations, there is no check for this overflow, meaning Heapsort fails with a runtime exception under certain inputs, when it need not. The sort works if you trap the overflow and exit the loop. Thus the current implementation is broken for any arrays of length greater than Positive'Last / 2. EXAMPLE SOLUTION A solution could therefore be to change the loop body of "Sift" to something like the following: loop declare Two_C : constant Long_Long_Integer := 2 * Long_Long_Integer (C); pragma Suppress (All_Checks); -- It'll be safe to convert Two_C to Son if we get past -- the 'exit' check i.e., to take the lower precision integer -- value (here 32 bits from 64 bits) begin exit when Two_C > Long_Long_Integer (Max); Son := Positive (Two_C); end; if Son < Max then if Lt (Son, Son + 1) then Son := Son + 1; end if; end if; Move (Son, C); C := Son; end loop; Note that the three files cited don't have identical code with respect to checking for loop termination, but they have the same logical meaning i.e., in my 10.1 toolchains, "g-hesorg.adb" and "g-heasor.adb" use: Son := 2 * C; if Son < Max then if Lt (Son, Son + 1) then Son := Son + 1; end if; elsif Son > Max then -- termination is checked down here while "g-hesora.adb" uses the form I demonstrated in the above solution: loop Son := 2 * C; exit when Son > Max; -- termination is checked early if Son < Max and then Lt (Son, Son + 1) then Son := Son + 1; end if;
[Bug target/95453] New: Failure to avoid useless sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95453
Bug ID: 95453
Summary: Failure to avoid useless sign extension
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f2(int);
void f1(short x)
{
f2(x);
}
With -O3, GCC outputs this :
f1(short):
movsx edi, di
jmp f2(int)
LLVM outputs this :
f1(short): # @f1(short)
jmp f2(int) # TAILCALL
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #2 from bouanto at zoho dot com --- Created attachment 48648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48648&action=edit Reproducer for the bug Oh, I see what I was doing wrong: I thought it was an option, so I was calling this function at the beginning. Also, I had to comment the line creating the type GCC_JIT_TYPE_COMPLEX_DOUBLE in order for this reproducer to reproduce the issue. With that line, it does another error: libgccjit.so: error: gcc_jit_context_get_type: unrecognized value for enum gcc_jit_types: 21 That's probably another bug, though.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #3 from David Malcolm --- Aha - thanks. Re-reading https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging it looks like the documentation for these entrypoints could use some clarification on whether each one relates to the current state of the context, or whether it takes effect when the context is compiled.
[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92838 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug target/95453] Failure to avoid useless sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95453 Andrew Pinski changed: What|Removed |Added Keywords||ABI --- Comment #1 from Andrew Pinski --- What does the ABI say about argument passing of types which are sized less than int?
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-31 --- Comment #4 from Andrew Pinski --- (In reply to Pádraig Brady from comment #3) > I've not got a reduced example where clang is generating the call, but it > could be a linker issue as the two constructors are aliased to the same > address. > The linker used here was lld. Can you check using BFD LD or gold? And report back? And if it works with them, please file the bug against LLD instead.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-31 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from David Malcolm --- The reproducer you attached reproduces the crash from comment #0 for me; marking as ASSIGNED. (gdb) call debug(insn) (barrier 29 28 30)
[Bug c++/95454] New: type-level nodiscard not applied to constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95454
Bug ID: 95454
Summary: type-level nodiscard not applied to constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
The following does not warn for constructors. See https://godbolt.org/z/BTZwew.
```C++
struct [[nodiscard]] X {
int x;
X operator+() const { return *this; }
};
class [[nodiscard]] Y {
int y;
public:
Y operator+() const { return *this; }
};
void f()
{
X{};
Y{};
X x;
+x;
Y y;
+y;
}
```
[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #15 from Asher Gordon ---
(In reply to Luc Van Oostenryck from comment #14)
> I've now changed Sparse's default so that these warnings are not issued
> anymore.
Thanks Luc.
(In reply to Tom Tromey from comment #7)
> The feature was added specifically to mimic what sparse does.
> If sparse changes, I think changing gcc would be appropriate.
Now there are a few things to consider: GCC currently treats '{ 0 }' specially
for -Wmissing-field-initializers (and maybe other warnings too). So if GCC adds
an option, -Wuniversal-initializer, should '-Wmissing-field-initializers
-Wuniversal-initializer' warn on '{ 0 }' (assuming that the struct being
initialized has more than one member)? Or alternatively, should
-Wdesignated-init treat '{ 0 }' specially, and no -Wuniversal-initializer
should be added?
Also, how should '{ 0, }' be treated? Sparse does not treat this specially
(i.e., it warns on '{ 0, }' with -Wdesignated-init). However, GCC does treat '{
0, }' specially (like '{ 0 }') for -Wmissing-field-initializers. Personally, I
think that Sparse's is the better behavior, since people will very rarely do '{
0, }' to mean "init to zero", and when people do use '{ 0, }', they probably
mean "init first member to zero". But I don't have a strong opinion on this,
and I don't think any special effort should be taken to avoid treating '{ 0, }'
like '{ 0 }'.
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org, ||uros at gcc dot gnu.org Summary|Static assert going off on |[11 Regression] Static |MinGW |assert going off on MinGW --- Comment #3 from Thomas Koenig --- Adding the author of the patch. Uros: I find no discussion of this patch on the fortran mailing list. Please remember to do so in the future if you touch the libgfortran or gcc/fortran directories.
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #4 from Andrew Pinski --- Looks like: unsigned short int __cs_selector; - unsigned short int __opcode; + unsigned int __opcode:11; + unsigned int __unused4:5; For Windows ABI, the int causes the bitfield to start at the next 4byte alignment. Unlike Linux ABI. I suspect using unsigned short will fix the issue. NOTE clang might not implement the correct Windows ABI.
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Looks like: >unsigned short int __cs_selector; > - unsigned short int __opcode; > + unsigned int __opcode:11; > + unsigned int __unused4:5; > > For Windows ABI, the int causes the bitfield to start at the next 4byte > alignment. Unlike Linux ABI. > I suspect using unsigned short will fix the issue. NOTE clang might not > implement the correct Windows ABI. The Visual Windows ABI does say the following: a bit-field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field --- CUT --- So this is why the difference between Linux and Windows ABI comes into place. So I suspect Clang is wrong.
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #6 from Uroš Bizjak --- (In reply to Thomas Koenig from comment #3) > Adding the author of the patch. > > Uros: I find no discussion of this patch on the fortran mailing list. > Please remember to do so in the future if you touch the libgfortran > or gcc/fortran directories. Thomas, Contrary to my other libgfortran contribution, I was under the impression that the patch touches only deep architectural details of the x87 chip, and should be (and in fact is) independent of libgfortran implementation. I would like to point out that the part, referred in Comment #4 unifies the structure definition with the ones in libgcc soft-fp and libatomic. So, if this change turns out to be problematic for MinGW, then the existing definitions in libgcc in libatomic are wrong as well. Actually, libgcc sfp-machine.h defines: #ifdef __MINGW32__ /* Make sure we are using gnu-style bitfield handling. */ #define _FP_STRUCT_LAYOUT __attribute__ ((gcc_struct)) #endif which should probably be added to libgfortran fpu-387.h (and libatomic fenv.c).
[Bug c++/95087] [11 Regression] ICE in gimplify_expr, at gimplify.c:14382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95087 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:1bb808504643e6c3c0df0fdd68a941ed2a64c7f0 commit r11-758-g1bb808504643e6c3c0df0fdd68a941ed2a64c7f0 Author: Iain Sandoe Date: Sun May 31 20:30:10 2020 +0100 coroutines: Avoid functions with unlowered coroutine trees [PR95087]. Diagnosing bad uses of 'return' in coroutines is somewhat tricky, since the user can use the keyword before we know that the function is a coroutine (where such returns are not permitted). At present, we are just doing a check for any use of 'return' and erroring on that. However, we can't then pass the function body on, since it will contain unlowered coroutine trees. This avoids the issue by dropping the entire function body under that circumstance. We could do better (for 11) but this is intended to allow back-port of other fixes to 10. gcc/cp/ChangeLog: PR c++/95087 * coroutines.cc (morph_fn_to_coro): If we see an early fatal error, drop the erroneous function body. gcc/testsuite/ChangeLog: PR c++/95087 * g++.dg/coroutines/co-return-syntax-08-bad-return.C: Adjust the testcase to do the compile (rather than an -fsyntax-only parse).
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #7 from Uroš Bizjak --- Created attachment 48649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48649&action=edit Untested patch. Can someone with an access to MinGW target please test the attached patch? The layout is defined by the hardware, and gcc_struct reflects this layout. BTW: I also doubt defining _FP_STRUCT_LAYOUT in sfp-machine.h has any effect, we have to use __attribute__ ((gcc_struct)) directly on the structure definition.
[Bug target/95420] arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95420 --- Comment #2 from Iain Buclaw --- With some confidence, I'm going to say that the intended cpu that should have been set is "generic-armv7-a", and not "armv7-a".
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #35 from wschmidt at linux dot ibm.com ---
Hi Jeff,
Just a quick comment. We should never discuss raw runtimes of SPEC
benchmarks on Power hardware in public. It's okay to talk about
improvements (>12% in this case), but not wall clock time. Not a big
deal, but there are some legal reasons regarding SPEC that cause us to
be a little careful.
Thanks!
Bill
On 5/21/20 12:29 AM, guojiufu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
>
> --- Comment #26 from Jiu Fu Guo ---
> Had a test on spec2017 xz_r by changing the specified loop manually, on
> ppc64le.
>
> original loop (this loops occur three times in code):
> while (++len != len_limit)
> if (pb[len] != cur[len])
> break;
> changed to loop:
> typedef long long __attribute__((may_alias)) TYPEE;
>
>for(++len; len + sizeof(TYPEE) <= len_limit; len += sizeof(TYPEE)) {
> long long a = *((TYPEE*)(cur+len));
> long long b = *((TYPEE*)(pb+len));
> if (a != b) {
>break; //to optimize len can be move forward here.
>}
> }
>for (;len != len_limit; ++len)
> if (pb[len] != cur[len])
>break;
>
> We can see xz_r runtime improved from 433s to 382s(>12%).
> It would be very valuable to do this kind of widening reading/checking.
>
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #8 from Markus Böck --- Tested the above patch and the build failure is gone now
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #9 from Thomas Koenig --- (In reply to Uroš Bizjak from comment #6) > Thomas, > > Contrary to my other libgfortran contribution, I was under the impression > that the patch touches only deep architectural details of the x87 chip, and > should be (and in fact is) independent of libgfortran implementation. Well, that's what https://gcc.gnu.org/fortran/ states - please copy us in in the future. It makes more sense to have a simpler rule than to make exceptions for specific subdirectories. (You can, of course, also commit a change as "obvious and simple", but we'd also appreciate a note about this).
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151 Bug 95151 depends on bug 95444, which changed state. Bug 95444 Summary: Incorrect constraints on length operand in cmpstrnqi patterns https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug target/95444] Incorrect constraints on length operand in cmpstrnqi patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444 H.J. Lu changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- Invalid.
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151 H.J. Lu changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-May/546 ||919.html Depends on|95444 | --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546919.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444 [Bug 95444] Incorrect constraints on length operand in cmpstrnqi patterns
[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #8)
> I see no conversion there?
>
> But, why does it it store to memory at all?
Yes, no conversion for this case, only adjust_address to TImode. mem/c:TD means
a MEM cannot trap.
Reason of store to memory:
D.2914 is a local struct variable here, seems we need do some optimization to
sink the D.2914.td0 and D.2914.td1 from BB3&BB4 to BB5 to avoid store/load on
stack? Or if there already exists some pass in Gimple? Or should this be
optimized after expander by some new pass like store sink?
O2/pr70053.c.234t.optimized:
D256_add_finite (_Decimal128 a, _Decimal128 b, _Decimal128 c)
{
struct TDx2_t D.2914;
[local count: 1073741824]:
if (b_4(D) == c_5(D))
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072224]:
D.2914.td0 = c_5(D);
D.2914.td1 = c_5(D);
goto ; [100.00%]
[local count: 708669601]:
D.2914.td0 = a_3(D);
D.2914.td1 = b_4(D);
[local count: 1073741824]:
return D.2914;
}
[Bug ipa/93429] Missed IPA-CP on by-ref argument directly passed through from caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93429 --- Comment #1 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:32633ec815b4d741a9a4b1b75de235844f6d691c commit r11-763-g32633ec815b4d741a9a4b1b75de235844f6d691c Author: Feng Xue Date: Fri Jan 24 23:09:28 2020 +0800 Fix missed IPA-CP on by-ref argument directly passed through (PR 93429) 2020-06-01 Feng Xue gcc/ PR ipa/93429 * ipa-cp.c (propagate_aggs_across_jump_function): Check aggregate lattice for simple pass-through by-ref argument. gcc/testsuite/ PR ipa/93429 * gcc.dg/ipa/ipcp-agg-8.c: Change dump string. * gcc.dg/ipa/ipcp-agg-13.c: New test.
[Bug c++/95455] New: ICE in capture with initializer in requires block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455
Bug ID: 95455
Summary: ICE in capture with initializer in requires block
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bhalevy at gmail dot com
Target Milestone: ---
Created attachment 48650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48650&action=edit
Preprocessed source
Compiling the following code hits ICE, as follows:
testcase.cc:
void f() {
int foo;
requires () {
[bar = foo] {};
};
}
$ g++ --std=gnu++20 testcase.cc
testcase.cc: In function ‘void f()’:
testcase.cc:4:16: internal compiler error: Segmentation fault
4 | [bar = foo] {};
|^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccVYMnnA.out file, please attach this to
your bugreport.
