[Bug target/90952] Costs of moves are used for costs of RTL expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90952 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- In the latest gcc version(GCC10_20190820), there's no difference in unroll factor when applying this patch. But still there's difference in Profitability threshold which changes from 5 to 4. That means if loop count less than Profitability threshold, it won't trigger vectorization. So if loop count is 4, runtime performance would be different otherwise they will be the same.
[Bug fortran/91519] [10 Regression] ICE error in 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519 --- Comment #13 from Hongtao.liu --- (In reply to Thomas Koenig from comment #12) > https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg02751.html shows that > 521.wrf_r is no longer failing. > > Closing as fixed. Yes, thank you. By the way, there's new fail in 527.cam4_r due to type mismatch. Using -std=legacy can make it successfully built.
[Bug fortran/91544] New: When initializing allocatable character array get "Error: size of variable 'A.0' is too large"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91544 Bug ID: 91544 Summary: When initializing allocatable character array get "Error: size of variable 'A.0' is too large" Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- If use a non-constant integer as the length for an allocatable character variable array get a confusing error message. If the integer LINE_LENGTH is a PARAMETER it works. A work-around where the array is first allocated as a zero-size array and then included in the assignment works. Otherwise get an odd compile-time error about "A.0" being too large. program testit implicit none integer :: line_length=50 character(len=:),allocatable :: test_in(:) #ifdef BAD test_in=[ character(len=line_length) :: 'aaa','bb' ] #else allocate(character(len=line_length) :: test_in(0)) test_in=[character(len=line_length) :: test_in,'aaa','bb'] #endif write(*,*)test_in end program testit gfortran -UBAD xx.F90 aaa bb gfortran -DBAD xx.F90 xx.f90:4:0: test_in=[ character(len=line_length) :: 'this is a test' ] Error: size of variable 'A.0' is too large
[Bug middle-end/91512] [10 Regression] Fortran compile time regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #18 from Sunil Pandey ---
(In reply to Thomas Koenig from comment #17)
> Simply passing on a huge number of arguments is not enough to trigger this.
>
> Here's a perl script to generate test cases:
>
> while ($n=shift)
> {
> open FOO, ">foo-$n.f90";
>
> print FOO < module foo
> implicit none
> contains
> EOF
>
> print FOO "subroutine foo_proc";
> for ($i=0; $i<$n; $i++)
> {
> push (@var, "a" . sprintf("%3.3d", $i));
> }
>
> @call = ();
> push (@call, "(");
>
> for ($i=0; $i<$n-1; $i++)
> {
> push (@call, "&\n ") if ($i%10 == 0);
> push (@call, $var[$i] . ", ");
> }
> push (@call, $var[$n-1],")\n");
> print FOO @call;
>
> for ($i=0; $i<$n; $i++)
> {
> print FOO " real, dimension(:,:) :: $var[$i]\n";
> }
>
> print FOO " call bar";
> print FOO @call;
> print FOO " end subroutine\n";
> print FOO "end module\n";
> }
>
> Running this script with
>
> for a in 50 100 200 500 1000; do perl gener.pl $a; echo -n "$a ";
> /usr/bin/time -f "%e %M" gfortran -c -O2 foo-$a.f90; done
>
> gave me
>
> 50 3.21 272668
> 100 8.44 581860
> 200 20.15 1046780
> 500 52.32 1208684
> 1000 167.43 3493456
>
> so the CPU time does not come close to what is reported here.
> Memory use is quite high, though.
>
> What is the memory footprint of the compilation? Is your machine possibly
> starting to swap?
My system has plenty of memory. I don't think it's swapping issue. Here is
memory profile for before and after commit.
Before commit:
==
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release.a4ba5c3ec624008e899a8bcb687359db25140c23/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O3 -march=skylake -funroll-loops
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
41.88 214612
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release.a4ba5c3ec624008e899a8bcb687359db25140c23/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O3 -march=skylake
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
40.88 214716
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release.a4ba5c3ec624008e899a8bcb687359db25140c23/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O2 -march=skylake
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
40.38 214652
After commit:
=
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O3 -march=skylake -funroll-loops
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
1548.42 10111860
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O3 -march=skylake
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
1088.74 2924072
$ /usr/bin/time -f "%e %M"
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release/usr/gcc-10.0.0-x86-64/bin/gfortran
-m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O2 -march=skylake
-fconvert=big-endian module_first_rk_step_part1.fppized.f90
544.56 3129568
[Bug target/37073] -fno-math-errno should be the default on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37073 Gerald Pfeifer changed: What|Removed |Added Status|ASSIGNED|NEW CC||andreast at gcc dot gnu.org Assignee|gerald at pfeifer dot com |unassigned at gcc dot gnu.org --- Comment #5 from Gerald Pfeifer --- (In reply to Eric Gallager from comment #4) > Assuming yes and making Gerald the assignee I thought I had a plan, alas it did not work out. So returning to the pool. Perhaps Andreas T. has got an idea - copying him.
[Bug libfortran/91543] New: Handling stack overflow more sensibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543 Bug ID: 91543 Summary: Handling stack overflow more sensibly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- I've just been bitten by a strange segfault, which turned out to be due to insufficient stack space with -Ofast (running nf from the Polyhedron benchmarks). We really need a sensible error message when that happens. "Insufficient stack space, aborting\n" would already be enough. Of course, not every segmentation violation is a stack overflow :-| So, a strategy could be: On startup, prepare a heap buffer with a sensible error message. Also, stash away the starting address of the stack, its size and other pertinent information, and set up a signal handler for SIGSEGV using sigalstack(). On receiving a SIGSEGV, we could check if the segfaulting address is indeed near the end of the stack, and if that is the case, just do a write(2,...) with our prepared error message and exit. Otherwise, just do the normal thing (usually, abort). We could also increase the stack size, to avoid hitting that particular error too soon. What do people think?
[Bug target/91533] abs pattern generates MMX instructions but fails to call EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91533 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.3 |7.4 --- Comment #5 from Uroš Bizjak --- Fixed for gcc-7.4+.
[Bug target/91533] abs pattern generates MMX instructions but fails to call EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91533 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Sun Aug 25 19:51:45 2019 New Revision: 274914 URL: https://gcc.gnu.org/viewcvs?rev=274914=gcc=rev Log: PR target/91533 Backport from mainline 2019-06-30 Uroš Bizjak * config/i386/sse.md (ssse3_abs2): Rename from abs2. * config/i386/i386-builtin.def (__builtin_ia32_pabsb): Use CODE_FOR_ssse3_absv8qi2. (__builtin_ia32_pabsw): Use CODE_FOR_ssse3_absv4hi2. (__builtin_ia32_pabsd): Use CODE_FOR_ssse3_absv2si2. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386-builtin.def branches/gcc-7-branch/gcc/config/i386/sse.md
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 --- Comment #16 from Iain Sandoe --- fixed for 8.4
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 --- Comment #15 from Iain Sandoe --- Author: iains Date: Sun Aug 25 19:31:47 2019 New Revision: 274913 URL: https://gcc.gnu.org/viewcvs?rev=274913=gcc=rev Log: [Darwin, fixincludes] Backport fix for PR83531 There is no reasonable chance that the SDKs in question will be re- issued, so the only viable solution is a fixincludes. 2019-08-24 Iain Sandoe Backport from mainline. 2019-08-18 C.G. Dogan Iain Sandoe PR target/83531 * inclhack.def (darwin_api_availability): New; strip leading underscores from API_ defines. * fixincl.x: Regenerate. * tests/base/os/availability.h: New file. Added: branches/gcc-8-branch/fixincludes/tests/base/os/availability.h Modified: branches/gcc-8-branch/fixincludes/ChangeLog branches/gcc-8-branch/fixincludes/fixincl.x branches/gcc-8-branch/fixincludes/inclhack.def
[Bug c++/91529] [8/9/10 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #2 from Nicholas Krause --- I was unable to find the proper marcos to fix the issue for this patch in the manual. However these lines: - /* FIXME P0135 doesn't say how to handle direct initialization from a -type with a suitable conversion operator. Let's handle it like -copy-initialization, but allowing explict conversions. */ - tsubst_flags_t sub_complain = tf_warning; - if (!is_dummy_object (instance)) - /* If we're using this to initialize a non-temporary object, don't - require the destructor to be accessible. */ - sub_complain |= tf_no_cleanup; if (BRACE_ENCLOSED_INITIALIZER_P (arg) - && !CONSTRUCTOR_IS_DIRECT_INIT (arg)) - /* An init-list arg needs to convert to the parm type (83937), so fall - through to normal processing. */ - arg = error_mark_node; - else if (!reference_related_p (class_type, TREE_TYPE (arg))) - arg = perform_implicit_conversion_flags (class_type, arg, -sub_complain, -flags); + && !TYPE_HAS_LIST_CTOR (class_type) + && CONSTRUCTOR_NELTS (arg) == 1) + arg = CONSTRUCTOR_ELT (arg, 0)->value; + or the ones added with a + seem to be the issue. Why are we not checked for initializing references in braces and not checked if its direct as those should be done regularly for inlining in normal processing. Maybe I'm missing something but this seems odd. A lot of the other parts of the patch just seems to be rewrites so this seems most likely.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #34 from Iain Sandoe --- Author: iains Date: Sun Aug 25 19:27:04 2019 New Revision: 274912 URL: https://gcc.gnu.org/viewcvs?rev=274912=gcc=rev Log: [Darwin, Driver] Fix driver crashes with valid command line input. Backport Improve processing of macosx-version-min= For PR target/63810 some improvements were made in the parsing of the version string at the point it's used to define the built-in __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. This is fine, but the specs processing also uses the version, and specs version-compare doesn't like leading zeros on components. This means that while we succeed in processing -mmacosx-version-min=010.2.99 on compile lines, it fails for any other line that uses the value as part of a spec (in particular, link lines fail). To fix this, we need to apply a bit of clean-up to the version that's presented to the driver, and push that back into the command line opts. The value can come from four places: 1. User-entered on the command line 2. User-entered as MACOSX_DEPLOYMENT_TARGET= environment var. 3. Absent those two 3a For self-hosting systems, look-up from the kernel 3b For cross-compilers, as a default supplied at configure time. We apply the clean-up to all 4 (although it shouldn't really be needed for the cases under 3). We also supply a test-case that adapts to the target-version of the system, so that the link requirements are met by the SDK in use (if you try to link i686-darwin9 on an x86-64-darwin18 SDK, it will fail). gcc/ 2019-08-25 Iain Sandoe Backport from mainline 2019-06-19 Iain Sandoe * config/darwin-driver.c (darwin_driver_init): Fix off-by-one errors in computing the number of options to be moved. Backport from mainline 2019-06-13 Iain Sandoe * config/darwin-driver.c (validate_macosx_version_min): New. (darwin_default_min_version): Cleanup and validate supplied version. (darwin_driver_init): Likewise and push cleaned version into opts. gcc/testsuite/ 2019-08-25 Iain Sandoe 2019-06-13 Iain Sandoe * gcc.dg/darwin-minversion-link.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/darwin-minversion-link.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/darwin-driver.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/30609] Calculating masks twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609
--- Comment #5 from Thomas Koenig ---
The problem with the test case is that both sum and count
are transformational functions, i.e. they reduce the
rank.
So, ideally this would be translated into
real sum = 0.;
int count = 0;
for (i=0; i 0) {
count ++;
sum += a[i];
}
}
return sum / count;
but the scalarizer does not do that (currently), and neither
does the middle end. It would require loop fusion.
So, it is probably not useful to do common subexpression
elimination for rank>0 expressions if they are the arguments
of transformational functions.
[Bug target/91533] abs pattern generates MMX instructions but fails to call EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91533 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Aug 25 18:24:01 2019 New Revision: 274911 URL: https://gcc.gnu.org/viewcvs?rev=274911=gcc=rev Log: PR target/91533 Backport from mainline 2019-06-30 Uroš Bizjak * config/i386/sse.md (ssse3_abs2): Rename from abs2. * config/i386/i386-builtin.def (__builtin_ia32_pabsb): Use CODE_FOR_ssse3_absv8qi2. (__builtin_ia32_pabsw): Use CODE_FOR_ssse3_absv4hi2. (__builtin_ia32_pabsd): Use CODE_FOR_ssse3_absv2si2. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386-builtin.def branches/gcc-8-branch/gcc/config/i386/sse.md
[Bug target/91533] abs pattern generates MMX instructions but fails to call EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91533 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Sun Aug 25 18:21:04 2019 New Revision: 274910 URL: https://gcc.gnu.org/viewcvs?rev=274910=gcc=rev Log: PR target/91533 Backport from mainline 2019-06-30 Uroš Bizjak * config/i386/sse.md (ssse3_abs2): Rename from abs2. * config/i386/i386-builtin.def (__builtin_ia32_pabsb): Use CODE_FOR_ssse3_absv8qi2. (__builtin_ia32_pabsw): Use CODE_FOR_ssse3_absv4hi2. (__builtin_ia32_pabsd): Use CODE_FOR_ssse3_absv2si2. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/i386/i386-builtin.def branches/gcc-9-branch/gcc/config/i386/sse.md
[Bug c/91542] internal representation of pointer reference shown in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91542
--- Comment #1 from ldrumm at rtps dot co ---
Sorry. I clicked submit too soon.
Interestingly if the index operation is a constant (but not a constant
expression), the error message is correct
```
struct Node {
int n_successors;
};
int foo(int n, struct Node *nodes[])
{
enum {a};
nodes[a].n_successors;
}
/home/luke/code/cc/src/gcc-bug.c:8:13: error: ‘*nodes’ is a pointer; did you
mean to use ‘->’?
8 | nodes[a].n_successors;
| ^
| ->
```
but with a more complex expression (but still an ICE):
```
struct Node {
int n_successors;
};
int foo(int n, struct Node *nodes[])
{
enum {a = 1};
nodes[a << 2].n_successors;
}
/home/luke/code/cc/src/gcc-bug.c:8:18: error: ‘*(nodes + 32)’ is a pointer; did
you mean to use ‘->’?
8 | nodes[a << 2].n_successors;
| ^
| ->
```
I see this behaviour on current top of tree built from source
(e86f87930567b7e5444260ffc1d46507ebc8f520) as well as the debian-packaged
version shipped with my OS ((Debian 9.2.1-4) 9.2.1 20190821)
I'm willing to help debug this one, but I'm unfamiliar with the code, so I'd
appreciate any guidance
[Bug c/91542] New: internal representation of pointer reference shown in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91542
Bug ID: 91542
Summary: internal representation of pointer reference shown in
error message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ldrumm at rtps dot co
Target Milestone: ---
Created attachment 46750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46750=edit
reduced-testcase.c
Printing an error message for an invalid use of struct member access in a
pointer context is incorrectly printing the internal representation of the
pointer expression
```c
struct Node {
int n_successors;
};
int foo(int n, struct Node *nodes[])
{
nodes[n].n_successors; // `n_successors` should be accessed through a
struct dereference expression.
}
```
Using built-in specs.
COLLECT_GCC=./build/bin/gcc
COLLECT_LTO_WRAPPER=/home/luke/code/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-bootstrap --enable-languages=c
--prefix=/home/luke/code/gcc/build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190824 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c99' '-mtune=generic'
'-march=x86-64'
/home/luke/code/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -E -quiet
-v -imultiarch x86_64-linux-gnu /home/luke/code/cc/src/gcc-bug.c -mtune=generic
-march=x86-64 -std=c99 -fpch-preprocess -o gcc-bug.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/luke/code/gcc/build/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/luke/code/gcc/build/lib/gcc/x86_64-pc-linux-gnu/10.0.0/include
/usr/local/include
/home/luke/code/gcc/build/include
/home/luke/code/gcc/build/lib/gcc/x86_64-pc-linux-gnu/10.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c99' '-mtune=generic'
'-march=x86-64'
/home/luke/code/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/cc1
-fpreprocessed gcc-bug.i -quiet -dumpbase gcc-bug.c -mtune=generic
-march=x86-64 -auxbase gcc-bug -std=c99 -version -o gcc-bug.s
GNU C99 (GCC) version 10.0.0 20190824 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.1 20190821, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C99 (GCC) version 10.0.0 20190824 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.1 20190821, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c4c9fdc5350b445a18baa11b2b776373
/home/luke/code/cc/src/gcc-bug.c: In function ‘foo’:
/home/luke/code/cc/src/gcc-bug.c:7:13: error: ‘*(nodes + (sizetype)((long
unsigned int)n * 8))’ is a pointer; did you mean to use ‘->’?
7 | nodes[n].n_successors;
| ^
| ->
[Bug fortran/30609] Calculating masks twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Let's see. We could do this like the function elimination pass, making a list of eligible gfc_expr *, and then iterating over it to find duplicates. If we put in the gfc_expr * from top to bottom, this should also make sure that we find any bigger expressions before smaller expressions.
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541 --- Comment #1 from frankhb1989 at gmail dot com --- Allocator-extended constructors with explicit exception specifications may also have the value_type/node mismatch problems.
[Bug libstdc++/91541] New: [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
Bug ID: 91541
Summary: [C++17] Exception specification of operator= of
node-based containers may be broken
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
#include
#include
struct A : std::allocator>
{
template
struct rebind
{
using other = std::pmr::polymorphic_allocator;
};
};
int main()
{
using always_equal = std::allocator_traits::is_always_equal;
using C = std::less<>;
constexpr bool std_nothrow = always_equal::value &&
std::is_nothrow_move_assignable_v;
static_assert(std_nothrow);
static_assert(!(std_nothrow &&
!std::is_nothrow_move_assignable>::value));
}
The defaulted exception specification is from _Rb_tree which uses node
allocator traits instead of the allocator_traits, so
is_always_equal::value can differ than expected.
There is a similar problem in list/forward_list::operator='s implementations:
they use the node allocator_traits explicitly, not the required exception
specification by the standard.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #29 from Yichao Yu --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412#c25 GCC is fully capable of aligning the stack. It just seems that different part of it disagrees on what the current stack alignment is and whether a realignment is needed.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
John Platts changed:
What|Removed |Added
CC||john_platts at hotmail dot com
--- Comment #28 from John Platts ---
The correct way to align the stack to a 32-byte or 64-byte boundary on 64-bit
Windows is to use a frame pointer in a function that requires stack realignment
and then realign the stack to the required alignment once the frame pointer is
set and all of the non-volatile registers used in the function are saved.
class Avx2VectorGenerator {
public:
virtual __m256i NextVector() = 0;
};
__m256i Example_AVX2_Func(Avx2VectorGenerator* generator, size_t iterations);
Example_AVX2_Func:
pushq %rbp
.seh_pushreg %rbp
pushq %rbx
.seh_pushreg %rbx
pushq %rdi
.seh_pushreg %rdi
movq %rsp, %rbp
.seh_setframe %rbp, 0
.seh_endprologue
/* Set rbx to generator and rdi to iterations */
movq %rcx, %rbx
movq %rdx, %rdi
/* It is okay to allocate additional stack memory */
/* and re-align the stack pointer outside of the */
/* SEH prologue as there is a frame pointer in this */
/* function */
subq $64, %rsp
andq $-32, %rsp
/* Zero out the result vector */
vpxor %ymm0, %ymm0, %ymm0
test %rdi, %rdi
jz .loop_complete
.loop_iteration_start:
/* Save the result vector to 32(%rsp) */
vmovdqa 32(%rsp), ymm0
/* Move generator into rcx */
movq %rbx, %rcx
/* Move the pointer to the NextVector() virtual member func */
/* into rax */
movq (%rbx), %rax
/* Call generator->NextVector() */
call *(%rax)
/* Add the result of generator->NextVector() to the result vector */
vpaddb 32(%rsp), %ymm0, %ymm0
/* Decrement iterations by 1 */
sub $1, %rdi
/* Jump back to the beginning of the loop if iterations is non-zero */
jnz .loop_iteration_start
.loop_complete:
lea (%rbp), %rsp
pop %rdi
pop %rbx
pop %rbp
ret
.seh_endproc
[Bug fortran/91519] [10 Regression] ICE error in 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg02751.html shows that 521.wrf_r is no longer failing. Closing as fixed.
