* Fix#21024 - Optimize x^^c expressions
Reason for the *magic* constraint c<8 on inlining x^^c:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/fpu/e_powl.S;h=47f129f34d368d7c67b8e5f2462b36b0bebb7621;hb=HEAD#l136
* Fix poor assumption about expression state
* Restrict optimization to floating point expressions
* Generalize optimization to any scalar data type
* Fix segfault on x^^c where x is a single member anonymous enum
DMD segfaulted on compiling the unittests in std/algorithm/sorting.o, the
unittest that caused the segfault can be reduced to:
enum real Two = 2.0;
auto _ = Two^^3;
I'm not sure why copying the anonymous enum into a `const` variable causes
the compiler to segfault.
* Add tests to x^^c inlining optimization
* Fix missing type for e1 ^^ -1 to 1 / e1 rewrite
* Move rewrites from constant folding to expression semantic and restrict them to [-1, 2]
* Improve error message for the x^^2 rewrite.
Before:
ex.d(4): Error: can implicitly convert expression `(const const(double) __powtmp2 = x + 5.0;) , __powtmp2 * ...` of type `double` to `int`
int y = ( x + 5 ) ^^ 2;
^
and after:
ex.d(4): Error: cannot implicitly convert expression `(x + 5.0) ^^ 2L` of type `double` to `int`
int y = ( x + 5 ) ^^ 2;
^
* Update C++ frontend header to match change in `CommaExp`
* Address code review feedback
Co-authored-by: Dennis Korpel <dkorpel@gmail.com>
---------
Co-authored-by: Dennis Korpel <dkorpel@gmail.com>
Objective-C Improvements
Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Dennis <dkorpel@users.noreply.github.com>
Commit a3abf1187e fixes some cases of
lambdas having unstable symbol names between compilation units by
using `generateIdWithLoc` to generate stable lambda names, however since
LOC doesn't uniquely identify a lambda instance (because templates,
mixins, static foreach and foreach unrolling), `generateIdWithLoc`
adds a counter, so there is still some instability going on.
`generateIdWithLoc` makes the name uniq per file+loc, by adding adding a
numeric suffix. But the order of instantiations might be different
across compilation units, so with this counting scheme we are back to
unstable names, so one module might have
`t!0.__lambda_LOC` and
`t!1.__lambda_LOC_1`
while another one has
`t!1.__lambda_LOC`
This is not a critical problem, but at very least the code gets
duplicated for no reason. I also have an example where it leads to
linking error, but since it's not a small one and fails to minimize
further, I suspect it's a result of interaction with some other bug.
The thing is we don't even need uniqueness for those lambdas inside
templates/mixins: their final names will have the instantiation prefix anyway.
But we can't also just disable this uniqueness check completely: `static
foreach` as well as unrollings of the normal `foreach` with lambdas in
the loop body will have several copies of a single lambda with the same
file+loc. So here we do want to keep making them unique. Fortunately, I
don't think a `foreach` could be iterated in different order in
different compilation units, so hopefully if we limit the counting to
this case only, it won't make symbols unstable.
To implement this idea, I've added an extra `parent` argument to
`generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but
without adding `parent` to the final output.
Fixes since last review:
1. Changed `fromStringz` to `toDString`
2. Added a test to showcase the problem
Commit a3abf1187e fixes some cases of
lambdas having unstable symbol names between compilation units by
using `generateIdWithLoc` to generate stable lambda names, however since
LOC doesn't uniquely identify a lambda instance (because templates,
mixins, static foreach and foreach unrolling), `generateIdWithLoc`
adds a counter, so there is still some instability going on.
`generateIdWithLoc` makes the name uniq per file+loc, by adding adding a
numeric suffix. But the order of instantiations might be different
across compilation units, so with this counting scheme we are back to
unstable names, so one module might have
`t!0.__lambda_LOC` and
`t!1.__lambda_LOC_1`
while another one has
`t!1.__lambda_LOC`
This is not a critical problem, but at very least the code gets
duplicated for no reason. I also have an example where it leads to
linking error, but since it's not a small one and fails to minimize
further, I suspect it's a result of interaction with some other bug.
The thing is we don't even need uniqueness for those lambdas inside
templates/mixins: their final names will have the instantiation prefix anyway.
But we can't also just disable this uniqueness check completely: `static
foreach` as well as unrollings of the normal `foreach` with lambdas in
the loop body will have several copies of a single lambda with the same
file+loc. So here we do want to keep making them unique. Fortunately, I
don't think a `foreach` could be iterated in different order in
different compilation units, so hopefully if we limit the counting to
this case only, it won't make symbols unstable.
To implement this idea, I've added an extra `parent` argument to
`generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but
without adding `parent` to the final output.
Fixes since last review:
1. Changed `fromStringz` to `toDString`
2. Added a test to showcase the problem
* Document template instance duplication status as part of its field documentation. (#16643)
* Fix Bugzilla 24599 - Wrongly elided TypeInfo emission (#15868)
Reverting #14844, which caused such missing TypeInfos, *and* making
sure the special TypeInfo members are fully analyzed and ready for
codegen (otherwise hitting an assertion for the real-world project).
* Reorganize backend build files to match target and make more similar per line (#16672)
* Remove redundant suggestions on linker errors (#16711)
* Fix bugzilla 24337 - Segfault when printing an int[] cast from a string (#16729)
* Add BitFieldStyle.Gcc_Clang_ARM
Required for 32-bit ARM, and non-Apple 64-bit ARM targets.
The only difference to `Gcc_Clang` is that anonymous and 0-length
bit-fields do contribute to the aggregate alignment.
Caught by existing proper C interop tests in
runnable_cxx/testbitfields.d on such targets. The hardcoded bad tests
in runnable/{bitfieldsposix64.c,dbitfieldsposix64.d} however now fail
after the fix, on such targets again.
* [refactor to `TargetC.contributesToAggregateAlignment(BitFieldDeclaration)` hook]
* Fix Bugzilla Issue 24687 - [REG2.110] Cannot cast string-imports to select overload anymore
* Also make deprecationSupplemental adhere to error limit (#16779)
Co-authored-by: Dennis Korpel <dennis@sarc.nl>
* Fix bugzilla 24699 - [REG2.108] No short-circuit evaluation of mixing template bool argument
* Fix bugzilla 24731 - IFTI cannot handle integer expressions (#16822)
* Fix Bugzilla Issue 24760 - ICE on variadic after default argument
* Fix bugzilla 24790 - -vcg-ast ICE on lowered assign exp (#16914)
Co-authored-by: Dennis Korpel <dennis@sarc.nl>
* Fix bugzilla 24764 - ICE when -vcg-ast prints imported invariant (#16917)
Co-authored-by: Dennis Korpel <dennis@sarc.nl>
* Fix bugzilla 24431 - dmd -vcg-ast crashes printing failed template in… (#16916)
---------
Co-authored-by: Richard (Rikki) Andrew Cattermole <richard@cattermole.co.nz>
Co-authored-by: Martin Kinkelin <kinke@users.noreply.github.com>
Co-authored-by: Dennis <dkorpel@users.noreply.github.com>
Co-authored-by: Martin Kinkelin <mkinkelin@symmetryinvestments.com>
Co-authored-by: Martin Kinkelin <noone@nowhere.com>
Co-authored-by: RazvanN7 <razvan.nitu1305@gmail.com>
Co-authored-by: Dennis Korpel <dennis@sarc.nl>
Co-authored-by: Dennis Korpel <dkorpel@gmail.com>
Fix Bugzilla 24701 - No error produced from casted noreturn variable
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
