[Bug c++/84493] [8 Regression] ICE with invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84493
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-21
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |8.0
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed, I think this is the fix:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21925,7 +21925,7 @@ cp_parser_braced_list (cp_parser* parser, bool*
non_constant_p)
/* Consume the `{' token. */
matching_braces braces;
- braces.consume_open (parser);
+ braces.require_open (parser);
/* Create a CONSTRUCTOR to represent the braced-initializer. */
initializer = make_node (CONSTRUCTOR);
/* If it's not a `}', then there is a non-trivial initializer. */
[Bug fortran/84487] [8 Regression] Large rodate section increase in 465.tonto with r257233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 --- Comment #4 from Martin Liška --- Created attachment 43477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43477&action=edit Reproducer $ gcc-7 -O2 -g -march=native -mtune=native -std=legacy types.f90 -o before.o -c $ gcc -O2 -g -march=native -mtune=native -std=legacy types.f90 -o after.o -c $ bloaty after.o -- before.o VM SIZEFILE SIZE ++ GROWING ++ +11e2% +35.5Ki .rodata +35.5Ki +11e2% [ = ] 0 .rela.debug_info +96 +0.2% [ = ] 0 .debug_loc +64 +8.1% [ = ] 0 .rela.text +48 +5.4% [ = ] 0 .debug_str +28 +0.5% +0.5% +16 .text+16 +0.5% +0.6% +8 .eh_frame +8 +0.6% [ = ] 0 .debug_line +1 +0.6% -- SHRINKING-- [DEL] -31.8Ki .bss 0 [ = ] [ = ] 0 .debug_info -27 -0.3% [ = ] 0 .comment -23 -35.4% [ = ] 0 [Unmapped] -16 -45.7% [ = ] 0 .debug_abbrev -3 -0.9% +9.6% +3.79Ki TOTAL+35.7Ki +43% It's sample where it increases approximately 10x.
[Bug c++/84493] [8 Regression] ICE with invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84493 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #13 from Martin Liška --- Created attachment 43440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43440&action=edit Parallel build of make all-host on 128 core EPYC machine --- Comment #14 from Martin Liška --- Created attachment 43478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43478&action=edit -ftime-report for most time consuming files on Haswell machine
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Martin Liška changed: What|Removed |Added CC||hubicka at ucw dot cz, ||rguenth at gcc dot gnu.org Target Milestone|--- |9.0
[Bug c++/84401] Misleading error message when running out of RAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84401 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Should be fixed starting with r251104.
[Bug c++/84496] New: Internal compiler error with lambda, static and auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496
Bug ID: 84496
Summary: Internal compiler error with lambda, static and auto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: damienrg+list at gmail dot com
Target Milestone: ---
The following code produces an internal compiler error with g++ (7.3.0):
#include
void foo(std::function fun)
{}
int main()
{
const auto f = []() {
static int counter = 0;
foo([](auto) { return counter; });
};
}
[Bug target/84482] 437.leslie3d regresses on Haswell and SandyBridge at -O3 and -Ofast with generic march and tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84482 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can confirm that, I see that also on train size. Let me try to run my bisection script.
[Bug c++/84494] Invalid constexpr with default assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84494 Marek Polacek changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, clang++ prints 10 10. Started with r233956, before that it was rejected: error: explicitly defaulted function ‘constexpr X& X::operator=(const X&)’ cannot be declared as constexpr because the implicit declaration is not constexpr:
[Bug target/84482] 437.leslie3d regresses on Haswell and SandyBridge at -O3 and -Ofast with generic march and tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84482 Martin Liška changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from Martin Liška --- I see one big regression in between: 4a57ae2569fba9cf(17 Nov 2017 17:53): [took: 60.695s] result: FAILED (1) 437.leslie3d -- 35.7 -- S SVN revision: 254889 Author: hubicka * i386.c (ix86_multiplication_cost, ix86_division_cost, ix86_shift_rotate_cost): Break out from ... (ix86_rtx_costs): ... here. (ix86_add_stmt_cost): Use rtx cost machinery to compute cost of vector operations. * gcc.target/i386/xop-imul64-vector.c: Disable vectorizer costmodel. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@254889 138bc75d-0d04-0410-961f-82ee72b054a4 7ae0128a031e2fd2(17 Nov 2017 17:47): [took: 55.618s] result: OK 437.leslie3d -- 30.5 -- S SVN revision: 254888 Author: hubicka * predict.c (determine_unlikely_bbs): Set cgraph node count to 0 when entry block was promoted unlikely. (estimate_bb_frequencies): Increase frequency scale. * profile-count.h (profile_count): Export precision info. * gcc.dg/tree-ssa/dump-2.c: Fixup template for profile precision changes. * gcc.dg/tree-ssa/pr77445-2.c: Fixup template for profile precision changes. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@254888 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #2 from Pádraig Brady --- This is an issue with gcc 5.3.1 This is _not_ an issue with gcc 6.3.1 or gcc 7.3 I'm thinking this was addressed in the significant refactoring for bug #66653
[Bug c++/43064] improve location and text of Wconversion warning for initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 --- Comment #2 from Jonny Grant --- I'll offer $100 bug-bounty for this
[Bug c++/84497] New: link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Bug ID: 84497
Summary: link errors with trivial external thread_local
variables
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
In some cases extern thread_local vars will generate a reference
to a tls_init function, when there is none generated for the translation unit
defining the variable, essentially due to it being std::is_trivial.
This used to work with gcc-5.3.1 and gcc-6.3.1,
the reason being that they were less efficient and
always exported the tls_init function, even for these std::is_trivial vars.
With gcc-7 the tls_init function is not emitted for these types,
but there is a mismatch in the logic determining if the extern thread_local
should call the tls_init function.
Specifically, in the module local to the var
if DECL_NONTRIVIALLY_INITIALIZED_P is false
then the tls_init function is not generated.
However in a translation unit that references such
an extern tls variable and TYPE_NEEDS_CONSTRUCTING is true
then a non weak call to the tls_init function is generated,
resulting in a link error.
$ cat a.cpp
#include
struct Test { std::atomic x; };
thread_local Test t;
$ cap main.cpp
#include
struct Test { std::atomic x; };
extern thread_local Test t;
int main() {
return t.x.load();
}
$ g++ -std=c++11 a.cpp main.cpp
/tmp/ccvPDpE2.o: In function `TLS wrapper function for t':
main.cpp:(.text._ZTW1t[_ZTW1t]+0x5): undefined reference to `TLS init function
for t'
collect2: error: ld returned 1 exit status
[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #28 from Martin Liška ---
(In reply to Martin Liška from comment #27)
> Let me decrypt how clang generates the red zones. I can probably quickly
> come up with a patch that will do the dynamic red zone size allocation.
> Having that you'll be able to rebuild kernel and catch remaining issues.
So the functions looks as follows:
static size_t VarAndRedzoneSize(size_t Size, size_t Granularity,
size_t Alignment) {
size_t Res = 0;
if (Size <= 4) Res = 16;
else if (Size <= 16) Res = 32;
else if (Size <= 128) Res = Size + 32;
else if (Size <= 512) Res = Size + 64;
else if (Size <= 4096) Res = Size + 128;
else Res = Size + 256;
return alignTo(std::max(Res, 2 * Granularity), Alignment);
}
It's bit confusing as it's size of variable plus red zone in shadow memory. So
to calculate just the size of redzone one has to subtract Size. And there's
some rounding up according to alignment.
I've prepared table with size of variable and corresponding middle end red zone
size:
+---+-+--+-+
| Variable size | GCC | LLVM | ratio |
+---+-+--+-+
| 1 | 63 | 15 | 23.81% |
| 4 | 60 | 12 | 20.00% |
| 8 | 56 | 24 | 42.86% |
|12 | 52 | 20 | 38.46% |
|16 | 48 | 16 | 33.33% |
|32 | 32 | 32 | 100.00% |
|40 | 56 | 40 | 71.43% |
|50 | 46 | 46 | 100.00% |
|64 | 32 | 32 | 100.00% |
|96 | 32 | 32 | 100.00% |
| 128 | 32 | 32 | 100.00% |
| 129 | 63 | 79 | 125.40% |
| 196 | 60 | 76 | 126.67% |
| 256 | 32 | 64 | 200.00% |
| 257 | 63 | 79 | 125.40% |
| 511 | 33 | 65 | 196.97% |
| 512 | 32 | 64 | 200.00% |
| 1024 | 32 | 128 | 400.00% |
| 1025 | 63 | 143 | 226.98% |
| 2048 | 32 | 128 | 400.00% |
| 4096 | 32 | 128 | 400.00% |
| 8192 | 32 | 256 | 800.00% |
+---+-+--+-+
As seen (and mentioned by you), for small variables we have bigger red zones.
[Bug c++/84497] link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497 --- Comment #1 from Pádraig Brady --- Created attachment 43479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43479&action=edit Proposed patch and testcase. This passes the full testsuite
[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Feb 21 10:35:46 2018 New Revision: 257870 URL: https://gcc.gnu.org/viewcvs?rev=257870&root=gcc&view=rev Log: PR tree-optimization/84478 * gimple-fold.h (get_range_strlen): Add a bool argument defaulted to false. * gimple-fold.c (get_range_strlen): Make minlen const and assume it can't be NULL. Change FUZZY from bool to int, for 1 add PHI/COND_EXPR support which is conservatively correct, for 2 only stay conservative for maxlen. Formatting and comment capitalization fixes. Add STRICT argument to the 2 argument get_range_strlen, adjust 6 arg get_range_strlen caller and clear minmaxlen[0] and [1] if it returned false. (get_maxval_strlen): Adjust 6 arg get_range_strlen caller. (gimple_fold_builtin_strlen): Pass true as last argument to get_range_strlen. * gcc.c-torture/execute/pr84478.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr84478.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/testsuite/ChangeLog
[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404 --- Comment #6 from Alexandre Oliva --- Patch posted https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01224.html
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- This looks like a duplicate of PR81116, fixed by r251125. This is not a regression, and in genereal (we have played loose with this rule) we are not supposed to backport. Opinions?
[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/84480] Unexpected -Wstringop-truncation on strncpy with string literal at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 --- Comment #1 from Romain Geissler --- Hi, I looked at the code. Actually all happens in tree-ssa-strlen.c, you have both handle_builtin_stxncpy and maybe_diag_stxncpy_trunc. It happens that the logic where you look at the next statement to check if its like "array[arraySize -1] = '\0' is only implemented in maybe_diag_stxncpy_trunc. Somehow the very same logic should be implemented in handle_builtin_stxncpy around line 2103 where you throw this warning. Cheers, Romain
[Bug target/84025] [nvptx] Don't generate branch-around-nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84025 --- Comment #1 from Tom de Vries --- Created attachment 43480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43480&action=edit Tentative patch
[Bug c++/84497] link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497 Jakub Jelinek changed: What|Removed |Added Keywords||ABI CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This is an ABI issue, so should be resolved for GCC8 if possible.
[Bug target/84498] New: [nvptx, openacc] Don't generate state-propagation inbetween subsequent worker/vector loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84498 Bug ID: 84498 Summary: [nvptx, openacc] Don't generate state-propagation inbetween subsequent worker/vector loops Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider a openacc parallel region with two subsequent worker loops, with no code inbetween the two loops. We have the following sequence of state transitions: 1. worker single 2. worker partitioned 3. worker single 4. worker partitioned 5. worker single At the transition from worker single to worker partitioned (1 -> 2 and 3 -> 4), we propagate the set of live registers from the worker single thread to all the worker threads. At the first transition, we need to propagate all registers, because they haven't been initialized yet in all the workers. At the second transition however, we only need to propagate the registers that have been modified during 3. To do this on a per-register base is more complicated, but if no code is executed during 3, then we know no register was modified inbetween, and we can skip the propagation of all registers.
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code --- Comment #3 from Dominique d'Humieres --- > This looks like a duplicate of PR81116, fixed by r251125. > > This is not a regression, and in genereal (we have played loose with > this rule) we are not supposed to backport. > > Opinions? This is silent wrong code. IMO this should be back ported.
[Bug target/84498] [nvptx, openacc] Don't generate state-propagation inbetween subsequent worker/vector loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84498 --- Comment #1 from Tom de Vries --- Created attachment 43481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43481&action=edit Don't propagate state for subsequent vector loops Tentative patch for two subsequent vector loops.
[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945 --- Comment #12 from Dominique d'Humieres --- Fixed?
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #15 from Segher Boessenkool --- This is a -O0 build? That's what that time report shows afaics.
[Bug c++/80026] [6/7/8 Regression] passing unresolved function pointer to variadic function template yields "too many arguments" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80026 --- Comment #5 from Paolo Carlini --- Then, barring further comments, I'm going to add the testcase and close the bug as invalid.
[Bug target/82096] [6 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82096 --- Comment #13 from sudi at gcc dot gnu.org --- Author: sudi Date: Wed Feb 21 12:50:31 2018 New Revision: 257871 URL: https://gcc.gnu.org/viewcvs?rev=257871&root=gcc&view=rev Log: Fix emit_store_flag_force () function to fix ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi. *** gcc/ChangeLog *** 2018-02-21 Sudakshina Das Backport from trunk 2018-01-10 Sudakshina Das PR target/82096 * expmed.c (emit_store_flag_force): Swap if const op0 and change VOIDmode to mode of op0. *** gcc/testsuite/ChangeLog *** 2018-02-21 Sudakshina Das Backport from trunk 2018-01-12 Sudakshina Das * gcc.c-torture/compile/pr82096.c: Add dg-skip-if directive. Backport from trunk 2018-01-10 Sudakshina Das PR target/82096 * gcc.c-torture/compile/pr82096.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/pr82096.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/expmed.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug other/79046] g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- There've been a bunch of commits for this bug; is it fixed yet?
[Bug target/84499] New: [8 Regression] ICE on cp2k in rs6000_emit_le_vsx_store starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84499 Bug ID: 84499 Summary: [8 Regression] ICE on cp2k in rs6000_emit_le_vsx_store starting with r256656 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Following testcase ICEs starting with r256656 with: -O1 -fstack-protector-strong -mcpu=power8 on powerpc64le-linux. MODULE rh1546743 PRIVATE PUBLIC :: foo INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(14, 200) INTEGER, PARAMETER :: int_8 = SELECTED_INT_KIND(10) COMPLEX(KIND=dp), PARAMETER :: gaussi = (0.0_dp, 1.0_dp) REAL(KIND=dp), PARAMETER :: twopi = 6.28318530717958647692528677_dp INTEGER, DIMENSION(:, :, :), ALLOCATABLE :: coset INTEGER, DIMENSION(:), ALLOCATABLE :: ncoset CONTAINS SUBROUTINE foo(S_G, hmat, h_inv, vol, G_bounds_1, R_bounds_2, order) REAL(KIND=dp), DIMENSION(3, 3), INTENT(IN) :: hmat, h_inv REAL(KIND=dp), INTENT(IN) :: vol REAL(KIND=dp), DIMENSION(3, 3), INTENT(IN) :: G_bounds_1, R_bounds_2 INTEGER :: l_max, sum_method, sum_order REAL(KIND=dp) :: alpha, beta, G_rad, gamma, R_rad REAL(KIND=dp), ALLOCATABLE, DIMENSION(:, :, :) :: S_G_tmp REAL(KIND=dp), DIMENSION(3) :: G_bound, R1, R2, R_bound SELECT CASE (sum_method) CASE (1) SELECT CASE (sum_order) CASE (1) CALL bar(S_G_tmp, l_max, m_max, n_max, R1, R2, alpha, beta, & gamma, hmat, h_inv, vol, R_bound, G_bound, R_rad, G_rad) CALL bar(S_G_tmp, n_max, m_max, l_max, -R2, -R1, gamma, beta, & alpha, hmat, h_inv, vol, R_bound, G_bound, R_rad, G_rad) END SELECT END SELECT END SUBROUTINE foo PURE SUBROUTINE bar(S_G, l_max, m_max, n_max, R1, R2, alpha, beta, gamma, & hmat, h_inv, vol, R_c, G_c, R_rad, G_rad) REAL(KIND=dp), DIMENSION(:, :, :), INTENT(OUT) :: S_G INTEGER, INTENT(IN) :: l_max, m_max, n_max REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: R1, R2 REAL(KIND=dp), INTENT(IN) :: alpha, beta, gamma REAL(KIND=dp), DIMENSION(3, 3), INTENT(IN) :: hmat, h_inv REAL(KIND=dp), INTENT(IN) :: vol REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: R_c, G_c REAL(KIND=dp), INTENT(IN) :: R_rad, G_rad COMPLEX(KIND=dp), DIMENSION(ncoset(m_max), ncoset(n_max)) :: S_R COMPLEX(KIND=dp), DIMENSION(ncoset(l_max), ncoset(m_max), ncoset(n_max)) :: S_G_c REAL(KIND=dp) :: G_rad_sq, R_rad_sq REAL(KIND=dp), DIMENSION(3) :: G, G_y, G_z REAL(KIND=dp), DIMENSION(3, 3) :: ht INTEGER :: gx, gy, gz, k DO gx = -FLOOR(G_c(1)), FLOOR(G_c(1)) DO gy = -FLOOR(G_c(2)), FLOOR(G_c(2)) G_y = ht(:, 2)*gy DO gz = -FLOOR(G_c(3)), FLOOR(G_c(3)) DO k = 1, 3 DO l = 1, l_max ENDDO ENDDO CALL baz(S_R, m_max, n_max, G, R2, beta, gamma, hmat, h_inv, vol, R_c, R_rad_sq) DO lco = 1, ncoset(l_max) ENDDO DO nco = 1, ncoset(n_max) DO mco = 1, ncoset(m_max) DO lco = 1, ncoset(l_max) S_G_c(lco, mco, nco) = exp_tot*i_pow(l+m+n)*(-1.0_dp)**m*S_R(mco, nco) ENDDO ENDDO ENDDO ENDDO ENDDO ENDDO END SUBROUTINE bar PURE SUBROUTINE baz(S_R, l_max, m_max, G, R, alpha, beta, hmat, h_inv, vol, R_c, R_rad_sq) COMPLEX(KIND=dp), DIMENSION(:, :), INTENT(OUT) :: S_R INTEGER, INTENT(IN) :: l_max, m_max REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: G, R REAL(KIND=dp), INTENT(IN) :: alpha, beta REAL(KIND=dp), DIMENSION(3, 3), INTENT(IN) :: hmat, h_inv REAL(KIND=dp), INTENT(IN) :: vol REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: R_c REAL(KIND=dp), INTENT(IN) :: R_rad_sq INTEGER :: k, t, tz, sx, tx, ty COMPLEX(KIND=dp), DIMENSION(ncoset(l_max+m_max)) :: S_R_t REAL(KIND=dp), DIMENSION(-1:l_max+m_max+1, -1:l_max, -1:m_max) :: E1, E2, E3 REAL(KIND=dp), DIMENSION(3) :: R_l, R_r, Rp, Rx, Ry, Rz, s_shift REAL(KIND=dp), DIMENSION(3, 0:l_max+m_max) :: R_pow_t INTERFACE PURE SUBROUTINE boo(l, m, a, b, R1, R2, H_or_C_product, E) INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(14, 200) INTENT(IN) :: l, m REAL(KIND=dp), INTENT(IN) :: a, b, R1, R2 INTEGER, INTENT(IN) :: H_or_C_product REAL(KIND=dp), DIMENSION(-1:l+m+1, -1:m), INTENT(OUT) :: E END SUBROUTINE END INTERFACE s_shift = MATMUL(h_inv, R) R_l = -R_c+s_shift DO sx = CEILING(R_l(1)), FLOOR(R_r(1)) Rx = hmat(:, 1)*sx DO sy = CEILING(R_l(2)), FLOOR(R_r(2)) Ry = hmat(:, 2)*sy DO sz = CEILING(R_l(3)), FLOOR(R_r(3)) Rz = hmat(:, 3)*sz exp_tot = EXP(-c1*Rp_sq)*EXP(-gaussi*c2*DOT_PRODUCT(Rp, G)) DO k = 1, 3 R_pow_t(k, 0) = 1.0_dp DO t = 1, l_max+m_max
[Bug target/84499] [8 Regression] ICE on cp2k in rs6000_emit_le_vsx_store starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84499 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||dje at gcc dot gnu.org, ||kelvin at gcc dot gnu.org, ||segher at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Andrew Pinski from comment #10) > Note this needs at least: > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html > This was approved; has it been committed yet?
[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Alexandre Oliva from comment #6) > Patch posted > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01224.html Adding "patch" keyword
[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||kelvin at gcc dot gnu.org Target Milestone|--- |8.0 Summary|ICE in |[8 Regression] ICE in |rs6000_emit_le_vsx_store, |rs6000_emit_le_vsx_store, |at |at |config/rs6000/rs6000.c:1036 |config/rs6000/rs6000.c:1036 |7 |7 starting with r256656 --- Comment #3 from Jakub Jelinek --- Perhaps related to PR84499.
[Bug target/84499] [8 Regression] ICE on cp2k in rs6000_emit_le_vsx_store starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84499 --- Comment #1 from Jakub Jelinek --- Perhaps related to PR84264.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #9 from Andreas Schwab --- That does not work because CFLAGS gets reset after the test. Only PTHREAD_CFLAGS survives.
[Bug other/79046] g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- I think so.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #10 from Ian Lance Taylor --- In what way does it fail? The final link of libgo is always done against ../libatomic/libatomic.la.
[Bug fortran/79072] ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #22 from Neil Carlson --- I just verified with 8.0 trunk (r257868) that all three of my examples continue to work as expected.
[Bug c/84500] New: diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500
Bug ID: 84500
Summary: diagnostic says "array of chars" for arrays of
wchar_t, char16_t and char32_t
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main() {
wchar_t w[3] = L"abcd";
char16_t u16[3] = u"abcd";
char32_t u32[3] = U"abcd";
}
a.c: In function ‘main’:
a.c:4:18: warning: initializer-string for array of chars is too long
wchar_t w[3] = L"abcd";
^~~
a.c:5:21: warning: initializer-string for array of chars is too long
char16_t u16[3] = u"abcd";
^~~
a.c:6:21: warning: initializer-string for array of chars is too long
char32_t u32[3] = U"abcd";
^~~
Also:
/* { dg-options "-Wc++-compat" } */
#include
int main() {
char c[3] = "abc";
wchar_t w[3] = L"abc";
}
a.c: In function ‘main’:
a.c:4:15: warning: initializer-string for array chars is too long for C++
[-Wc++-compat]
char c[3] = "abc";
^
a.c:5:18: warning: initializer-string for array chars is too long for C++
[-Wc++-compat]
wchar_t w[3] = L"abc";
^~
Note "array chars" not "array of chars".
[Bug target/84499] [8 Regression] ICE on cp2k in rs6000_emit_le_vsx_store starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84499 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Almost certainly a DUP. *** This bug has been marked as a duplicate of bug 84264 ***
[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 --- Comment #4 from Jeffrey A. Law --- *** Bug 84499 has been marked as a duplicate of this bug. ***
[Bug c++/84501] New: diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84501
Bug ID: 84501
Summary: diagnostic says "array of chars" for arrays of
wchar_t, char16_t and char32_t
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
int main() {
wchar_t w[3] = L"abc";
char16_t u16[3] = u"abc";
char32_t u32[3] = U"abc";
}
a.c: In function ‘int main()’:
a.c:2:18: error: initializer-string for array of chars is too long
[-fpermissive]
wchar_t w[3] = L"abc";
^~
a.c:3:21: error: initializer-string for array of chars is too long
[-fpermissive]
char16_t u16[3] = u"abc";
^~
a.c:4:21: error: initializer-string for array of chars is too long
[-fpermissive]
char32_t u32[3] = U"abc";
^~
Saying "chars" implies narrow characters. The standard uses "character array"
for the general case.
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 --- Comment #1 from Jonathan Wakely --- Saying "chars" implies narrow characters. The standard uses "character array" for the general case.
[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #11 from Andreas Schwab --- See comment #0.
[Bug c++/61940] Wrong error location for error in initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jonathan Wakely --- Dup of PR 43064 (assuming that adding better location info will benefit both warnings and errors occurring in the ctor-initializer-list). *** This bug has been marked as a duplicate of bug 43064 ***
[Bug c++/43064] improve location and text of Wconversion warning for initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 Jonathan Wakely changed: What|Removed |Added CC||martin at steghoefer dot eu --- Comment #3 from Jonathan Wakely --- *** Bug 61940 has been marked as a duplicate of this bug. ***
[Bug debug/59319] gcc does not emit DW_AT_friend or DW_TAG_friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59319 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Alexandre Oliva from comment #2) > Revised patch > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02092.html > last refreshed and pinged at > https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html Adding "patch" keyword
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Martin Liška changed: What|Removed |Added Attachment #43478|0 |1 is obsolete|| --- Comment #16 from Martin Liška --- Created attachment 43482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43482&action=edit -ftime-report for most time consuming files on Haswell machine Properly generated with -O2 which was missing in previous version.
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #10 from Martin Liška --- Author: marxin Date: Wed Feb 21 14:05:17 2018 New Revision: 257873 URL: https://gcc.gnu.org/viewcvs?rev=257873&root=gcc&view=rev Log: Add "native" as a valid option value for -march= on arm (PR driver/83193). 2018-02-21 Martin Liska PR driver/83193 * common/config/arm/arm-common.c (arm_print_hint_for_arch_option): Add "native" as a possible value. * config/arm/arm.h (HAVE_LOCAL_CPU_DETECT): Define the macro when native cpu detection is available. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/arm/arm-common.c trunk/gcc/config/arm/arm.h
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #11 from Martin Liška --- Author: marxin Date: Wed Feb 21 14:05:45 2018 New Revision: 257874 URL: https://gcc.gnu.org/viewcvs?rev=257874&root=gcc&view=rev Log: Add "native" as a valid option value for -march= on aarch64 (PR driver/83193). 2018-02-21 Martin Liska PR driver/83193 * config/aarch64/aarch64.c (aarch64_print_hint_for_core_or_arch): Add "native" as a possible value. * config/aarch64/aarch64.h (HAVE_LOCAL_CPU_DETECT): Define the macro when native cpu detection is available. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.h
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2010-02-14 19:44:58 |2018-2-21
Summary|improve location and text |improve location and text
|of Wconversion warning for |of diagnostics in
|initializer list|constructor initializer
||lists
Severity|enhancement |normal
--- Comment #4 from Jonathan Wakely ---
This applies to all diagnostics, not just -Wconversion:
class X {
X() : bad(1),
good(1)
{ }
void* bad;
int good;
};
i.cc: In constructor ‘X::X()’:
i.cc:3:11: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive]
good(1)
^
As Manu said, it's unlikely that the member name can be printed easily, because
the code that checks the initialization works with types, and the name of the
variable isn't known at that point. There are also dozens of different errors
and warnings that can happen there (not just -Wconversion) so they would all
need to be updated.
If the location was correct and shown with a range marking the variable that
would remove the need for printing the name:
i.cc: In constructor ‘X::X()’:
i.cc:2:11: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive]
X() : bad(1),
^~
I'm changing the priority from enhancement to normal, because printing the
wrong location is a bug.
[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Feb 21 14:25:54 2018 New Revision: 257875 URL: https://gcc.gnu.org/viewcvs?rev=257875&root=gcc&view=rev Log: PR c++/84454 - ICE with pack expansion in signature. * error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic172.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Feb 21 14:25:54 2018 New Revision: 257875 URL: https://gcc.gnu.org/viewcvs?rev=257875&root=gcc&view=rev Log: PR c++/84454 - ICE with pack expansion in signature. * error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic172.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c --- Comment #2 from Jason Merrill --- Fixed.
[Bug target/82096] [6 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82096 sudi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from sudi at gcc dot gnu.org --- Backported to gcc-6
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71157, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84315, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84316 --- Comment #55 from Eric Gallager --- Related: bug 71157, bug 84315, and bug 84316 (should this be a meta-bug for all issues with -Wnull-dereference? In which case I should be putting those under "Depends on" instead of "See Also"...)
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #12 from Ian Lance Taylor ---
How about this patch?
diff --git a/libgo/configure b/libgo/configure
index aba4dc39..dcfc524b 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14209,7 +14209,7 @@ if test "${libgo_cv_lib_pthread+set}" = set; then :
$as_echo_n "(cached) " >&6
else
CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -pthread"
+CFLAGS="$CFLAGS -pthread -L../libatomic/.libs"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
int i;
@@ -14226,7 +14226,8 @@ fi
$as_echo "$libgo_cv_lib_pthread" >&6; }
PTHREAD_CFLAGS=
if test "$libgo_cv_lib_pthread" = yes; then
- PTHREAD_CFLAGS=-pthread
+ # RISC-V apparently adds -latomic when using -pthread.
+ PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
fi
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1264a1d2..1f49aee9 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -493,14 +493,15 @@ dnl Test whether the compiler supports the -pthread
option.
AC_CACHE_CHECK([whether -pthread is supported],
[libgo_cv_lib_pthread],
[CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -pthread"
+CFLAGS="$CFLAGS -pthread -L../libatomic/.libs"
AC_COMPILE_IFELSE([[int i;]],
[libgo_cv_lib_pthread=yes],
[libgo_cv_lib_pthread=no])
CFLAGS=$CFLAGS_hold])
PTHREAD_CFLAGS=
if test "$libgo_cv_lib_pthread" = yes; then
- PTHREAD_CFLAGS=-pthread
+ # RISC-V apparently adds -latomic when using -pthread.
+ PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
fi
AC_SUBST(PTHREAD_CFLAGS)
[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84434 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added Keywords|patch | --- Comment #12 from Andrew Pinski --- (In reply to Eric Gallager from comment #11) > (In reply to Andrew Pinski from comment #10) > > Note this needs at least: > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html > > > > This was approved; has it been committed yet? Yes. That patch was applied. But that patch is only a support patch and not the full patch to fix this. I was actually going to working on this again but it won't go in until gcc 9.
[Bug fortran/79072] ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #23 from Thomas Koenig --- Let's close it then. Thanks for the bug report!
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #13 from Andreas Schwab --- The first hunk is useless since this is a compile test.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #14 from Andreas Schwab --- See gcc/config/riscv/linux.h for why it does that.
[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|kelvin at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #5 from Peter Bergner --- I'm looking into this.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #15 from Ian Lance Taylor --- > The first hunk is useless since this is a compile test. Understood, but I would prefer to test the exact options that the build is going to use.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #56 from Martin Sebor --- I'd say any warning option with more than just a handful of pr's against it would benefit from having a meta-bug.
[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126 --- Comment #9 from Tom de Vries --- (In reply to Tom de Vries from comment #8) > Created attachment 43476 [details] > Tentative patch > > (In reply to rguent...@suse.de from comment #3) > > > This is the usual "you should not repeat analysis during transform" issue. > > The vectorizer gets around this by caching relevant scalar evolution > > but obviously that's difficult if using generic stuff like > > canonicalize_loop_ivs ... > > This patch caches affine_iv info before calling loop_version, and then uses > that cached info in canonicalize_loop_ivs. This fixes the ICE. Bootstrap and reg-test on x86_64 succeeded. Richard, is this approach ok for stage1 and/or stage4?
[Bug c++/84502] New: Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Bug ID: 84502 Summary: Argument corruption when passing empty templated struct Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.schlangen at bmw dot de Target Milestone: --- Created attachment 43483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43483&action=edit Minimal example Hi, we've discovered a strange problem when passing many function arguments where one argument is an alias (using = ...) for a templated struct which has no members (e.g. std::integer_sequence). When building in non-optimized mode or with -O1/-O2, all arguments starting from argument #7 seem to be corrupt. Building with -O3 seems to solve the issue. I've attached a small example program. Correct output: --- $ ~/gcc-8/bin/g++ -O3 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 6, 7 Wrong outputs: -- $ ~/gcc-8/bin/g++ -O2 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 0 $ ~/gcc-8/bin/g++ -O1 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 0 $ ~/gcc-8/bin/g++ -O0 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 2088590376 gcc version (freshly built): $ ~/gcc-8/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/patrick/gcc-8/bin/g++ COLLECT_LTO_WRAPPER=/home/patrick/gcc-8/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/patrick/gcc-8 --disable-multilib Thread model: posix gcc version 8.0.1 20180218 (experimental) (GCC) Best Regards Patrick
[Bug tree-optimization/84503] New: [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
Bug ID: 84503
Summary: [7/8 Regression] store-merging miscompilation on
powerpc64 with -O3 since r241789
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
typedef __SIZE_TYPE__ size_t;
typedef __UINTPTR_TYPE__ uintptr_t;
struct S { int a; unsigned short b; int c, d, e; long f, g, h; int i, j; };
static struct S *k;
static size_t l = 0;
int m;
static int
bar (void)
{
unsigned i;
int j;
if (k[0].c == 0)
{
++m;
size_t n = l * 2;
struct S *o;
o = (struct S *) __builtin_realloc (k, sizeof (struct S) * n);
if (!o)
__builtin_exit (0);
k = o;
for (i = l; i < n; i++)
{
void *p = (void *) &k[i];
int q = 0;
size_t r = sizeof (struct S);
if uintptr_t) p) % __alignof__ (long)) == 0
&& r % sizeof (long) == 0)
{
long __attribute__ ((may_alias)) *s = (long *) p;
long *t = (long *) ((char *) s + r);
while (s < t)
*s++ = 0;
}
else
__builtin_memset (p, q, r);
k[i].c = i + 1;
k[i].a = -1;
}
k[n - 1].c = 0;
k[0].c = l;
l = n;
}
j = k[0].c;
k[0].c = k[j].c;
return j;
}
int
main ()
{
k = (struct S *) __builtin_malloc (sizeof (struct S));
if (!k)
__builtin_exit (0);
__builtin_memset (k, '\0', sizeof (struct S));
k->a = -1;
l = 1;
for (int i = 0; i < 15; ++i)
bar ();
if (m != 4)
__builtin_abort ();
return 0;
}
is miscompiled with -O3 starting with r241789. The bug can be seen when
diffing store_merging dump with the previous one:
--- rh1547495.c.192t.widening_mul 2018-02-21 17:25:00.049972838 +0100
+++ rh1547495.c.193t.store-merging 2018-02-21 17:25:00.049972838 +0100
@@ -1,6 +1,10 @@
;; Function main (main, funcdef_no=1, decl_uid=2691, cgraph_uid=1,
symbol_order=4) (executed once)
+Coalescing successful!
+Merged into 2 stores
+New sequence of 2 stmts to replace old one of 3 stmts
+Merging successful!
main ()
{
unsigned int i;
@@ -120,8 +124,6 @@ main ()
goto ; [57.11%]
[local count: 510973054]:
- MEM[(long int *)p_28] = 0;
- MEM[(long int *)p_28 + 8B] = 0;
MEM[(long int *)p_28 + 16B] = 0;
MEM[(long int *)p_28 + 24B] = 0;
MEM[(long int *)p_28 + 32B] = 0;
@@ -130,7 +132,8 @@ main ()
_14 = i_31 + 1;
_119 = (int) _14;
MEM[(struct S *)p_28].c = _119;
- MEM[(struct S *)p_28].a = -1;
+ MEM[(void *)p_28] = 18446744069414584320;
+ MEM[(long int *)p_28 + 8B] = 0;
_111 = (long unsigned int) _14;
if (n_21 > _111)
goto ; [89.00%]
MEM[(void *)p_28] = 18446744069414584320;
is fine, that stores 0x into the first 8 bytes, but
MEM[(struct S *)p_28].c = _119;
stores 4 bytes at offset 8 and MEM[(long int *)p_28 + 8B] = 0;
overwrites it.
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-21 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug c++/84502] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 --- Comment #1 from patrick.schlangen at bmw dot de --- Note: This problem does not happen with gcc 7.2.1. The problem can also be reproduced with -O3 when the empty struct object passed to the function is actually used in the function. (So it is not optimized out.)
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #16 from Andreas Schwab --- Created attachment 43484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43484&action=edit libgo support for riscv64 With this patch I can sucessfully build libgo for riscv64.
[Bug fortran/84504] New: procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 Bug ID: 84504 Summary: procedure pointer variables cannot be initialized with functions returning pointers Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sriram at pobox dot com Target Milestone: --- Also occurs on gcc 7.2.0 - not tried on other version. procedure pointer variables pointing initialized with functions returning pointers fail to compile. Note that the sample code below compiles if we change the function type to not be a pointer. Source: module test_procedure_pointer implicit none private procedure(the_proc), pointer :: ptr => the_proc contains function the_proc() integer, pointer :: the_proc end function the_proc end module test_procedure_pointer Error: procedure(the_proc), pointer :: ptr => the_proc 1 Error: Pointer initialization target at (1) must have the TARGET attribute save-temps: sn-fey1[1-290] gfortran -v -save-temps ~/procpointer.f90 Driving: gfortran -v -save-temps /users/sriram/procpointer.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-6.4.0/configure --prefix=/usr/projects/hpcsoft/toss3/common/gcc/6.4.0 --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-checking=release --disable-multilib --enable-languages=c,c++,fortran Thread model: posix gcc version 6.4.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/f951 /users/sriram/procpointer.f90 -quiet -dumpbase procpointer.f90 -mtune=generic -march=x86-64 -auxbase procpointer -version -fintrinsic-modules-path /yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.4.0/finclude -o procpointer.s GNU Fortran (GCC) version 6.4.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 6.4.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /users/sriram/procpointer.f90:4:50: procedure(the_proc), pointer :: ptr => the_proc 1 Error: Pointer initialization target at (1) must have the TARGET attribute
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 --- Comment #4 from Steve Kargl --- On Wed, Feb 21, 2018 at 10:44:07AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 > > Thomas Koenig changed: > >What|Removed |Added > > CC||tkoenig at gcc dot gnu.org > > --- Comment #2 from Thomas Koenig --- > This looks like a duplicate of PR81116, fixed by r251125. > > This is not a regression, and in genereal (we have played loose with > this rule) we are not supposed to backport. > > Opinions? > Release Manager would probably say that it is up the Fortran Maintainers on whether something should be backported. If I have a patch on trunk that applies to the branch(es) with minimum effort, I tend to backport to keep code in sync.
[Bug c++/84492] [8 Regression] ICE with statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||dmalcolm at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. Started with r253599.
[Bug c++/84492] [8 Regression] ICE with statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492 --- Comment #2 from David Malcolm --- This assertion is failing, where rhs is a STMT_EXPR. 8000 /* There are only a few kinds of expressions that may have a type 8001 dependent on overload resolution. */ 8002 gcc_assert (TREE_CODE (rhs) == ADDR_EXPR 8003 || TREE_CODE (rhs) == COMPONENT_REF 8004 || is_overloaded_fn (rhs) 8005 || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL));
[Bug c++/84491] Multiple inheritance and covariant return types causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84491 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. It's failing this assertion in method.c: 96/* Likewise, we can only be adding thunks to a function declared in 97 the class currently being laid out. */ 98gcc_assert (TYPE_SIZE (DECL_CONTEXT (function)) 99&& TYPE_BEING_DEFINED (DECL_CONTEXT (function)));
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-21
Known to work||7.3.0
Summary|Argument corruption when|[8 Regression] Argument
|passing empty templated |corruption when passing
|struct |empty templated struct
Ever confirmed|0 |1
Known to fail||8.0.1
--- Comment #2 from Jonathan Wakely ---
This is caused by -fabi-version=12 (which is the default for GCC 8). You can
get the old handling of empty structs with -fabi-version=11
The bug only seems to happen when the empty struct is a class template.
Reduced, this fails at -O0 but not any other optimization level, or with
-fabi-version=11:
template
struct EmptyTemplatedStruct { };
using X = EmptyTemplatedStruct;
void func(X, int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
if (a1 != 0)
__builtin_abort();
if (a2 != 1)
__builtin_abort();
if (a3 != 2)
__builtin_abort();
if (a4 != 3)
__builtin_abort();
if (a5 != 4)
__builtin_abort();
if (a6 != 5)
__builtin_abort();
if (a7 != 6)
__builtin_abort();
if (a8 != 7)
__builtin_abort();
}
int main()
{
func(X{}, 0, 1, 2, 3, 4, 5, 6, 7);
}
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.0
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #1 from Jakub Jelinek --- Can be reproduced also on x86_64-linux with -O3 -fno-tree-vectorize -fno-ivopts. For the latter, I wonder what's the point in using TARGET_MEM_REF in: MEM[(long int *)p_28] = 0; MEM[(long int *)p_28 + 8B] = 0; MEM[(long int *)p_28 + 16B] = 0; MEM[(long int *)p_28 + 24B] = 0; MEM[(long int *)p_28 + 32B] = 0; MEM[(long int *)p_28 + 40B] = 0; MEM[(long int *)p_28 + 48B] = 0; , isn't that something that MEM_REF can express too? store-merging doesn't handle TARGET_MEM_REFs and only handles MEM_REFs. So, for stage1 shall it handle also TARGET_MEM_REFs that only have base and optionally constant disp and nothing else, or shall ivopts pass instead just generate MEM_REFs in those cases?
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=45431
--- Comment #5 from Jonathan Wakely ---
In this similar case the C front end gets the location right, and also prints a
note with the name of the field:
#include
struct X { int i; int j; };
struct X x = {
NULL,
2
};
$ gcc -Wall s.c -c
s.c:4:3: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
NULL,
^~~~
s.c:4:3: note: (near initialization for ‘x.i’)
$ g++ -Wall s.c -c
s.c:6:1: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
};
^
[Bug c++/45431] specify the field for initializer-string for array of chars is too long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431 --- Comment #4 from Jonathan Wakely --- Because the C front end gets the location info right in recent versions of GCC it also marks the bad initializer with carets: bug.c:4:3: warning: initializer-string for array of chars is too long "Christopher", ^ bug.c:4:3: note: (near initialization for 'sc_me.name') bug.c:5:3: warning: initializer-string for array of chars is too long "Yeleighton" }; ^~~~ bug.c:5:3: note: (near initialization for 'sc_me.surname') This is ideal, as it shows both the bad initializer, and the field it's trying to initialize.
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- This might be the reason why building Chromium gn fails (I hope). Related: PR84286
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #2 from Jakub Jelinek ---
The bug is in the way we handle overlapping stores. The problem is that all we
do if there is overlap is:
if (IN_RANGE (info->bitpos, merged_store->start,
merged_store->start + merged_store->width - 1))
{
/* Only allow overlapping stores of constants. */
if (info->rhs_code == INTEGER_CST
&& merged_store->stores[0]->rhs_code == INTEGER_CST)
{
merged_store->merge_overlapping (info);
continue;
}
}
otherwise we:
/* |---store 1---| |---store 2---|.
Gap between stores or the rhs not compatible. Start a new group. */
/* Try to apply all the stores recorded for the group to determine
the bitpattern they write and discard it if that fails.
This will also reject single-store groups. */
if (!merged_store->apply_stores ())
delete merged_store;
else
m_merged_store_groups.safe_push (merged_store);
merged_store = new merged_store_group (info);
But the statements here are sorted primarily by bitpos and we emit statements
for the group at the location of the last statement (highest order) in the
merged store group. So I think we need to check before adding another store if
it is not rhs_code INTEGER_CST, whether there is any overlap with following
stores. Overlap is fine if the order of all the overlapping statements is
higher than MAX (merged_store->last_order, info->order), because then we know
we'll start a new group right after info and the merged stores of the current
group will come before any overlapping stores (whether merged successfully with
something or not), but otherwise we just shouldn't add info into the current
group.
[Bug tree-optimization/84480] Unexpected -Wstringop-truncation on strncpy with string literal at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Thanks for the test case. The root cause is the same as in bug 84474. The warnings in both of these test cases are issued in gimple-fold.c (see gimple_fold_builtin_strncpy), long before the code in tree-ssa-strlen.c has run. The difference between this case and the one in bug 84474 is that here the next statement is already available. With that, I think there may be a way to avoid the subset of the warnings in this report.
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|Unexpected |[8 Regression] bogus |-Wstringop-truncation on|-Wstringop-truncation |strncpy with string literal |despite assignment with an |at -O2 |inlined string literal
[Bug c/70186] RFE: better handling of misspelled attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70186 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82914 --- Comment #4 from Martin Sebor --- See also bug 82914 that points out cases where GCC silently ignores all attributes, misspelled or otherwise. (It's a different problem than this one and the solutions are different as well.)
[Bug tree-optimization/84505] New: [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505
Bug ID: 84505
Summary: [8 Regression] store-merging miscompilation on i586 in
xemacs package starting with r254391
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
I'm still reducing the test-case, but with:
$ gcc -O2 -m32 alloc.i -funroll-loops -fdump-tree-optimized=/tmp/bad.txt -c -o
/tmp/bad.s -S -fno-strict-aliasing
I see following difference in tree-optimized dump:
$ diff -u /tmp/good.txt /tmp/bad.txt -U20
--- /tmp/good.txt 2018-02-21 19:15:26.081205161 +0100
+++ /tmp/bad.txt2018-02-21 19:23:04.898349760 +0100
@@ -9831,50 +9831,49 @@
free_marker (Lisp_Object ptr)
{
struct Lisp_Marker * FFT_ptr;
struct Lisp_Free * marker_free_list.705_1;
long int consing_since_gc.706_2;
long unsigned int consing_since_gc.707_3;
long unsigned int _4;
long int _5;
long unsigned int total_consing.708_6;
long unsigned int _7;
int profiling_active.709_8;
int gc_count_num_marker_freelist.711_10;
int _11;
long int prephitmp_31;
long int pretmp_40;
[local count: 1431]:
FFT_ptr_15 = (struct Lisp_Marker *) ptr_14(D);
unchain_marker (ptr_14(D));
- MEM[(unsigned int *)FFT_ptr_15] = 3735928559;
- MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;
MEM[(unsigned int *)FFT_ptr_15 + 8B] = 3735928559;
MEM[(unsigned int *)FFT_ptr_15 + 12B] = 3735928559;
MEM[(unsigned int *)FFT_ptr_15 + 16B] = 3735928559;
MEM[(unsigned int *)FFT_ptr_15 + 20B] = 3735928559;
marker_free_list.705_1 = marker_free_list;
MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1;
marker_free_list = FFT_ptr_15;
- MEM[(struct lrecord_header *)FFT_ptr_15].type = 69;
+ MEM[(void *)FFT_ptr_15] = 3735928389;
+ MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;
consing_since_gc.706_2 = consing_since_gc;
consing_since_gc.707_3 = (long unsigned int) consing_since_gc.706_2;
_4 = consing_since_gc.707_3 + 4294967272;
_5 = (long int) _4;
consing_since_gc = _5;
total_consing.708_6 = total_consing;
_7 = total_consing.708_6 + 4294967272;
total_consing = _7;
profiling_active.709_8 = profiling_active;
if (profiling_active.709_8 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 472]:
profile_record_unconsing (24);
pretmp_40 = consing_since_gc;
[local count: 1429]:
# prephitmp_31 = PHI
I suspect later 2 stores:
+ MEM[(void *)FFT_ptr_15] = 3735928389;
+ MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;
which overwrite:
MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1;
It's probably connected with aliasing analysis that allows store motion after
the *.chain store.
[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- It was fixed on trunk by r242607 i.e. PR c++/77285 *** This bug has been marked as a duplicate of bug 77285 ***
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 Maxim Kuvyrkov changed: What|Removed |Added Status|ASSIGNED|NEW CC||mkuvyrkov at gcc dot gnu.org Assignee|cbaylis at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505 --- Comment #1 from Jakub Jelinek --- Might very well be a dup of PR84503, let me finish up the patch.
[Bug fortran/83980] Various issues with character length in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83980 --- Comment #6 from Dominique d'Humieres --- > The fix for pr83823 seems to have fixed the problems reported in > comment #0 and comment #2 for 8.0 trunk. The issues persist up to > 7.2 (haven't checked 7.3). Confirmed.
[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Jeffrey A. Law changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE |---
--- Comment #22 from Jeffrey A. Law ---
I don't think this is a duplicate of 21161.
AFAICT the core of the problem here is the multiple static assignments to the
pseudos holding cancel_arg and cancel_routine.
They set the objects to the same value, but the multiple-assignment nature is a
key aspect of the longjmp clobbering analysis.
I think the multiple assignment largely steps from the PHIs in this block:
;; basic block 5, loop depth 0, count 536656163 (estimated locally), maybe
hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP,
VISITED)
;;pred: 4 [always (guessed)] count:268328082 (estimated locally)
(FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;;6 [always (guessed)] count:1716613 (estimated locally)
(ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;;3 [50.0% (guessed)] count:268328082 (estimated locally)
(IRREDUCIBLE_LOOP,FALSE_VALUE,EXECUTABLE)
# __cancel_routine_9(ab) = PHI
# __cancel_arg_12(ab) = PHI <_1(4), __cancel_arg_13(ab)(6), _1(3)>
_24 = __sigsetjmp (&__cancel_buf.__cancel_jmp_buf, 0);
goto ; [99.96%]
This happens in CCP1 and FRE1 for cancel_routine and cancel_arg respectively.
(replacinging a cancel_{arg,routine} with an equivalent). Once replaced, it's
exceedingly hard to undo. One could easily argue that we shouldn't to the
replacement in an abnormal PHI.
Regardless, this is separate from 21161. There is a slim chance that fixing
21161 is a requirement to fix this BZ, but they are not duplicates AFAICT.
[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to Thomas Koenig from comment #4) > Reverting the resolve.c part of r254427 makes the problem go away. It's the second part of the patch to resolve.c that offends. Clearly, the possession of a iso_bind_c type component is the problem. I will investigate more on Friday, when I have some time. Paul
[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
--- Comment #5 from Martin Sebor ---
(In reply to Ramana Radhakrishnan from comment #4)
Setting -march=armv7-a doesn't make a difference.
The root cause is that initializers of locally defined aggregates such as
struct { char a[N]; } S s = { "12345" };
are represented in one of two ways in GIMPLE:
a) as an assignment of the string to s.a, or
b) as a copy from a label (e.g., 's = *.LC0')
and the strlen pass only knows how to deal with (a) but not (b).
AFAICS, whether form (a) or form (b) is chosen depends on the size of the size
of the aggregate. Some targets use a lower threshold for (b) than others. As
far as I can see, x86_64 appears to cut over at 257 bytes, while arm-none-eabi
always uses (b).
[Bug c++/77285] [5 Regression] extern thread_local linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285 Jonathan Wakely changed: What|Removed |Added CC||zhykzhykzhyk at gmail dot com --- Comment #15 from Jonathan Wakely --- *** Bug 66971 has been marked as a duplicate of this bug. ***
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. I think the warning would be the most informative and the least vague if it instead used the name of the array type, and also mentioned the size of the initializer in case it's hidden behind a macro: warning: initializer-string for an object of 'wchar_t[3]' has 5 elements as long as there is a way to get at the name of the typedef. Otherwise, printing the underlying type would be an alternative.
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 --- Comment #4 from Dominique d'Humieres --- AFAICT the tests in comment 0 and 1 compile at revision r257865, but compiling the test z4.f90 still gives an ICE.
