[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- These are caused by distinct issues. THe first is a problem with an RTL pass (insn splitting), the second is a problem with a gimple pass (switch conversion). For the first case we could try to fix this in the backend. I believe the original insn is marked as having an EH edge because we've enabled -fnon-call-exceptions. So the float_truncate itself might signal. ISTM that we really need to be doing a CFG cleanup after splitting if we potentially could have removed a throwing insn. Fixing switch conversion for the second test is pretty trivial. group_case_labels removes the edge from the switch to the __builtin_unreachable case. This leaves the block unreachable and of course causes the failure in computation of the dominance tree. Tracking whether or not the CFG was altered and thus we need to return TODO_cleanup_cfg is sufficient to address this problem.
[Bug rtl-optimization/83723] New: [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723
Bug ID: 83723
Summary: [8 Regression] ICE: in gen_rtx_SUBREG, at
emit-rtl.c:1010
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272 on i686-linux-gnu, worked around with -O1
$ cat debris.ii
int a();
void b();
void c(float);
float d();
int *e;
void f() {
float g = d();
c(g);
if (e)
b();
if (g < 1.0)
g = a() / g;
}
$ g++ -c -g -O2 -mfpmath=sse -msse -msse2 -ansi -funroll-loops -fsigned-char
debris.ii
during RTL pass: reload
debris.ii: In function 'void f()':
debris.ii:13:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010
}
^
0x81c19b8 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long
long>)
../../src/gcc/emit-rtl.c:1010
0x86d8a89 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool)
../../src/gcc/lra.c:1936
0x86d8b45 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool)
../../src/gcc/lra.c:1950
0x86d8b45 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool)
../../src/gcc/lra.c:1950
0x86d8c02 lra_substitute_pseudo_within_insn(rtx_insn*, int, rtx_def*, bool)
../../src/gcc/lra.c:1973
0x86ec39e remove_inheritance_pseudos
../../src/gcc/lra-constraints.c:6769
0x86ec39e lra_undo_inheritance()
../../src/gcc/lra-constraints.c:6970
0x86d954b lra(_IO_FILE*)
../../src/gcc/lra.c:2471
0x8698747 do_reload
../../src/gcc/ira.c:5462
0x8698747 execute
../../src/gcc/ira.c:5646
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
[Bug rtl-optimization/83723] [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723 --- Comment #1 from Matthias Klose --- ... building the freespace2 package on i386
[Bug preprocessor/83722] [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Isn't that simply diagnostic output from unrelated compilers running in parallel? As shown in the log file, the build is launched with make -j4 after all. The ICE needs a separate bug.
[Bug preprocessor/83722] [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 --- Comment #3 from Matthias Klose --- no, the output is directly taken from the generated file, not from the build log. The itself is reported in PR83723.
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #23 from Janne Blomqvist --- Author: jb Date: Sun Jan 7 10:17:52 2018 New Revision: 256322 URL: https://gcc.gnu.org/viewcvs?rev=256322&root=gcc&view=rev Log: PR 78534, 83704 Handle large formatted I/O In order to handle large characters when doing formatted I/O, use size_t and ptrdiff_t for lengths. Compared to the previous patch, based on discussions on IRC use size_t for sizes that don't need to be negative rather than ptrdiff_t everywhere. Regtested on x86_64-pc-linux-gnu, approved as part of the PR 78534 approval, committed to trunk. libgfortran/ChangeLog: 2018-01-07 Janne Blomqvist PR fortran/78534 PR fortran/83704 * io/fbuf.c (fbuf_init): Use size_t instead of int for length. (fbuf_debug): Convert debug output to unsigned long. (fbuf_reset): Use ptrdiff_t for return value. (fbuf_alloc): Use size_t for length argument. (fbuf_flush): Handle large buffers. (fbuf_flush_list): Likewise. (fbuf_seek): Use ptrdiff_t for offset and return value. (fbuf_read): Use size_t for length argument. (fbuf_getc_refill): Use size_t to match fbuf_read. * io/fbuf.h (struct fbuf): Use size_t for lengths. (fbuf_init): Use size_t instead of int for length. (fbuf_reset): Use ptrdiff_t for return value. (fbuf_alloc): Use size_t for length argument. (fbuf_seek): Use ptrdiff_t for offset and return value. (fbuf_read): Use size_t for length argument. * io/io.h (read_block_form): Likewise. (read_block_form4): Likewise. (write_block): Likewise. (read_a): Likewise. (read_a_char4): Likewise. (read_x): Likewise. (write_a): Likewise. (write_a_char4): Likewise. * io/list_read.c (list_formatted_read_scalar): Use size_t to handle large buffers. * io/read.c (read_l): Likewise. (read_utf8): Likewise. (read_utf8_char1): Likewise. (read_default_char1): Likewise. (read_utf8_char4): Likewise. (read_default_char4): Likewise. (read_a): Likewise. (read_a_char4): Likewise. (eat_leading_spaces): Likewise. (next_char): Likewise. (read_decimal): Likewise. (read_radix): Likewise. (read_f): Likewise. (read_x): Likewise. * io/transfer.c (read_sf_internal): Likewise. (read_sf): Likewise. (read_block_form): Likewise. (read_block_form4): Likewise. (write_block): Likewise. (formatted_transfer_scalar_write): Likewise. (next_record_w): Likewise. * io/unix.c (mem_alloc_r): Likewise. (mem_alloc_r4): Likewise. (mem_alloc_w): Likewise. (mem_alloc_w4): Likewise. (mem_read): Likewise. (mem_read4): Likewise. (mem_write): Likewise. (mem_write4): Likewise. (open_internal): Likewise. (open_internal4): Likewise. * io/unix.h (open_internal): Likewise. (open_internal4): Likewise. (mem_alloc_w): Likewise. (mem_alloc_r): Likewise. (mem_alloc_w4): Likewise. (mem_alloc_r4): Likewise. * io/write.c (write_check_cc): Likewise. (write_cc): Likewise. (write_a): Likewise. (write_a_char4): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/fbuf.c trunk/libgfortran/io/fbuf.h trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/io/write.c
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #11 from Janne Blomqvist --- Author: jb Date: Sun Jan 7 10:17:52 2018 New Revision: 256322 URL: https://gcc.gnu.org/viewcvs?rev=256322&root=gcc&view=rev Log: PR 78534, 83704 Handle large formatted I/O In order to handle large characters when doing formatted I/O, use size_t and ptrdiff_t for lengths. Compared to the previous patch, based on discussions on IRC use size_t for sizes that don't need to be negative rather than ptrdiff_t everywhere. Regtested on x86_64-pc-linux-gnu, approved as part of the PR 78534 approval, committed to trunk. libgfortran/ChangeLog: 2018-01-07 Janne Blomqvist PR fortran/78534 PR fortran/83704 * io/fbuf.c (fbuf_init): Use size_t instead of int for length. (fbuf_debug): Convert debug output to unsigned long. (fbuf_reset): Use ptrdiff_t for return value. (fbuf_alloc): Use size_t for length argument. (fbuf_flush): Handle large buffers. (fbuf_flush_list): Likewise. (fbuf_seek): Use ptrdiff_t for offset and return value. (fbuf_read): Use size_t for length argument. (fbuf_getc_refill): Use size_t to match fbuf_read. * io/fbuf.h (struct fbuf): Use size_t for lengths. (fbuf_init): Use size_t instead of int for length. (fbuf_reset): Use ptrdiff_t for return value. (fbuf_alloc): Use size_t for length argument. (fbuf_seek): Use ptrdiff_t for offset and return value. (fbuf_read): Use size_t for length argument. * io/io.h (read_block_form): Likewise. (read_block_form4): Likewise. (write_block): Likewise. (read_a): Likewise. (read_a_char4): Likewise. (read_x): Likewise. (write_a): Likewise. (write_a_char4): Likewise. * io/list_read.c (list_formatted_read_scalar): Use size_t to handle large buffers. * io/read.c (read_l): Likewise. (read_utf8): Likewise. (read_utf8_char1): Likewise. (read_default_char1): Likewise. (read_utf8_char4): Likewise. (read_default_char4): Likewise. (read_a): Likewise. (read_a_char4): Likewise. (eat_leading_spaces): Likewise. (next_char): Likewise. (read_decimal): Likewise. (read_radix): Likewise. (read_f): Likewise. (read_x): Likewise. * io/transfer.c (read_sf_internal): Likewise. (read_sf): Likewise. (read_block_form): Likewise. (read_block_form4): Likewise. (write_block): Likewise. (formatted_transfer_scalar_write): Likewise. (next_record_w): Likewise. * io/unix.c (mem_alloc_r): Likewise. (mem_alloc_r4): Likewise. (mem_alloc_w): Likewise. (mem_alloc_w4): Likewise. (mem_read): Likewise. (mem_read4): Likewise. (mem_write): Likewise. (mem_write4): Likewise. (open_internal): Likewise. (open_internal4): Likewise. * io/unix.h (open_internal): Likewise. (open_internal4): Likewise. (mem_alloc_w): Likewise. (mem_alloc_r): Likewise. (mem_alloc_w4): Likewise. (mem_alloc_r4): Likewise. * io/write.c (write_check_cc): Likewise. (write_cc): Likewise. (write_a): Likewise. (write_a_char4): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/fbuf.c trunk/libgfortran/io/fbuf.h trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/io/write.c
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #12 from Janne Blomqvist --- With these two commits in #c10 and #c11 the testcase now works correctly. However, if one enables warnings there's still the (spurious) warning: test1.f90:12:18: ch = '123456789' 1 Warning: CHARACTER expression will be truncated in assignment (4/9) at (1) [-Wcharacter-truncation] If one changes the size of the variable 'ch' to 2_8**31_8+4_8 the warning message becomes test2.f90:12:18: ch = '123456789' 1 Warning: CHARACTER expression will be truncated in assignment (-2147483644/9) at (1) [-Wcharacter-truncation] Which looks like a clear case of integer wraparound. Given that the testcase works, apparently correctly, I would guess the it's an error in the implementation of the -Wcharacter-truncation warning.
[Bug middle-end/83724] New: [8 Regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83724
Bug ID: 83724
Summary: [8 Regression] ICE in calc_dfs_tree, at
dominance.c:458
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272, building llvm-toolchain-3.9 (3.9.1) on x86_64-linux-gnu
$ g++ -c -std=c++11 -O2 -fno-exceptions MipsAsmParser.ii
during GIMPLE pass: profile_estimate
: In function 'unsigned int {anonymous}::G::bi(const at&, l&)':
:64:1: internal compiler error: in calc_dfs_tree, at dominance.c:458
0x5a1d99 calc_dfs_tree
../../src/gcc/dominance.c:458
0x8fd59d calculate_dominance_info(cdi_direction)
../../src/gcc/dominance.c:734
0xaa959a loop_optimizer_init(unsigned int)
../../src/gcc/loop-init.c:103
0xb4b626 execute
../../src/gcc/predict.c:3821
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat MipsAsmParser.ii
# 1 "" 3
namespace a {
template struct d { static constexpr b e = c; };
template struct f : d {};
}
typedef long g;
template struct h { static const bool e = a::f::e; };
namespace a {
template struct ah;
template class ai;
}
class i {
public:
operator[](long) const {}
};
template class am : public i {};
class an;
class k : public am, h>>::e> {};
class l {
public:
aq();
};
class ar extern as;
typedef k at;
class m {
virtual bool av(int, unsigned &, at &, int &, g &, bool);
};
class ar {
public:
typedef m *aw(const &, int &, const &, const &);
};
struct ax {
static ay(ar::aw);
};
template struct n {
n(ar) { ax::ay(ba); }
static m *ba(const &bb, int &bc, const &bd, const &be) { az(bb, bc, bd, be);
}
};
namespace {
class G : m {
unsigned bi(const at &, l &);
bool av(int, unsigned &, at &, int &, g &, bool);
public:
G(const, int, const, const) {}
};
}
bool G::av(int, unsigned &, at &bl, int &, g &, bool) {
l bo;
bi(bl, bo);
}
o() { n bp(as); }
namespace {
enum { bq, br };
}
unsigned G::bi(const at &bl, l &bo) {
unsigned bs;
for (char *j;; j += 2)
switch (*j) {
case bq:
bl[bs];
case br:
bo.aq();
}
}
[Bug middle-end/83724] [8 Regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83724 --- Comment #1 from Matthias Klose --- duplicate of PR81308?
[Bug ipa/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 Rainer Orth changed: What|Removed |Added Target|powerpc64*-*-* | Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-07 CC||ro at gcc dot gnu.org Host|powerpc64*-*-* | Target Milestone|--- |8.0 Ever confirmed|0 |1 Build|powerpc64*-*-* | --- Comment #1 from Rainer Orth --- According to gcc-testresults, this happens on all sorts of targets (I'm seeing it on i386-pc-solaris2.11 and sparc-sun-solaris2.11).
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Blocks||39627 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Summary|[F03] [F08] Add FINDLOC |[F08] Add FINDLOC plus |plus support MAXLOC/MINLOC |support MAXLOC/MINLOC with |with KIND=/BACK=|KIND=/BACK= --- Comment #5 from Thomas Koenig --- I'll take a shot, but this will take a while. If anybody else wants to chime in, feel free :-) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 [Bug 39627] [meta-bug] Fortran 2008 support
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #13 from Dominique d'Humieres ---
> Which looks like a clear case of integer wraparound. Given that
> the testcase works, apparently correctly, I would guess the it's
> an error in the implementation of the -Wcharacter-truncation warning.
gfc_set_constant_character_len (int len, gfc_expr *expr, int check_len)
{
gfc_char_t *s;
int slen;
...
in fortran/decl.c looks wrong, but I failed to find a fix!-(
[Bug web/78315] "Changes" don't explain what "LRA" is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78315 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Segher Boessenkool --- It is more than plenty: what is the default for new ports only concerns developers of GCC itself. Everyone else is free to read some documentation (it isn't hard to find).
[Bug fortran/83725] New: [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 Bug ID: 83725 Summary: [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: jb at gcc dot gnu.org Target Milestone: --- Compiling the following variant of pr65381: module stringtable_mod implicit none private save type, public :: StringList character(:), allocatable :: chars end type type, public :: StringTable type(StringList), allocatable :: list(:) end type contains pure function fixedStringTable(this) result(fixed) !class(StringTable), intent(IN) :: this(:) type(StringTable), intent(IN) :: this(:) character(LEN_MAX(this)) :: fixed(getTableSize(this)) integer :: i, j, k k = 0 do i = 1, SIZE(this) if (.NOT. ALLOCATED(this(i)%list)) cycle do j = 1, SIZE(this(i)%list) k = k + 1 fixed(k) = this(i)%list(j)%chars enddo enddo integer :: ln, sz character(:), allocatable :: strings(:) ln = LEN_MAX(this) sz = getTableSize(this) allocate (character(ln) :: strings(sz)) strings(:) = fixedStringTable(this) joined='' end function pure function LEN_MAX(this) result(stringlen) integer :: stringlen type(StringTable), intent(IN) :: this(:) integer :: i, j stringlen = 0 end function pure function getTableSize(this) result(sz) integer :: sz type(StringTable), intent(IN) :: this(:) integer :: i sz = 0 end function end module stringtable_mod end gives the ICE pr65381_red.f90:15:0: pure function fixedStringTable(this) result(fixed) internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159 It compiles with gfortran 7.2.0 and trunk before r256284 and it is not fixed by revision r256310.
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #7 from Dominique d'Humieres ---
> Of course, commenting out the part in simplify.c makes the repeat_7.f90
> test fail. Also, when compiling the testcase in this PR the compiler
> uses 1.7 GB RAM, so I do think it makes sense to have *some* limit
> where we give up and defer to runtime.
I agree, but the limit should probably not hardcoded. In order to test large
strings with our rebuilding gfortran, I have highjacked
flag_max_array_constructor with the following patch:
--- ../_clean/gcc/fortran/simplify.c2018-01-05 20:02:38.0 +0100
+++ gcc/fortran/simplify.c 2018-01-07 12:20:45.0 +0100
@@ -6080,12 +6114,14 @@ gfc_simplify_repeat (gfc_expr *e, gfc_ex
len = e->value.character.length;
gfc_charlen_t nlen = ncop * len;
- /* Here's a semi-arbitrary limit. If the string is longer than 32 MB
- (8 * 2**20 elements * 4 bytes (wide chars) per element) defer to
+ /* Here's a semi-arbitrary limit. If the string is longer than 256 MB
+ (8 * 2**25 elements * 4 bytes (wide chars) per element) defer to
runtime instead of consuming (unbounded) memory and CPU at
compile time. */
- if (nlen > 8388608)
+ /* printf("nlen = %lld, limit = %lld\n", nlen, 4096ll *
flag_max_array_constructor); */
+ if (nlen > 4096ll * flag_max_array_constructor)
return NULL;
+ /* printf("result\n"); */
result = gfc_get_character_expr (e->ts.kind, &e->where, NULL, nlen);
for (size_t i = 0; i < (size_t) ncop; i++)
Note that on darwin repeat_7.f90 compiles, but does not link:
% time gfc repeat_7_db.f90 -fmax-array-constructor=100
final section layout:
__TEXT/__text addr=0x10E2E, size=0x00B0, fileOffset=0x0E2E,
type=1
__TEXT/__stubs addr=0x10EDE, size=0x001E, fileOffset=0x0EDE,
type=28
__TEXT/__stub_helper addr=0x10EFC, size=0x0042,
fileOffset=0x0EFC, type=32
__TEXT/__cstring addr=0x10F3E, size=0x0010, fileOffset=0x0F3E,
type=13
__TEXT/__const addr=0x10F50, size=0x801C, fileOffset=0x0F50,
type=0
__TEXT/__eh_frame addr=0x18F70, size=0x0088, fileOffset=0x8F70,
type=19
__DATA/__nl_symbol_ptr addr=0x180001000, size=0x0010,
fileOffset=0x80001000, type=29
__DATA/__la_symbol_ptr addr=0x180001010, size=0x0028,
fileOffset=0x80001010, type=27
__DATA/__huge addr=0x180001038, size=0x, fileOffset=0x,
type=25
ld: 32-bit RIP relative reference out of range (2147483784 max is +/-2GB): from
_main (0x10EA1) to _options.1.3769 (0x18F50) in '_main' from
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccs6xnfq.o for architecture
x86_64
collect2: error: ld returned 1 exit status
218.482u 16.499s 4:01.43 97.3% 0+0k 0+0io 2668pf+0w
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-07 Target Milestone|--- |8.0 Ever confirmed|0 |1 Known to fail||7.2.0 --- Comment #1 from Dominique d'Humieres --- Similar to pr50892, but at a different place.
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 Janne Blomqvist changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Janne Blomqvist --- Trying to compile the example produces ❯ gfortran -c pr83725.f90 pr83725.f90:29:21: integer :: ln, sz 1 Error: Unexpected data declaration statement at (1) pr83725.f90:30:43: character(:), allocatable :: strings(:) 1 Error: Unexpected data declaration statement at (1) pr83725.f90:33:24: allocate (character(ln) :: strings(sz)) 1 Error: Scalar INTEGER expression expected at (1) pr83725.f90:34:4: strings(:) = fixedStringTable(this) 1 Error: Unclassifiable statement at (1) pr83725.f90:35:10: joined='' 1 Error: Symbol ‘joined’ at (1) has no IMPLICIT type; did you mean ‘fixed’? pr83725.f90:31:6: ln = LEN_MAX(this) 1 Error: Symbol ‘ln’ at (1) has no IMPLICIT type pr83725.f90:32:6: sz = getTableSize(this) 1 Error: Symbol ‘sz’ at (1) has no IMPLICIT type
[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308 Jeffrey A. Law changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #7 from Jeffrey A. Law --- *** Bug 83724 has been marked as a duplicate of this bug. ***
[Bug middle-end/83724] [8 Regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83724 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Yes, a dup of 81308 which I've got prototype patches to fix. *** This bug has been marked as a duplicate of bug 81308 ***
[Bug middle-end/83721] [8 Regression] ICE: in generic_overlap, at gimple-ssa-warn-restrict.c:821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83721 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #1 from Jeffrey A. Law --- Matthias, can you reconfirm this is still a problem after r256321? I committed a fix from Martin S last night that should have fixed this.
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 --- Comment #3 from Dominique d'Humieres --- Created attachment 43053 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43053&action=edit right reproducer.
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 --- Comment #4 from Dominique d'Humieres --- > Trying to compile the example produces > ... Sorry about that (copy and paste problem). I have attached the right test.
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 --- Comment #5 from dominiq at tournesol dot lps.ens.fr --- Bugzilla seems down so I cannot check what is wrong with the code I have posted. I attach the test. Cheers, Dominique
[Bug target/83726] New: [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726
Bug ID: 83726
Summary: [8 Regression] ICE: in final_scan_insn, at
final.c:3063
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272 on aarch64-linux-gnu, building hyphy. worked around with -O2
$ cat HYDialogDefs.ii
typedef struct { long a, b, bottom, c; } d;
class e {
public:
e(d, bool);
};
long f;
void g() {
d h = {};
h.c = 70;
for (; f;)
new e(h, 0);
h.bottom = 0;
}
$ g++ -std=gnu++98 -O3 -c HYDialogDefs.ii
HYDialogDefs.ii: In function 'void g()':
HYDialogDefs.ii:13:1: error: could not split insn
}
^
(insn:TI 20 18 95 (set (reg:TI 1 x1 [101])
(const_wide_int 0x46)) "HYDialogDefs.ii":11 50
{*movti_aarch64}
(nil))
during RTL pass: final
HYDialogDefs.ii:13:1: internal compiler error: in final_scan_insn, at
final.c:3063
0x5607bb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x8413bf final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src/gcc/final.c:3063
0x84175f final(rtx_insn*, _IO_FILE*, int)
../../src/gcc/final.c:2065
0x841c6f rest_of_handle_final
../../src/gcc/final.c:4551
0x841c6f execute
../../src/gcc/final.c:4625
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/83727] New: [8 Regression] ICE (Segmentation fault) in local_class_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83727
Bug ID: 83727
Summary: [8 Regression] ICE (Segmentation fault) in
local_class_index
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272, building kakoune
$ cat normal.ii
namespace a {
template b *begin(b (&)[c]);
}
class d {
public:
d(const char *);
};
struct e {
int f;
d docstring;
void (*func)(int &, int);
};
namespace a {
template h i(h, h, g) { return 0; }
}
using a::begin;
template
auto i(j &&container, k l) -> decltype(begin(container)) {
return a::i(container, container, l);
}
enum { m };
template void n(int &, int) {
[] {
struct p {
} o[]{{}};
i(o, p{});
};
}
e cmds{'i', "", n};
$ g++ -std=gnu++11 -c -O0 normal.ii
normal.ii: In instantiation of 'decltype (a::begin(container)) i(j&&, k) [with
j = n(int&, int):: [with int = 0]::p (&)[1]; k = n(int&,
int):: [with int = 0]::p]':
normal.ii:18:6: required from here
normal.ii:18:6: internal compiler error: Segmentation fault
auto i(j &&container, k l) -> decltype(begin(container)) {
^
0x8803dda crash_signal
../../src/gcc/toplev.c:325
0x834effb local_class_index
../../src/gcc/cp/mangle.c:1925
0x83515a6 discriminator_for_local_entity
../../src/gcc/cp/mangle.c:1957
0x83515a6 write_local_name
../../src/gcc/cp/mangle.c:2058
0x83515a6 write_name
../../src/gcc/cp/mangle.c:964
0x8353698 write_encoding
../../src/gcc/cp/mangle.c:825
0x8351427 write_local_name
../../src/gcc/cp/mangle.c:2027
0x8351427 write_name
../../src/gcc/cp/mangle.c:964
0x8351ded write_class_enum_type
../../src/gcc/cp/mangle.c:2809
0x8351ded write_type
../../src/gcc/cp/mangle.c:
0x8352595 write_array_type
../../src/gcc/cp/mangle.c:3599
0x8352595 write_type
../../src/gcc/cp/mangle.c:2146
0x8351f05 write_type
../../src/gcc/cp/mangle.c:2303
0x8356b9b write_template_args
../../src/gcc/cp/mangle.c:2838
0x8351334 write_name
../../src/gcc/cp/mangle.c:933
0x8353698 write_encoding
../../src/gcc/cp/mangle.c:825
0x8357244 mangle_decl_string
../../src/gcc/cp/mangle.c:3791
0x835743d get_mangled_id
../../src/gcc/cp/mangle.c:3813
0x835743d mangle_decl(tree_node*)
../../src/gcc/cp/mangle.c:3851
0x89d1886 decl_assembler_name(tree_node*)
../../src/gcc/tree.c:687
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c/33167] Hex constant characters with \x escape not parsing correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167 Albert Chan changed: What|Removed |Added CC||albertmcchan at yahoo dot com --- Comment #4 from Albert Chan --- if gcc hex escapes is right, then gcc octal escape is wrong (it just look at first 3 octals) "\123" = "S" "\0123" = "\n3" ?? "\00123" = "\1" "23" ?? personally, i like this octal escape "bug"
[Bug debug/83728] New: [8 regression] FAIL: gcc.dg/guality/pr68037-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83728 Bug ID: 83728 Summary: [8 regression] FAIL: gcc.dg/guality/pr68037-1.c Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: aoliva at gcc dot gnu.org Target Milestone: --- Target: x86 On x86, r255569 caused: FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 error == 0x12345670 FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 frame->ip == 0x12345671 FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 frame->cs == 0x12345672 FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 frame->flags == 0x12345673 FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 frame->sp == 0x12345674 FAIL: gcc.dg/guality/pr68037-1.c -O2 line 33 frame->ss == 0x12345675 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 error == 0x12345670 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 frame->ip == 0x12345671 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 frame->cs == 0x12345672 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 frame->flags == 0x12345673 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 frame->sp == 0x12345674 FAIL: gcc.dg/guality/pr68037-1.c -O3 -g line 33 frame->ss == 0x12345675 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 error == 0x12345670 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 frame->ip == 0x12345671 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 frame->cs == 0x12345672 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 frame->flags == 0x12345673 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 frame->sp == 0x12345674 FAIL: gcc.dg/guality/pr68037-1.c -Os line 33 frame->ss == 0x12345675
[Bug middle-end/83729] New: AVR ICE on convert_memory_address_addr_space_1 at explow.c:300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83729 Bug ID: 83729 Summary: AVR ICE on convert_memory_address_addr_space_1 at explow.c:300 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: gandalf at winds dot org Target Milestone: --- Created attachment 43054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43054&action=edit Preprocessed file gcc version 8.0.0 20180107 (experimental) (GCC) gcc svn r256323 Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-bootstrap --disable-libssp Cross compiled on host using x86_64-pc-linux-gnu v7.2.0 ICE while compiling avr-libc svn r2546 Command: avr-gcc -save-temps -DHAVE_CONFIG_H -I. -I../../.. -I../../../common -I../../../include -I../../../include -Wall -W -Wstrict-prototypes -mmcu=avr2 -D__COMPILING_AVR_LIBC__ -mcall-prologues -Os -MT asctime_r.o -MD -MP -MF .deps/asctime_r.Tpo -c -o asctime_r.o ../../../libc/time/asctime_r.c -Wextra during RTL pass: expand ../../../libc/time/asctime_r.c: In function 'asctime_r': ../../../libc/time/asctime_r.c:57:16: internal compiler error: in convert_memory_address_addr_space_1, at explow.c:300 buffer[i] = ascdays[d++]; ~~^~ 0x51b973 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*, unsigned char, bool, bool) ../../gcc/explow.c:300 0x7ab83a convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*, unsigned char, bool, bool) ../../gcc/explow.c:474 0x7ab83a convert_memory_address_addr_space(scalar_int_mode, rtx_def*, unsigned char) ../../gcc/explow.c:402 0x7ab83a memory_address_addr_space(machine_mode, rtx_def*, unsigned char) ../../gcc/explow.c:416 0x791824 change_address_1 ../../gcc/emit-rtl.c:2288 0x7c200f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10185 0x7c1a6c expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10586 0x7c492f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9923 0x7cf6d3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5632 0x7d0f87 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5400 0x6ad998 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3692 0x6ad998 expand_gimple_stmt ../../gcc/cfgexpand.c:3790 0x6afdf7 expand_gimple_basic_block ../../gcc/cfgexpand.c:5810 0x6b52ae execute ../../gcc/cfgexpand.c:6416
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 --- Comment #6 from Janne Blomqvist --- Hmm, the attached testcase works just fine for me. No ICE observed.
[Bug target/83524] [8 Regression] bootstrap fails build a nvptx cross: ICE in get_insn_template, at final.c:2099
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83524 --- Comment #1 from Jakub Jelinek --- Can't reproduce with current trunk.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #3 from Eric Gallager --- Blocks had to be removed from the Objective-C sources in Emacs due to this bug: https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-12/msg00301.html
[Bug c++/83727] [8 Regression] ICE (Segmentation fault) in local_class_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83727 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- Dup of PR82514, but your testcase is smaller. *** This bug has been marked as a duplicate of bug 82514 ***
[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82514 --- Comment #3 from Markus Trippelsdorf --- *** Bug 83727 has been marked as a duplicate of this bug. ***
[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82514
--- Comment #4 from Markus Trippelsdorf ---
Smaller testcase from PR83727:
namespace a {
template b *begin(b (&)[c]);
}
class d {
public:
d(const char *);
};
struct e {
int f;
d docstring;
void (*func)(int &, int);
};
namespace a {
template h i(h, h, g) { return 0; }
}
using a::begin;
template
auto i(j &&container, k l) -> decltype(begin(container)) {
return a::i(container, container, l);
}
enum { m };
template void n(int &, int) {
[] {
struct p {
} o[]{{}};
i(o, p{});
};
}
e cmds{'i', "", n};
[Bug c++/83730] New: Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
Bug ID: 83730
Summary: Unnecessary generation of guard variables with
-fno-threadsafe-statics
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
Compiling the following example using -fno-threadsafe-statics and -Os still
generates the guard-variables for the member mTop. This is unnecessary and
occupies 8 Bytes on an avr target.
struct A {
A() = default; // if commented out, no guards are allocated
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
inline static T mTop;
};
int main() {
B::foo();
}
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730 --- Comment #1 from Wilhelm M --- If the defaulted ctor is commented out, the guards aren't generated. Still is even stranger ...
[Bug testsuite/67905] running the libstdc++ testsuite as root removed /dev/null from my system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67905 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Eric Gallager --- I'm no longer using the computer where I have to be root so this bug is no longer relevant for me.
[Bug libstdc++/83709] Inserting duplicates into an unordered associative containers causes the container to invalidate iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83709 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- I'm going to take a look, thanks.
[Bug target/83524] [8 Regression] bootstrap fails build a nvptx cross: ICE in get_insn_template, at final.c:2099
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83524 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matthias Klose --- yes, at least r256272 builds.
[Bug fortran/83731] New: PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 Bug ID: 83731 Summary: PDT length parameter incorrectly rejected at run-time with -fcheck=bounds Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: berke.durak at gmail dot com Target Milestone: --- Using the nightly 20180107 trunk rev. 256317: % cat pdt.f90 module pdt_m implicit none type :: vec(k) integer, len :: k=10 integer :: foo(k) end type vec contains function total(a) type(vec(k=*)), intent(in) :: a integer :: total total=sum(a%foo) end function total end module pdt_m program test_pdt use pdt_m implicit none type(vec(k=123)) :: u u%foo=1 print *,'total=',total(u) end program test_pdt % /usr/local/gfortran-bin/bin/gfortran pdt.f90 -fcheck=bounds -g -O0 -o pdt -Wall -Wextra % LD_LIBRARY_PATH=/usr/local/gfortran-bin/lib64:$LD_LIBRARY_PATH ./pdt In file 'pdt.f90', around line 14 Fortran runtime error: The value of the PDT LEN parameter 'k' does not agree with that in the dummy declaration Error termination. Backtrace: #0 0x40096a in __pdt_m_MOD_total at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:13 #1 0x400c45 in test_pdt at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:22 #2 0x400cce in main at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:17 GNU Fortran (GCC) 8.0.0 20180107 (experimental) [trunk revision 256317] Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-07 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug fortran/83725] [8 Regression] Another ICE:: in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83725 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Dominique d'Humieres --- > Hmm, the attached testcase works just fine for me. No ICE observed. This is pr82923 comment 4: I had the patch in my working tree. The ICE is gone once the patch has been reverted. Closing as INVALID. Sorry for the noise.
[Bug tree-optimization/83693] missing strlen optimization for array of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83693 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-07 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Testing a patch.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #14 from Thomas Koenig --- What about Index: resolve.c === --- resolve.c (Revision 256284) +++ resolve.c (Arbeitskopie) @@ -10120,8 +10120,8 @@ resolve_ordinary_assign (gfc_code *code, gfc_names bool rval = false; gfc_expr *lhs; gfc_expr *rhs; - int llen = 0; - int rlen = 0; + ptrdiff_t llen = 0; + ptrdiff_t rlen = 0; int n; gfc_ref *ref; symbol_attribute attr; does this help?
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #15 from Dominique d'Humieres ---
> does this help?
Nope, I get
../../work/gcc/fortran/resolve.c: In function 'bool
resolve_ordinary_assign(gfc_code*, gfc_namespace*)':
../../work/gcc/fortran/resolve.c:10281:27: error: format '%d' expects argument
of type 'int', but argument 3 has type 'ptrdiff_t' {aka 'long int'}
[-Werror=format=]
llen, rlen, &code->loc);
^
../../work/gcc/fortran/resolve.c:10281:27: error: format '%d' expects argument
of type 'int', but argument 4 has type 'ptrdiff_t' {aka 'long int'}
[-Werror=format=]
i.e., in
gfc_warning_now (OPT_Wcharacter_truncation,
"CHARACTER expression will be truncated "
"in assignment (%d/%d) at %L",
llen, rlen, &code->loc);
I did not find how to change the %d format (%lld does not work).
[Bug c++/83732] New: wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 Bug ID: 83732 Summary: wrong warning about non-POD field Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 43055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43055&action=edit test-case The attached test-case demonstrates the problem: --- $ LC_ALL=C g++ -Wall pod.cpp pod.cpp:11:16: warning: ignoring packed attribute because of unpacked non-POD field 'ttt tst::a' struct ttt a; $ ./a.out size1=5 size2=8 --- As can be seen from the output, the attribute was actually not ignored. I actually think there are no non-POD members, so the warning is spurious and the resulting code is correct. And indeed, clang++ generates no such warning and the packing works fine there too.
[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81420 --- Comment #1 from Ed Catmur --- icc 18 also has this bug. MSVC 19 2017 (with /permissive-) miscompiles by copying the bound subobject to a separate complete object before binding, so the reference does not dangle but the derived and base class objects are still destructed prematurely.
[Bug tree-optimization/83693] missing strlen optimization for array of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83693 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00436.html
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #16 from Thomas Koenig --- I hadn't actually compiled this... but then this at least compiles. Index: resolve.c === --- resolve.c (Revision 256284) +++ resolve.c (Arbeitskopie) @@ -10120,8 +10120,8 @@ resolve_ordinary_assign (gfc_code *code, gfc_names bool rval = false; gfc_expr *lhs; gfc_expr *rhs; - int llen = 0; - int rlen = 0; + ptrdiff_t llen = 0; + ptrdiff_t rlen = 0; int n; gfc_ref *ref; symbol_attribute attr; @@ -10219,8 +10219,8 @@ resolve_ordinary_assign (gfc_code *code, gfc_names if (rlen && llen && rlen > llen) gfc_warning_now (OPT_Wcharacter_truncation, "CHARACTER expression will be truncated " -"in assignment (%d/%d) at %L", -llen, rlen, &code->loc); +"in assignment (%ld/%ld) at %L", +(long int) llen, (long int) rlen, &code->loc); } /* Ensure that a vector index expression for the lvalue is evaluated I don't have the RAM to test it on my system at the moment.
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730 --- Comment #2 from Wilhelm M --- Additionally: if one only uses a global variable of type A, no guards are creates at all. But this should be conceptually equivalent to the above use case.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #17 from Janne Blomqvist --- I have fixed resolve_ordinary_assign as part of a larger patch fixing similar issues in the frontend (you also need to change extract_int to extract_hwi). I can submit it once I have tackled the 32-bit regression Dominique reported on IRC.
