[Bug c++/88348] New: ICE in pp_cxx_unqualified_id when handling pointer to pointer to member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88348
Bug ID: 88348
Summary: ICE in pp_cxx_unqualified_id when handling pointer to
pointer to member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhouzhouyi at gmail dot com
Target Milestone: ---
g++ from git ICE when compiling following program because of incorrect
handling pointer to pointer to member
---
void* operator new (__SIZE_TYPE__, void *p) { return p; }
int i;
struct Z {
void f(int = 0) const;
};
template struct helper {};
typedef void (Z::**QF)(int) const;
template void check1( helper * ) { }
---
./cc1plus /root/zzy/mangle52.C
void* operator new(long unsigned int, void*)‘
At global scope:
Segmentation fault
11 | template void check1( helper * ) { }
|^~
0x105c80f crash_signal
../../gcc-git/gcc/toplev.c:326
0x812b40 pp_cxx_unqualified_id
../../gcc-git/gcc/cp/cxx-pretty-print.c:128
0x812e63 pp_cxx_unqualified_id
../../gcc-git/gcc/cp/cxx-pretty-print.c:173
0x813ae6 pp_cxx_qualified_id
../../gcc-git/gcc/cp/cxx-pretty-print.c:291
0x8166d5 cxx_pretty_printer::simple_type_specifier(tree_node*)
../../gcc-git/gcc/cp/cxx-pretty-print.c:1338
0xb189db pp_c_specifier_qualifier_list(c_pretty_printer*, tree_node*)
../../gcc-git/gcc/c-family/c-pretty-print.c:483
0xb18a31 pp_c_specifier_qualifier_list(c_pretty_printer*, tree_node*)
../../gcc-git/gcc/c-family/c-pretty-print.c:447
0xb18c40 c_pretty_printer::type_id(tree_node*)
../../gcc-git/gcc/c-family/c-pretty-print.c:615
0x818481 cxx_pretty_printer::type_id(tree_node*)
../../gcc-git/gcc/cp/cxx-pretty-print.c:1833
0x814d39 pp_cxx_new_expression
../../gcc-git/gcc/cp/cxx-pretty-print.c:722
0x815cf0 cxx_pretty_printer::expression(tree_node*)
../../gcc-git/gcc/cp/cxx-pretty-print.c:1127
0x897e2e dump_expr
../../gcc-git/gcc/cp/error.c:2796
0x898a22 expr_to_string(tree_node*)
../../gcc-git/gcc/cp/error.c:3078
0x89b925 cp_printer
../../gcc-git/gcc/cp/error.c:4087
0x1d2224d pp_format(pretty_printer*, text_info*)
../../gcc-git/gcc/pretty-print.c:1392
0x1d03dcd diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-git/gcc/diagnostic.c:1015
0x1d040a3 diagnostic_impl
../../gcc-git/gcc/diagnostic.c:1159
0x1d04da8 error_at(unsigned int, char const*, ...)
../../gcc-git/gcc/diagnostic.c:1461
0x7e1833 potential_constant_expression_1
../../gcc-git/gcc/cp/constexpr.c:5947
0x7e306a potential_constant_expression_1(tree_node*, bool, bool, bool, int)
../../gcc-git/gcc/cp/constexpr.c:6339
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/88346] [9 Regression] Inconsistent list of CPUs supported by the rs6000 backend after r266502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88346 --- Comment #1 from Alan Modra --- OK, good, the %e is doing its job in showing up missing cases.. And thanks for pointing out the silly typo.
[Bug target/88346] [9 Regression] Inconsistent list of CPUs supported by the rs6000 backend after r266502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88346 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-04 CC|amodra at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
--- Comment #5 from bin cheng ---
(In reply to seurer from comment #4)
> Any progress on this? It really slows down test runs as it hangs twice and
> has to wait for the timeout to occur to continue.
Sorry for being slow. I am still not very sure where the issue is.
Look at the dump before ivcanon (at ivcanon the code diverges w/o the patch):
;; basic block 7, loop depth 1, count 8656061039 (estimated locally), maybe
hot
;;prev block 6, next block 24, flags: (NEW, REACHABLE, VISITED)
;;pred: 6 [always] count:1073312328 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;23 [always] count:7582748748 (estimated locally)
(FALLTHRU,DFS_BACK)
# .MEM_95 = PHI <.MEM_62(6), .MEM_94(23)>
# RANGE [0, 4] NONZERO 7
# n_63 = PHI <0(6), _28(23)>
# RANGE [-1, 2]
_19 = n_63 + -1;
# RANGE [-1, 2]
_20 = (integer(kind=8)D.4) _19;
# RANGE [0, 2] NONZERO 3
_22 = MAX_EXPR <_20, 0>;
# RANGE [0, 2] NONZERO 3
_25 = (sizetype) _22;
# RANGE [1, 2] NONZERO 3
_26 = MAX_EXPR <_25, 1>;
# .MEM_74 = VDEF <.MEM_95>
# PT = null { D.2402 }
# ALIGN = 8, MISALIGN = 0
# USE = nonlocal null
# CLB = nonlocal null
_27 = mallocD.235 (_26);
# .MEM_75 = VDEF <.MEM_74>
D.2389.spanD.2142 = 1;
# .MEM_76 = VDEF <.MEM_75>
MEM[(struct dtype_type *) + 24B] = {};
# .MEM_77 = VDEF <.MEM_76>
D.2389.dtypeD.2141.elem_lenD.2079 = 1;
# .MEM_78 = VDEF <.MEM_77>
D.2389.dtypeD.2141.rankD.2081 = 1;
# .MEM_79 = VDEF <.MEM_78>
D.2389.dtypeD.2141.typeD.2082 = 6;
# .MEM_80 = VDEF <.MEM_79>
D.2389.dimD.2143[0].lboundD.2102 = 1;
# .MEM_81 = VDEF <.MEM_80>
D.2389.dimD.2143[0].uboundD.2103 = _20;
# .MEM_82 = VDEF <.MEM_81>
D.2389.dimD.2143[0].strideD.2101 = 1;
# .MEM_83 = VDEF <.MEM_82>
D.2389.dataD.2139 = pretmp_65;
# .MEM_84 = VDEF <.MEM_83>
D.2389.offsetD.2140 = -1;
# .MEM_85 = VDEF <.MEM_84>
# PT = nonlocal escaped null { D.2389 D.2401 }
# USE = nonlocal escaped null { D.2389 D.2401 }
# CLB = nonlocal escaped
_47 = _gfortran_internal_packD.1827 ();
if (_20 >= _22)
goto ; [67.00%]
else
goto ; [33.00%]
;;succ: 24 [67.0% (guessed)] count:5799560912 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;8 [33.0% (guessed)] count:2856500127 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;; basic block 24, loop depth 1, count 5799560912 (estimated locally), maybe
hot
;;prev block 7, next block 8, flags: (NEW)
;;pred: 7 [67.0% (guessed)] count:5799560912 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
goto ; [100.00%]
;;succ: 9 [always] count:5799560912 (estimated locally) (FALLTHRU)
;; basic block 8, loop depth 1, count 2856500143 (estimated locally), maybe
hot
;;prev block 24, next block 9, flags: (NEW, REACHABLE, VISITED)
;;pred: 7 [33.0% (guessed)] count:2856500127 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
# .MEM_86 = VDEF <.MEM_85>
# PT = null { D.2403 }
# ALIGN = 8, MISALIGN = 0
# USE = nonlocal null
# CLB = nonlocal null
_49 = mallocD.235 (_26);
# .MEM_87 = VDEF <.MEM_86>
# USE = nonlocal null
# CLB = nonlocal null
memcpyD.588 (_49, _47, _25);
;;succ: 9 [always (adjusted)] count:2856500143 (estimated locally)
(FALLTHRU,EXECUTABLE)
;; basic block 9, loop depth 1, count 8656061039 (estimated locally), maybe
hot
;;prev block 8, next block 25, flags: (NEW, REACHABLE, VISITED)
;;pred: 8 [always (adjusted)] count:2856500143 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;24 [always] count:5799560912 (estimated locally) (FALLTHRU)
# PT = nonlocal escaped null { D.2389 D.2401 D.2403 }
# transfer.5_53 = PHI <_49(8), _47(24)>
# .MEM_56 = PHI <.MEM_87(8), .MEM_85(24)>
if (_20 > 0)
goto ; [41.48%]
else
goto ; [58.52%]
;;succ: 10 [41.5% (guessed)] count:3590534146 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;25 [58.5% (guessed)] count:5065526893 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;; basic block 25, loop depth 1, count 5065526893 (estimated locally), maybe
hot
;;prev block 9, next block 10, flags: (NEW)
;;pred: 9 [58.5% (guessed)] count:5065526893 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
goto ; [100.00%]
;;succ: 11 [always] count:5065526893 (estimated locally) (FALLTHRU)
;; basic block 10, loop depth 1, count 3590534111 (estimated locally), maybe
hot
;;prev block 25, next block 11, flags: (NEW, REACHABLE, VISITED)
;;pred: 9 [41.5% (guessed)] count:3590534146 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
# .MEM_88 = VDEF <.MEM_56>
# USE = nonlocal null
# CLB = nonlocal null
memcpyD.588 (_27, transfer.5_53, _25);
;;succ: 11 [always (adjusted)] count:3590534111 (estimated locally)
(FALLTHRU,EXECUTABLE)
;; basic block 11, loop depth 1, count 8656061039 (estimated locally), maybe
hot
;;prev block 10, next block 26, flags: (NEW, REACHABLE,
[Bug rtl-optimization/88347] New: ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347 Bug ID: 88347 Summary: ICE in begin_move_insn, at sched-ebb.c:175 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gcc-9.0.0-alpha20181202 snapshot (r266729) ICEs when compiling gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c w/ -mcpu=603e -O1 -fsched-stalled-insns -fsched2-use-superblocks -fschedule-insns2 -fno-dce -fno-guess-branch-probability --param max-cse-insns=4: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202 -mcpu=603e -O1 -fsched-stalled-insns -fsched2-use-superblocks -fschedule-insns2 -fno-dce -fno-guess-branch-probability --param max-cse-insns=4 -c gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c during RTL pass: sched2 gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c: In function 'test_switch': gcc/testsuite/gcc.target/powerpc/ppc-switch-2.c:32:1: internal compiler error: in begin_move_insn, at sched-ebb.c:175 32 | } | ^ 0x759da8 begin_move_insn /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:175 0x145ec0b commit_schedule /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/haifa-sched.c:6228 0x1469a90 schedule_block(basic_block_def**, void*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/haifa-sched.c:7065 0x14f47e9 schedule_ebb(rtx_insn*, rtx_insn*, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:537 0x14f4f64 schedule_ebbs() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:657 0xcc2eac rest_of_handle_sched2 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-rgn.c:3738 0xcc2eac execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-rgn.c:3876
[Bug rtl-optimization/79593] [7/8/9 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #20 from Jeffrey A. Law ---
Could we perhaps attack this in RTL DSE?
If we look at the RTL .dse2 dump we have:
(insn 84 24 92 4 (set (reg:SI 0 ax [116])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.c":21:35 67
{*movsi_internal}
(nil))
(insn 92 84 93 4 (set (mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])
(reg:SI 0 ax [116])) "j.c":21:35 67 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 0 ax [116])
(nil)))
insn 92 is clearly a dead store.
Walking up in the dump file we have:
**scanning insn=84
mem: (reg/f:SI 7 sp)
after canon_rtx address: (reg/f:SI 7 sp)
after cselib_expand address: (reg/f:SI 7 sp)
after canon_rtx address: (reg/f:SI 7 sp)
varying cselib base=1:1 offset = 0
processing cselib load mem:(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])
mems_found = 0, cannot_delete = true
**scanning insn=92
mem: (reg/f:SI 7 sp)
after canon_rtx address: (reg/f:SI 7 sp)
after cselib_expand address: (reg/f:SI 7 sp)
after canon_rtx address: (reg/f:SI 7 sp)
varying cselib base=1:1 offset = 0
processing cselib store [0..4)
mems_found = 1, cannot_delete = false
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #33 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Dec 4 04:22:37 2018 New Revision: 266770 URL: https://gcc.gnu.org/viewcvs?rev=266770=gcc=rev Log: 2018-12-03 Sandra Loosemore PR c/59039 gcc/ * doc/extend.texi (Nonlocal gotos): New section. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug target/88346] New: [9 Regression] Inconsistent list of CPUs supported by the rs6000 backend after r266502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88346 Bug ID: 88346 Summary: [9 Regression] Inconsistent list of CPUs supported by the rs6000 backend after r266502 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: amodra at gcc dot gnu.org Target Milestone: --- Target: powerpc-*-linux-gnu After r266502 gcc still lists powerpc64, rs64, and titan as valid arguments to -mcpu when emitting diagnostic for invalid -mcpu= argument: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202 -mcpu=list powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202: error: unrecognized argument in option '-mcpu=list' powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202: note: valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64 titan powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202: fatal error: no input files compilation terminated. However, when provided w/ -mcpu=powerpc64, =rs64, or =titan, it now fails w/ the following: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202 -mcpu=powerpc64 -w -c test.c -o /dev/null powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181202: error: Missing -mcpu option in ASM_SPEC_CPU? which actually agrees w/ what is defined for ASM_CPU_SPEC in config/rs6000/rs6000.h. I also believe that ASM_SPEC_CPU in :%eMissing -mcpu option in ASM_SPEC_CPU?\n defined in config/rs6000/aix72.h, config/rs6000/aix71.h, and config/rs6000/rs6000.h should actually read ASM_CPU_SPEC.
[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to kargl from comment #1) > > (In reply to Matt Thompson from comment #0) > > > All, > > > > > > A colleague of mine encountered an issue with 8.2.0 (but it's also in > > > 7.3.0 > > > at least). We believe it might be a bug since our reading of the Standard > > > seems to make it legal. > > > > > > Namely if this program: > > > > > > PROGRAM test > > >USE, INTRINSIC :: ieee_arithmetic > > >IMPLICIT NONE > > >REAL :: inf > > >inf = IEEE_VALUE(inf, IEEE_POSITIVE_INF) > > > END PROGRAM test > > > > > > is compiled with -ffpe-trap=overflow the code FPEs: > > > > gfortran's IEEE modules and the -ffpe-trap option are independent > > of each other. As the manual states, -ffpe-trap is a *debugging* > > option, and will enabling traps on floating point exceptions. You > > specifically requested an overflow trap. What do you expect to > > happen? > > > > The likely correct solution is to manipulate the halting > > behavior with a combination of IEEE_GET_HALTING_MODE and > > IEEE_SET_HALTING_MODE. In fact, F2018, 17.11.6 contains > > this exact example. > > > >Example. To store the halting mode for IEEE_OVERFLOW, do a > >calculation without halting, and restore the halting mode later: > > > >USE, INTRINSIC :: IEEE_ARITHMETIC > >LOGICAL HALTING > >... > >CALL IEEE_GET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Store halting mode > >CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, .FALSE.) ! No halting > >... ! calculation without halting > >CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Restore halting > > mode > > > > whether or not these functions works is something that I > > haven't investigated. > > Just tested. > > program test >use, intrinsic :: ieee_arithmetic >implicit none >real :: inf >logical h >call ieee_get_halting_mode(ieee_overflow, h) ! store halting mode >call ieee_set_halting_mode(ieee_overflow, .false.) ! no halting >inf = ieee_value(inf, ieee_positive_inf) >print *, inf >call ieee_set_halting_mode(ieee_overflow, h) ! restore halting mode > end program test > > % gfcx -o z a.f90 && ./z > Infinity > % gfcx -o z -ffpe-trap=overflow a.f90 && ./z > Infinity > > This seems to give the desired behavior. Something like the following is probably want people want. I don't know how robust this is. Index: libgfortran/ieee/ieee_arithmetic.F90 === --- libgfortran/ieee/ieee_arithmetic.F90(revision 266766) +++ libgfortran/ieee/ieee_arithmetic.F90(working copy) @@ -861,6 +861,7 @@ contains real(kind=4), intent(in) :: X type(IEEE_CLASS_TYPE), intent(in) :: CLASS +logical flag select case (CLASS%hidden) case (1) ! IEEE_SIGNALING_NAN @@ -888,8 +889,15 @@ contains case (9) ! IEEE_POSITIVE_NORMAL res = 42 case (10)! IEEE_POSITIVE_INF +if (ieee_support_halting(ieee_overflow)) then + call ieee_get_halting_mode(ieee_overflow, flag) + call ieee_set_halting_mode(ieee_overflow, .false.) +end if res = huge(res) res = res * res +if (ieee_support_halting(ieee_overflow)) then + call ieee_set_halting_mode(ieee_overflow, flag) +end if case default ! IEEE_OTHER_VALUE, should not happen res = 0 end select
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #5 from pkoning at gcc dot gnu.org --- Could you post the full config specification and what the build system is? It seems hard to reproduce, and it is rather puzzling for a powerpc build to trigger a check that is explicitly there for pdp11 only.
[Bug middle-end/88345] -Os overrides -finline-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Martin Sebor --- I think the expected and most useful behavior is let the -falign-functions=n setting on the command line override whatever default may be used for each optimization level, on the basis that the more specific setting should win over the more general one.
[Bug middle-end/88345] New: -Os overrides -finline-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Bug ID: 88345
Summary: -Os overrides -finline-functions=N on the command line
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Os effect on -falign-functions is documented in a confusing or even
contradictory way:
Optimize for size. -Os enables all -O2 optimizations except those that
often increase code size:
-falign-functions -falign-jumps
-falign-labels -falign-loops
-fprefetch-loop-arrays -freorder-blocks-algorithm=stc
It also enables -finline-functions, causes the compiler to tune for code
size rather than execution speed, and performs further optimizations designed
to reduce code size.
The first sentence implies -Os is doesn't enable -finline-functions, but the
second sentence contradicts it.
The documentation for -finline-functions=n doesn't help. It just says:
If n is not specified or is zero, use a machine-dependent default.
I haven't been able to find a way to determine the machine-dependent default
except by testing.
An experiment with an x86_64 compiler shows that -Os overrides whatever
-falign-functions option is specified on the command line. Curiously, though,
with -O2 GCC does honor the -falign-functions=n setting.
Clang, on the other hand, does the opposite: it honors the -falign-functions=n
setting with -Os and ignores it with -O2.
$ cat u.c && gcc -Os -c -Wall -falign-functions=2 u.c && objdump -d u.o
void f (void) { }
void g (void) { }
u.o: file format elf64-x86-64
Disassembly of section .text:
:
0: c3 retq
0001 :
1: c3 retq
[Bug c++/88174] Make __real__ += __val usable in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174 --- Comment #4 from emsr at gcc dot gnu.org --- Never mind.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- The test passes all assertions with both of my powerpc64*-linux cross compilers (i.e., BE and LE).
[Bug middle-end/71905] Values passed to -Wlarger-than= and -Wframe-larger-than= and -Wstack-usage= should accept KB and MB suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71905 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 Known to fail||7.3.0, 8.2.0 --- Comment #6 from Martin Sebor --- A fix for this was implemented for GCC 9 in r262910.
[Bug c++/88320] GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||dmalcolm at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- I think it would be nice if the hint suggested a valid fix. Let's let David decide if it's worth trying to fix (btw., it affects the whole C family of front-ends, not just C++).
[Bug libstdc++/82716] struct/class vs. tuple_element/tuple_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82716 --- Comment #4 from Jonathan Wakely --- (In reply to Marc Mutz from comment #0) > Here's a stripped-down example: https://godbolt.org/g/sUZxAQ > Works with -stdlib=libc++: https://godbolt.org/g/bW4u1u But not if you use 'struct' instead of 'class': https://godbolt.org/z/kCb32t The only difference is which class-key causes a warning and which one doesn't.
[Bug c++/88344] New: sole attribute specification in a class silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88344
Bug ID: 88344
Summary: sole attribute specification in a class silently
accepted
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The C++ front-end silently accepts sole attribute specifications within a class
that don't apply to any member of the class. The C front-end (and Clang and
ICC) issue a warning.
$ (set -x && cat t.c && gcc -S -Wall t.c && gcc -S -Wall -xc++ t.c)
+ cat t.c
struct B {
__attribute__ ((always_inline));
};
+ gcc -S -Wall t.c
t.c:2:3: warning: empty declaration
2 | __attribute__ ((always_inline));
| ^
+ gcc -S -Wall -xc++ t.c
The real code that this came up in actually looked more like this:
struct A
{
void* alloc (int); __attribute__ ((alloc_align (2)));
// ...
};
I.e., there was a spurious semicolon before the __attribute__ keyword. GCC
ended up swallowing and ignoring the attribute with no warning.
[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337
--- Comment #1 from emsr at gcc dot gnu.org ---
LOL, this compiles:
// P1330R0 - Changing the active member of a union inside constexpr
union Foo
{
int i;
float f;
};
constexpr int
use()
{
Foo foo{};
foo.i = 3;
foo.f = 1.2f;
return 1;
}
[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > (In reply to Matt Thompson from comment #0) > > All, > > > > A colleague of mine encountered an issue with 8.2.0 (but it's also in 7.3.0 > > at least). We believe it might be a bug since our reading of the Standard > > seems to make it legal. > > > > Namely if this program: > > > > PROGRAM test > >USE, INTRINSIC :: ieee_arithmetic > >IMPLICIT NONE > >REAL :: inf > >inf = IEEE_VALUE(inf, IEEE_POSITIVE_INF) > > END PROGRAM test > > > > is compiled with -ffpe-trap=overflow the code FPEs: > > gfortran's IEEE modules and the -ffpe-trap option are independent > of each other. As the manual states, -ffpe-trap is a *debugging* > option, and will enabling traps on floating point exceptions. You > specifically requested an overflow trap. What do you expect to > happen? > > The likely correct solution is to manipulate the halting > behavior with a combination of IEEE_GET_HALTING_MODE and > IEEE_SET_HALTING_MODE. In fact, F2018, 17.11.6 contains > this exact example. > >Example. To store the halting mode for IEEE_OVERFLOW, do a >calculation without halting, and restore the halting mode later: > >USE, INTRINSIC :: IEEE_ARITHMETIC >LOGICAL HALTING >... >CALL IEEE_GET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Store halting mode >CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, .FALSE.) ! No halting >... ! calculation without halting >CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Restore halting mode > > whether or not these functions works is something that I > haven't investigated. Just tested. program test use, intrinsic :: ieee_arithmetic implicit none real :: inf logical h call ieee_get_halting_mode(ieee_overflow, h) ! store halting mode call ieee_set_halting_mode(ieee_overflow, .false.) ! no halting inf = ieee_value(inf, ieee_positive_inf) print *, inf call ieee_set_halting_mode(ieee_overflow, h) ! restore halting mode end program test % gfcx -o z a.f90 && ./z Infinity % gfcx -o z -ffpe-trap=overflow a.f90 && ./z Infinity This seems to give the desired behavior.
[Bug c++/88174] Make __real__ += __val usable in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174 --- Comment #3 from emsr at gcc dot gnu.org --- Created attachment 45150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45150=edit Special case REALPART_EXPR, IMAGPART_EXPR in cxx_eval_store_expression. Obeying the smart people. ;-) I reverted the workaround in libstdc++ that I needed because of this. With this patch and reverting those changes libstdc++ works (C++20 constexpr complex). Checking everything to see if I broke anything. I shoud have a testcase somewhere too. I didn't limit this to C++20. What do you all think?
[Bug target/88343] [7/8/9 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
Iain Sandoe changed:
What|Removed |Added
Target|powerpc-darwin |powerpc-darwin,
||powerpc-linux-gnu
--- Comment #3 from Iain Sandoe ---
actually, m32 powerpc-linux-gnu seems affected too.
The only change that the commit causing this introduced was makrking the
picbase as non-copyable.
-
$ echo "void foo (void) {} " | ./gcc/xgcc -Bgcc -x c - -S -o t.s -O2 -fPIC
-fomit-frame-pointer -m32
$ more t.s
.file ""
.machine power4
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
stwu 1,-16(1)
.cfi_def_cfa_offset 16
stw 30,8(1)
.cfi_offset 30, -8
ori 2,2,0
lwz 30,8(1)
addi 1,1,16
.cfi_restore 30
.cfi_def_cfa_offset 0
blr
.cfi_endproc
.LFE0:
.size foo,.-foo
.ident "GCC: (GNU) 9.0.0 20181203 (experimental) [trunk revision
266733]"
.section.note.GNU-stack,"",@progbits
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 pkoning at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pkoning at gcc dot gnu.org --- Comment #3 from pkoning at gcc dot gnu.org --- Strange. I'll look.
[Bug fortran/88298] Bogus conversion warning for CSHIFT with -fno-range-check -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
--- Comment #1 from Harald Anlauf ---
The problem appears here:
Breakpoint 1, gfc_resolve_cshift (f=0x2431950, array=0x23bc1f0,
shift=0x23bc880, dim=0x23bcce0) at ../../trunk/gcc/fortran/iresolve.c:836
836 gfc_resolve_dim_arg (dim);
(gdb) p dim->ts.kind
$1 = 4
(gdb) n
838 if (dim->ts.kind != shift->ts.kind)
(gdb) p dim->ts.kind
$2 = 8
(gdb) l
833 }
834 else
835 {
836 gfc_resolve_dim_arg (dim);
837 /* Convert dim to shift's kind to reduce variations. */
838 if (dim->ts.kind != shift->ts.kind)
839 gfc_convert_type_warn (dim, >ts, 2, 0);
840 }
841 }
842
Function gfc_resolve_dim_arg converts the kind and is the cause of the
warning.
The above code points to this rather old commit:
r130391 | jvdelisle | 2007-11-24 01:25:01 +0100 (Sat, 24 Nov 2007) | 20 lines
However, the real point probably is that gfc_index_integer_kind = 8 for -m64,
and gfc_resolve_dim_arg does the conversion from default kind = 4 to the
gfc_index_integer_kind:
if (dim->ts.kind != gfc_index_integer_kind)
{
gfc_typespec ts;
gfc_clear_ts ();
ts.type = BT_INTEGER;
ts.kind = gfc_index_integer_kind;
gfc_convert_type_warn (dim, , 2, 0);
}
Deep down the -f(no-)range-check apparently controls whether we get
the warning.
Wouldn't it be better/safer to convert dim/shift to their largest kind
involved?
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #18 from Wilco --- (In reply to Jeffrey A. Law from comment #17) > Or just emit a blockage insn to avoid the undesirable code motion. I tried that already, it doesn't affect the forward substitution - I guess it simply assumes it is always valid, and a function never writes to SFP/SP/FP.
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #17 from Jeffrey A. Law --- Or just emit a blockage insn to avoid the undesirable code motion.
[Bug fortran/88328] ICE in resolve_tag_format, at fortran/io.c:1641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88328
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-12-03
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Affects versions down to at least gcc-5 :
>
>
> $ cat z1.f90
> program p
>character(3), parameter :: a(0) = [character(3)::]
>print a
> end
>
>
> $ gfortran-9-20181202 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb2ec9f crash_signal
> ../../gcc/toplev.c:326
> 0x63ddee resolve_tag_format
> ../../gcc/fortran/io.c:1641
I get
% gfcx -c a.f90
a.f90:3:10:
3 |print a
| 1
Error: FORMAT tag at (1) cannot be a zero-sized array
with this patch
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266710)
+++ gcc/fortran/io.c(working copy)
@@ -1636,6 +1636,12 @@ resolve_tag_format (gfc_expr *e)
gfc_expr *r;
gfc_char_t *dest, *src;
+ if (e->value.constructor == NULL)
+ {
+ gfc_error ("FORMAT tag at %C cannot be a zero-sized array");
+ return false;
+ }
+
n = 0;
c = gfc_constructor_first (e->value.constructor);
len = c->expr->value.character.length;
@@ -3231,12 +3237,17 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
{
gfc_expr *e;
io_kind k;
+ locus loc_tmp;
/* This is set in any case. */
gcc_assert (dt->dt_io_kind);
k = dt->dt_io_kind->value.iokind;
+ loc_tmp = gfc_current_locus;
+ gfc_current_locus = *loc;
RESOLVE_TAG (_format, dt->format_expr);
+ gfc_current_locus = loc_tmp;
+
RESOLVE_TAG (_rec, dt->rec);
RESOLVE_TAG (_spos, dt->pos);
RESOLVE_TAG (_advance, dt->advance);
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #16 from Wilco --- (In reply to Christophe Lyon from comment #9) > Created attachment 45138 [details] > QEMU traces for --with-cpu=cortex-m3 / QEMU --cpu cortex-m3 Thanks, I can reproduce this now. It fails due to sched1 scheduling the move before the sp restore (correct at this point since it doesn't use a frame pointer) and reload then forward propagates a frame pointer use into it. Even if I add additional clobbers for sfp it won't block the substitution. So maybe we need an unspec around the address generation to be safe.
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #4 from mateuszb at poczta dot onet.pl ---
W dniu 03.12.2018 o 21:21, pinskia at gcc dot gnu.org pisze:
> --- Comment #1 from Andrew Pinski ---
> Can you attach the preprocessed source as requested by
> https://gcc.gnu.org/bugs/ ?
Now slicetype.ii (in 7z archive). This bug is newer -- probably from r266726
Step to reproduce:
$ g++ -c -O3 -march=core-avx2 slicetype.ii
f:/x265/source/encoder/slicetype.cpp: In member function 'void
x265_12bit::Lookahead::cuTree(x265_12bit::Lowres**, int, bool)':
f:/x265/source/encoder/slicetype.cpp:2086:1: error: insn outside basic block
2086 | }
| ^
(insn 6071 5573 6072 (parallel [
(set (reg:DI 4089)
(plus:DI (reg/f:DI 19 frame)
(const_int -6928 [0xe4f0])))
(clobber (reg:CC 17 flags))
]) 191 {*adddi_1}
(nil))
during RTL pass: reload
f:/x265/source/encoder/slicetype.cpp:2086:1: internal compiler error: in
rtl_verify_bb_layout, at cfgrtl.c:2987
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/88343] [7/8/9 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #2 from Iain Sandoe --- (In reply to Iain Sandoe from comment #1) > moving this from 71469 and noting it's a regression. 71496, even: this was the commit. https://gcc.gnu.org/viewcvs?rev=243532=gcc=rev
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Mon Dec 3 20:57:14 2018 New Revision: 266766 URL: https://gcc.gnu.org/viewcvs?rev=266766=gcc=rev Log: PR middle-end/64242 * gcc.c-torture/execute/pr64242.c (foo, bar): New functions. (p): Make it void *volatile instead of volatile void *. (q): New variable. (main): Add a dummy 32-byte aligned variable and escape its address. Don't require that the two __builtin_alloca (0) calls return the same address, just require that their difference is smaller than 1024 bytes. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c
[Bug fortran/88299] [9 Regression] COMMON in a legacy module produces bogus warnings in dependent code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299 --- Comment #1 from Harald Anlauf --- The warning was introduced in: r260705 | janus | 2018-05-25 08:09:10 +0200 (Fri, 25 May 2018) | 16 lines 2018-05-25 Janus Weil PR fortran/85839 * match.c (gfc_match_block_data): Call gfc_notify_std to warn about an obsolescent feature in Fortran 2018. (gfc_match_equivalence): Ditto. * resolve.c (resolve_common_blocks): Ditto. (gfc_resolve_forall): Ditto. * symbol.c (gfc_define_st_label): Ditto. Maybe the warning can be restricted to those files / compilation units where the COMMON is declared? The COMMON unfortunately pollutes all upstream module files (*.mod), even if no symbol is imported (see e.g. mod2 in the testcase).
[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71496 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Iain Sandoe --- fallout issue filed as PR88343.
[Bug target/88343] [7/8/9 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 Iain Sandoe changed: What|Removed |Added Keywords||missed-optimization Target||powerpc-darwin Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- moving this from 71469 and noting it's a regression.
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 --- Comment #3 from mateuszb at poczta dot onet.pl --- W dniu 03.12.2018 o 21:21, pinskia at gcc dot gnu.org pisze: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 > > Andrew Pinski changed: > >What|Removed |Added > > Target||x86_64-w64-mingw32 > Component|c++ |target > > --- Comment #1 from Andrew Pinski --- > Can you attach the preprocessed source as requested by > https://gcc.gnu.org/bugs/ ? Attachment too big. Second try with 7z archive.
[Bug target/88343] New: [7/8/9 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
Bug ID: 88343
Summary: [7/8/9 Regression] R31 is unconditionally
saved/restored on powerpc-darwin even when it's not
necessary.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
This was fallout from the fix for PR 71469.
a trivial
void foo (void) {}
at -O2 produces
$ more t.s
.machine ppc7400
.text
.align 2
.globl _foo
_foo:
stw r31,-4(r1)
lwz r31,-4(r1)
blr
.subsections_via_symbols
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #2 from mateuszb at poczta dot onet.pl ---
W dniu 03.12.2018 o 21:21, pinskia at gcc dot gnu.org pisze:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
> Target||x86_64-w64-mingw32
> Component|c++ |target
>
> --- Comment #1 from Andrew Pinski ---
> Can you attach the preprocessed source as requested by
> https://gcc.gnu.org/bugs/ ?
Big *.ii file attached (bug in pixel.cpp).
Reproduce steps:
$ g++ -c -O3 -march=core-avx2 pixel.ii
f:/x265/source/common/pixel.cpp: In function 'int {anonymous}::_sa8d_8x8(const
pixel*, intptr_t, const pixel*, intptr_t)':
f:/x265/source/common/pixel.cpp:325:1: error: insn outside basic block
325 | }
| ^
(insn 270 239 271 (parallel [
(set (reg:DI 425)
(plus:DI (reg/f:DI 19 frame)
(const_int -304 [0xfed0])))
(clobber (reg:CC 17 flags))
]) -1
(nil))
during RTL pass: reload
f:/x265/source/common/pixel.cpp:325:1: internal compiler error: in
rtl_verify_bb_layout, at cfgrtl.c:2987
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Matt Thompson from comment #0) > All, > > A colleague of mine encountered an issue with 8.2.0 (but it's also in 7.3.0 > at least). We believe it might be a bug since our reading of the Standard > seems to make it legal. > > Namely if this program: > > PROGRAM test >USE, INTRINSIC :: ieee_arithmetic >IMPLICIT NONE >REAL :: inf >inf = IEEE_VALUE(inf, IEEE_POSITIVE_INF) > END PROGRAM test > > is compiled with -ffpe-trap=overflow the code FPEs: gfortran's IEEE modules and the -ffpe-trap option are independent of each other. As the manual states, -ffpe-trap is a *debugging* option, and will enabling traps on floating point exceptions. You specifically requested an overflow trap. What do you expect to happen? The likely correct solution is to manipulate the halting behavior with a combination of IEEE_GET_HALTING_MODE and IEEE_SET_HALTING_MODE. In fact, F2018, 17.11.6 contains this exact example. Example. To store the halting mode for IEEE_OVERFLOW, do a calculation without halting, and restore the halting mode later: USE, INTRINSIC :: IEEE_ARITHMETIC LOGICAL HALTING ... CALL IEEE_GET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Store halting mode CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, .FALSE.) ! No halting ... ! calculation without halting CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Restore halting mode whether or not these functions works is something that I haven't investigated.
[Bug other/80203] libiberty fails to compile regex.c correctly when gcc is configured --with-sysroot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203 --- Comment #1 from Iain Sandoe --- Is this still failing anywhere ?
[Bug libstdc++/88341] [9 Regression] taking norm() of complex variable fails to compile with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88341
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-12-03
Known to work||8.2.0
Assignee|unassigned at gcc dot gnu.org |emsr at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||9.0
--- Comment #2 from Jonathan Wakely ---
Caused by r266416
The fix is simple:
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -659,7 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _Norm_helper
{
template
-static inline _GLIBCXX_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& __z)
+static inline _GLIBCXX20_CONSTEXPR _Tp _S_do_it(const complex<_Tp>&
__z)
{
const _Tp __x = __z.real();
const _Tp __y = __z.imag();
@@ -671,7 +671,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _Norm_helper
{
template
-static inline _GLIBCXX_CONSTEXPR _Tp _S_do_it(const complex<_Tp>& __z)
+static inline _GLIBCXX20_CONSTEXPR _Tp _S_do_it(const complex<_Tp>&
__z)
{
//_Tp __res = std::abs(__z);
//return __res * __res;
[Bug c++/88334] Implement P0482R6, C++20 char8_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88334 --- Comment #1 from Jonathan Wakely --- It needs review.
[Bug c++/88336] Implement P0595R2, C++20 std::is_constant_evaluated (compiler magic library tool).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88336 --- Comment #1 from Jonathan Wakely --- __builtin_constant_evaluated is already implemented, it just needs to be provided with the name std::is_constant_evaluated() (and possibly adjusted for the changes in the R2 paper).
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 Andrew Pinski changed: What|Removed |Added Target||x86_64-w64-mingw32 Component|c++ |target --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source as requested by https://gcc.gnu.org/bugs/ ?
[Bug libstdc++/88341] [9 Regression] taking norm() of complex variable fails to compile with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88341 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ Target Milestone|--- |9.0 Summary|taking norm() of complex|[9 Regression] taking |variable fails to compile |norm() of complex variable |with -std=c++11 |fails to compile with ||-std=c++11
[Bug c++/88341] taking norm() of complex variable fails to compile with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88341 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think this is caused by a change in libstdc++.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #3 from Harald Anlauf --- Created attachment 45147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45147=edit Minimal netcdf-fortran part for the reproducer Compile the netcdf.f90 header before the testcase.
[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #10 from Iain Sandoe --- Created attachment 45146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45146=edit Initial patch (incomplete) rebased experimental patch on trunk at 266733. I think that we need to be clear about what we're trying to achieve. === Here I'm operating on a system * without Xcode installed * without command line tools in the "usual place" (so mimicing a 'vanilla' system). * a non-standard installation of the command line tools places the SDKs in a known place. * GCC bootstrap compiler (so that I can build Ada) which, of course, is capable of building code that will run on my build machine. * the build machine is Darwin16 / 10.16 and I target 10.10 typically for x86_64 tests and cross-compilers for powerpc-darwin9, Linux and MinGW. So, without a sysroot, my bootstraps will fail (there are no headers in /usr/include,; it doesn't exist). Normally, I use --with-sysroot=/path/to/SDK like this (here building on 10.12 for 10.10+): MACOSX_DEPLOYMENT_TARGET=10.10 /src/gcc-trunk/configure --prefix=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched --target=x86_64-apple-darwin14 --host=x86_64-apple-darwin14 --build=x86_64-apple-darwin14 --with-iconv-prefix=/usr --enable-checking=yes,rtl,tree --enable-lto --disable-nls --with-sysroot=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/SDKs/darwin14 --enable-version-specific-runtime-libs --with-as=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/bin/as --with-ld=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/bin/ld --enable-languages=all,d >conf.txt MACOSX_DEPLOYMENT_TARGET=10.10 make ... etc. here, I have my own builds of cctools and ld64 - installed into the prefix. So .. this will produce a self-contained compiler, this :/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/SDKs/darwin14 is a symlink pointing to my command line install. and that compiler will have a default sysroot of /opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/SDKs/darwin14, which can be overidden by passing --sysroot= on the command line (just like clang). == Using --with-build-sysroot with the attached patch works (modulo things I need to sort out with Ada)... MACOSX_DEPLOYMENT_TARGET=10.10 /src/gcc-trunk/configure --prefix=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched --target=x86_64-apple-darwin14 --host=x86_64-apple-darwin14 --build=x86_64-apple-darwin14 --with-iconv-prefix=/usr --enable-checking=yes,rtl,tree --enable-lto --disable-nls --with-build-sysroot=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/SDKs/darwin14 --enable-version-specific-runtime-libs --with-as=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/bin/as --with-ld=/opt/iains/x86_64-apple-darwin16/gcc-trunk-unpatched/bin/ld --enable-languages=c,c++,objc,obj-c++ >conf.txt MACOSX_DEPLOYMENT_TARGET=10.10 make ... etc. Now the difference here is that the resulting compiler has no default sysroot, and therefore won't work *unless* a ) there are headers in the "usual place" (i.e. /usr/include) which I don't think is what you want b ) --sysroot= is specified on the command line (or isysroot IIRC, I think we made that operate the same way as clang). So -- I wonder if this is optimum, since the end user is now stuck with having to add --sysroot= to every command line. If you use --with-sysroot=/path/to/some/default/SDK then I suspect that works tolerably for many cases. = Ideally, we'd be able to make a "foreign" toolchain operate with the DEVELOPER_TOOLDIR= (spelling?) option but I think that's more involved. packaging for Darwin is a challenge since we allow are users to move stuff where they like, and we are trying to avoid privileged installs, so no "well known places". As mentioned elsewhere (a more recent PR) one idea is to have a two-layer approach, where we have a symlink to the SDK in some known place to GCC (e.g. ~/.gcc/version/darwinNN) and then take the runtime hit on updating that only when it becomes stale. I was experimenting with having a set of places to look including (1) /usr/include (2) /A/Configure/Time/SDK/Path (3) xcrun --blah... (I had a trial implementation a couple of years ago, needs dusting off). For those of us who build for Darwin8+ it's essential to have some scheme that allows switching SDKs since modern ones don't have support for the older systems.
[Bug fortran/88342] New: Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 Bug ID: 88342 Summary: Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: matthew.thompson at nasa dot gov Target Milestone: --- All, A colleague of mine encountered an issue with 8.2.0 (but it's also in 7.3.0 at least). We believe it might be a bug since our reading of the Standard seems to make it legal. Namely if this program: PROGRAM test USE, INTRINSIC :: ieee_arithmetic IMPLICIT NONE REAL :: inf inf = IEEE_VALUE(inf, IEEE_POSITIVE_INF) END PROGRAM test is compiled with -ffpe-trap=overflow the code FPEs: (998) $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/ford1/local/gcc/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-8.2.0/configure --prefix=/ford1/local/gcc/gcc-8.2.0 --disable-multilib Thread model: posix gcc version 8.2.0 (GCC) (999) $ gfortran -ffpe-trap=overflow ./test.F90 (1000) $ ./a.out Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x2aab63d5427f in ??? #1 0x2aab63387d60 in __ieee_arithmetic_MOD_ieee_value_4 at ../../../gcc-8.2.0/libgfortran/ieee/ieee_arithmetic.F90:892 #2 0x400770 in ??? #3 0x4007c3 in ??? #4 0x2aab63d403d4 in ??? #5 0x400698 in ??? #6 0x in ??? Floating exception (core dumped)
[Bug c++/88341] New: taking norm() of complex variable fails to compile with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88341
Bug ID: 88341
Summary: taking norm() of complex variable fails to compile
with -std=c++11
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p.vanhoof at oma dot be
Target Milestone: ---
Created attachment 45145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45145=edit
preprocessed file
The attached code fails to compile with the mainline at r266725.
% g++ -std=c++11 -W -Wall -c bug.cc
In file included from bug.cc:1:
/usr/local/gcc900/include/c++/9.0.0/complex: In instantiation of ‘static
constexpr _Tp std::_Norm_helper::_S_do_it(const std::complex<_Tp>&) [with
_Tp = double]’:
/usr/local/gcc900/include/c++/9.0.0/complex:689:35: required from ‘_Tp
std::norm(const std::complex<_Tp>&) [with _Tp = double]’
bug.cc:5:20: required from here
/usr/local/gcc900/include/c++/9.0.0/complex:681:9: error: body of ‘constexpr’
function ‘static constexpr _Tp std::_Norm_helper::_S_do_it(const
std::complex<_Tp>&) [with _Tp = double]’ not a return-statement
681 | }
| ^
% cat bug.cc
#include
double n(std::complex& c)
{
return std::norm(c);
}
The code compiles correctly with all release versions I tried, including 8.2.0,
so this is a regression from g++ 8.
% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc900/lib/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-mainline/configure --prefix=/usr/local/gcc900
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20181202 (experimental) (GCC)
[Bug libstdc++/88340] New: Implement P0019R8, C++20 std::atomic_ref.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88340 Bug ID: 88340 Summary: Implement P0019R8, C++20 std::atomic_ref. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug libstdc++/88339] New: Implement P0515R3, C++20 three-way comparison operator support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88339 Bug ID: 88339 Summary: Implement P0515R3, C++20 three-way comparison operator support . Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug libstdc++/88338] Implement P0898R3, C++20 concepts library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88338 --- Comment #1 from emsr at gcc dot gnu.org --- We may be able/probably should? support both TS and std.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #2 from seurer at gcc dot gnu.org --- powerpc64 for sure BE and possibly LE.
[Bug libstdc++/88338] New: Implement P0898R3, C++20 concepts library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88338 Bug ID: 88338 Summary: Implement P0898R3, C++20 concepts library. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug c++/88337] New: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 Bug ID: 88337 Summary: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug c++/88336] New: Implement P0595R2, C++20 std::is_constant_evaluated (compiler magic library tool).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88336 Bug ID: 88336 Summary: Implement P0595R2, C++20 std::is_constant_evaluated (compiler magic library tool). Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #1 from pkoning at gcc dot gnu.org --- What is your target? I checked this on linux-x86_64 (native build). I don't see the complaint about line 15 in that run.
[Bug c++/88335] New: Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 Bug ID: 88335 Summary: Implement P1073R3, C++20 immediate functions (consteval). Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug c++/88334] New: Implement P0482R6, C++20 char8_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88334 Bug ID: 88334 Summary: Implement P0482R6, C++20 char8_t. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: --- I remember seeing a patch kit go by... https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00292.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00293.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00294.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00295.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00296.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00297.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00298.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00299.html https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00300.html Maybe Copyright issues?
[Bug c/88333] New: ice in asan_emit_stack_protection, at asan.c:1574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88333
Bug ID: 88333
Summary: ice in asan_emit_stack_protection, at asan.c:1574
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code, derived from Linux kernel:
int a;
void b() {
typeof(a) c;
}
compiled with flags -fstack-protector-strong -fsanitize=kernel-address --param
asan-stack=1 in recent gcc trunk, does this:
bug487.c:2:6: internal compiler error: in asan_emit_stack_protection, at
asan.c:1574
The bug seems to first appear sometime between revision 266650 and 266700.
svn blame says
24 marxin gcc_assert (rz_buffer.m_shadow_bytes.is_empty ());
[Bug testsuite/88332] New: [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 Bug ID: 88332 Summary: [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/Wattributes-10.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -Wall -ftrack-macro-expansion=0 -S -o Wattributes-10.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/Wattributes-10.c:11:3: warning: 'packed' attribute ignored for type 'int *' [-Wattributes] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/Wattributes-10.c:13:3: warning: ignoring attribute 'packed' because it conflicts with attribute 'aligned' [-Wattributes] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/Wattributes-10.c:14:3: warning: 'packed' attribute ignored for type 'int *' [-Wattributes] PASS: gcc.dg/Wattributes-10.c (test for warnings, line 11) PASS: gcc.dg/Wattributes-10.c (test for warnings, line 13) PASS: gcc.dg/Wattributes-10.c (test for warnings, line 14) FAIL: gcc.dg/Wattributes-10.c target pdp11*-*-* (test for errors, line 15) PASS: gcc.dg/Wattributes-10.c (test for excess errors) testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes4 # of unexpected failures1
[Bug c++/88331] New: ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
Bug ID: 88331
Summary: ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateuszb at poczta dot onet.pl
Target Milestone: ---
When I compile x265 with option
export CXXFLAGS="-march=core-avx2"
with gcc 9.0 for mingw-w64 target:
g++ -v
Reading specs from
f:/msys/m64-900/bin/../lib/gcc/x86_64-w64-mingw32/9.0.0/specs
COLLECT_GCC=f:\msys\m64-900\bin\g++.exe
COLLECT_LTO_WRAPPER=f:/msys/m64-900/bin/../libexec/gcc/x86_64-w64-mingw32/9.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-9/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --prefix=/home/ma/m/target
--with-sysroot=/home/ma/m/target
Thread model: win32
gcc version 9.0.0 20181203 (experimental) (GCC)
I get errors (it depend of what module x265 compile first):
f:/x265/source/encoder/slicetype.cpp: In member function 'void
x265_12bit::Lookahead::cuTree(x265_12bit::Lowres**, int, bool)':
f:/x265/source/encoder/slicetype.cpp:2086:1: error: insn outside basic block
2086 | }
| ^
(insn 8402 7720 8403 (parallel [
(set (reg:DI 5536)
(plus:DI (reg/f:DI 19 frame)
(const_int -6896 [0xe510])))
(clobber (reg:CC 17 flags))
]) 191 {*adddi_1}
(nil))
during RTL pass: reload
f:/x265/source/encoder/slicetype.cpp:2086:1: internal compiler error: in
rtl_verify_bb_layout, at cfgrtl.c:2987
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
*** OR ***
f:/x265/source/common/pixel.cpp: In function 'int {anonymous}::_sa8d_8x8(const
pixel*, intptr_t, const pixel*, intptr_t)':
f:/x265/source/common/pixel.cpp:325:1: error: insn outside basic block
325 | }
| ^
(insn 270 239 271 (parallel [
(set (reg:DI 425)
(plus:DI (reg/f:DI 19 frame)
(const_int -304 [0xfed0])))
(clobber (reg:CC 17 flags))
]) -1
(nil))
during RTL pass: reload
f:/x265/source/common/pixel.cpp:325:1: internal compiler error: in
rtl_verify_bb_layout, at cfgrtl.c:2987
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc 9.0 snapshot 20181118 works OK, next snapshots works wrong.
If this error is not reproducible/obvious, I could try to make preprocessed
source. Anyway the option "-march=core-avx2" is important for the bug.
[Bug c++/88330] New: Implement P0542R5, P1289R1, C++20 contract based programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330 Bug ID: 88330 Summary: Implement P0542R5, P1289R1, C++20 contract based programming. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug c++/88329] New: Implement C++20 std concepts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88329 Bug ID: 88329 Summary: Implement C++20 std concepts. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug fortran/88328] New: ICE in resolve_tag_format, at fortran/io.c:1641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88328 Bug ID: 88328 Summary: ICE in resolve_tag_format, at fortran/io.c:1641 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least gcc-5 : $ cat z1.f90 program p character(3), parameter :: a(0) = [character(3)::] print a end $ gfortran-9-20181202 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb2ec9f crash_signal ../../gcc/toplev.c:326 0x63ddee resolve_tag_format ../../gcc/fortran/io.c:1641 0x63ddee resolve_tag ../../gcc/fortran/io.c:1747 0x641f37 gfc_resolve_dt(gfc_dt*, locus*) ../../gcc/fortran/io.c:3239 0x6860a7 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11579 0x688b0f resolve_codes ../../gcc/fortran/resolve.c:16704 0x688bde gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16739 0x676967 resolve_all_program_units ../../gcc/fortran/parse.c:6067 0x676967 gfc_parse_file() ../../gcc/fortran/parse.c:6317 0x6bf5ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug c++/88327] New: Implement P0515R3, P0905R1, P1120R0, C++20 std concepts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88327 Bug ID: 88327 Summary: Implement P0515R3, P0905R1, P1120R0, C++20 std concepts. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug fortran/88326] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326
--- Comment #1 from G. Steinmetz ---
This variant compiles and runs :
$ cat z4.f90
program p
character, parameter :: x(3) = ['a','b','c']
character :: y(1) = transfer('x', x)
print *, y
end
$ gfortran-9-20181202 z4.f90 -static-libgfortran
$ a.out
x
$
[Bug fortran/88326] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326
Bug ID: 88326
Summary: ICE in gfc_conv_array_initializer, at
fortran/trans-array.c:6085
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc-5 :
$ cat z1.f90
program p
character, parameter :: x(3) = ['a','b','c']
character :: y(1) = transfer('', x)
print *, y
end
$ cat z2.f90
program p
character, parameter :: x(3) = ['a','b','c']
character(0) :: y(1) = transfer('', x)
print *, y
end
$ cat z3.f90
program p
character, parameter :: x(3) = ['a','b','c']
character :: y(0) = transfer('', x)
print *, y
end
$ gfortran-9-20181202 -c z1.f90
z1.f90:1:0:
1 | program p
|
internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:6085
0x6fbbba gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:6085
0x737200 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7033
0x71ace2 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1824
0x71e517 generate_local_decl
../../gcc/fortran/trans-decl.c:5600
0x6d37e2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x71fa6c generate_local_vars
../../gcc/fortran/trans-decl.c:5800
0x71fa6c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6444
0x69d446 translate_all_program_units
../../gcc/fortran/parse.c:6128
0x69d446 gfc_parse_file()
../../gcc/fortran/parse.c:6331
0x6e6a9f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
[Bug c++/88325] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: in make_typename_type, at cp/decl.c:3816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88325 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Indeed, started with r266710.
[Bug c++/88325] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: in make_typename_type, at cp/decl.c:3816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88325 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Summary|ICE on (invalid) C++ code |[9 Regression] ICE on |when compiled with |(invalid) C++ code when |-std=c++2a: in |compiled with -std=c++2a: |make_typename_type, at |in make_typename_type, at |cp/decl.c:3816 |cp/decl.c:3816 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This has got to be mine...
[Bug bootstrap/88321] Crosscompiled gcc does not use preinstalled as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88321 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=61651 --- Comment #2 from Eric Gallager --- Possibly related to or a duplicate of bug 61651?
[Bug c++/88325] New: ICE on (invalid) C++ code when compiled with -std=c++2a: in make_typename_type, at cp/decl.c:3816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88325
Bug ID: 88325
Summary: ICE on (invalid) C++ code when compiled with
-std=c++2a: in make_typename_type, at cp/decl.c:3816
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This appears to be a recent regression.
$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20181203 (experimental) [trunk revision 266735] (GCC)
$
$ g++tk -std=c++2a -c tmp.cpp
tmp.cpp:6:34: internal compiler error: in make_typename_type, at cp/decl.c:3816
6 | template < typename T > A < T >::A < T > () {}
| ^~~
0x7573fd make_typename_type(tree_node*, tree_node*, tag_types, int)
../../gcc-source-trunk/gcc/cp/decl.c:3816
0x80a9ac cp_parser_class_name
../../gcc-source-trunk/gcc/cp/parser.c:22970
0x80ae81 cp_parser_type_name
../../gcc-source-trunk/gcc/cp/parser.c:17837
0x7f4334 cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:17697
0x8037b5 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:17336
0x80dbc7 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:13986
0x81a7e8 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27828
0x81abbc cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:27507
0x81b6cd cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27754
0x81b6cd cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:27772
0x823179 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13055
0x821e5e cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4688
0x821e5e c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:40806
0x979bfa c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1151
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
--
template < typename > struct A
{
template < typename > A ();
};
template < typename T > A < T >::A < T > () {}
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Marek Polacek changed: What|Removed |Added Keywords||meta-bug Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/88297] [9 Regression] Assembler Error: symbol `_Z41__static_initialization_and_destruction_0ii.constprop.0' is already defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 --- Comment #6 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 > > --- Comment #5 from michael.ploujnikov at oracle dot com --- > (In reply to Richard Biener from comment #3) > > So before the patch we were just lucky, right? When seeing the patches I > > wondered whether we instead want to add a clone_count member to cgraph_node > > (which we could stream) and use that for the .NUM suffix. We alread have > > it (sort-of) if we walk the clones list and do counting, right? > > But the root of the problem is that multiple different cgraph_nodes share the > same name, so even if two or more nodes like that have counters == 0 we would > get the same conflict. Unless it's always the case that the additional They are linked together as "transparent aliases". So one node has no transparent_alias set and other sets it and node->alias_target will get you to the "master" node. Honza
[Bug c++/88320] GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320 --- Comment #4 from Jonny Grant --- (In reply to Jonathan Wakely from comment #3) > (In reply to Jonny Grant from comment #0) > > Suggestion on line 5 of a variable which is acutally the return value, and > > doesn't exist yet. Better to only suggest alternative as variables that > > exist already in scope? > > The variable's scope begins after its name, so it is already in scope. yes, actually you're right. Maybe it doesn't matter, as it's only a suggestion, but changing it to the suggestion gives another warning, but would not in other cases (eg a std::string) var_suggest.cpp:6:9: warning: ‘aresult’ is used uninitialized in this function [-Wuninitialized] int aresult = aresult +1; Shall we close this ticket?
[Bug lto/88297] [9 Regression] Assembler Error: symbol `_Z41__static_initialization_and_destruction_0ii.constprop.0' is already defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 --- Comment #5 from michael.ploujnikov at oracle dot com --- (In reply to Richard Biener from comment #3) > So before the patch we were just lucky, right? When seeing the patches I > wondered whether we instead want to add a clone_count member to cgraph_node > (which we could stream) and use that for the .NUM suffix. We alread have > it (sort-of) if we walk the clones list and do counting, right? But the root of the problem is that multiple different cgraph_nodes share the same name, so even if two or more nodes like that have counters == 0 we would get the same conflict. Unless it's always the case that the additional cgraph_nodes with the same decl name are made as copies of the original one and their counter values are copied as well - I'm not sure if things actually work like that, I'm just guessing...
[Bug c++/88102] Implement P0542R5, C++20 contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Marek Polacek changed: What|Removed |Added Keywords||meta-bug Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #14 from Wilco ---
(In reply to Jakub Jelinek from comment #13)
> I wonder about following, on i686-linux it FAILs with older trunk and
> succeeds with current trunk. Without the (useless) stack realignment the
> right value of stack pointer happened to be in exactly that slot from which
> it read memory.
We could just increase the alloca size to 1 to avoid that (however there is
always a possibility that the loaded value happens to be valid).
> While still not fully portable, I think if the two alloca (0) are more than
> 1024 bytes appart, something is wrong with the target or at least alloca is
> helplessly expensive there.
If alloca (x) always allocates extra bytes for no reason then that's a separate
issue with alloca - I fixed this in the generic code last year.
> --- gcc/testsuite/gcc.c-torture/execute/pr64242.c 2018-12-01
> 00:25:08.082009500 +0100
> +++ gcc/testsuite/gcc.c-torture/execute/pr64242.c 2018-12-03
> 16:43:33.343875994 +0100
> @@ -11,20 +11,40 @@ broken_longjmp(void *p)
>__builtin_longjmp (buf, 1);
> }
>
> +__attribute ((noipa)) __UINTPTR_TYPE__
> +foo(void *p)
> +{
> + return (__UINTPTR_TYPE__) p;
> +}
> +
> +__attribute ((noipa)) void
> +bar(void *p)
> +{
> + asm volatile ("" : : "r" (p));
> +}
> +
> volatile int x = 0;
> -volatile void *p;
> +void *volatile p;
> +void *volatile q;
> int
> main (void)
> {
>void *buf[5];
> + struct __attribute__((aligned (32))) S { int a[4]; } s;
> + bar ();
Not sure what the purpose of this would be?
>p = __builtin_alloca (x);
> -
>if (!__builtin_setjmp (buf))
> broken_longjmp (buf);
>
>/* Fails if stack pointer corrupted. */
> - if (p != __builtin_alloca (x))
> -abort();
> + q = __builtin_alloca (x);
> + if (foo (p) < foo (q))
> +{
> + if (foo (q) - foo (p) >= 1024)
> + abort ();
> +}
> + else if (foo (p) - foo (q) >= 1024)
> +abort ();
I think that could just become __builtin_absl (foo (q) - foo (p)) > 64.
>return 0;
> }
[Bug c++/88324] New: segfault with constexpr lambda in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88324
Bug ID: 88324
Summary: segfault with constexpr lambda in template arguments
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
With -std=c++17 GCC segfaults on
template
int f()
{
return 0;
}
template int f();
Clang accepts with -fsyntax-only, segfaults trying to mangle. MSVC accepts. GCC
produces
: In lambda function:
:1:35: error: invalid use of 'auto'
1 | template
| ^~
:1:35: error: could not convert '42' from 'int' to 'auto'
: At global scope:
:1:14: error: use of '' before deduction of 'auto'
1 | template
| ^
: In static member function 'static auto::_FUN()':
:1:14: error: invalid use of 'auto'
: At global scope:
:1:40: internal compiler error: Segmentation fault
[Bug c++/88320] GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320 --- Comment #3 from Jonathan Wakely --- (In reply to Jonny Grant from comment #0) > Suggestion on line 5 of a variable which is acutally the return value, and > doesn't exist yet. Better to only suggest alternative as variables that > exist already in scope? The variable's scope begins after its name, so it is already in scope.
[Bug c++/88320] GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #1)
> Created attachment 45144 [details]
> test case
Reproduced here, as it's tiny and more convenient in a comment than as an
attachment:
// g++ -Wall -O2 -o suggest var_suggest.cpp
int main()
{
int vresults1 = 0;
int aresult = aresults +1;
return aresult;
}
[Bug bootstrap/88321] Crosscompiled gcc does not use preinstalled as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88321 --- Comment #1 from Daniel Fruzynski --- Update: there is workaround for this, pass "--with-ld=/bin/x86_64-w64-mingw32-ld --with-as=/bin/x86_64-w64-mingw32-as" to configure script. I also tried to use "--with-ld=x86_64-w64-mingw32-ld --with-as=x86_64-w64-mingw32-as". With these options initial configure completed successfully, but build failed that command cannot be found - probably PATH environment variable was cleared during build, and full path to specified as/ld was not saved.
[Bug c++/88323] New: implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Bug ID: 88323 Summary: implement C++20 language features. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug libstdc++/88322] New: Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug ID: 88322 Summary: Implement C++20 library features. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: emsr at gcc dot gnu.org Target Milestone: ---
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #15 from Alexander Monakov ---
Typo: PR 42491 should have said PR 43491.
Hopefully more obviously-broken testcase with an inline function:
static inline void
ff(int *o)
{
register int a asm("eax");
a = 1;
asm("add %1, %0" : "+g"(*o) : "r"(a));
}
int f(void)
{
int o=0, i;
for (i=0; i<3; i++) {
ff();
asm("xor %%eax, %%eax" ::: "eax");
}
return o;
}
[Bug fortran/87919] Incorrect fortran handling of -fno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Dec 3 17:10:50 2018 New Revision: 266761 URL: https://gcc.gnu.org/viewcvs?rev=266761=gcc=rev Log: PR fortran/87919 * options.c (SET_FLAG, SET_BITFLAG, SET_BITFLAG2): New macros. (set_dec_flags): Set/unset DEC and std flags according to value. (post_dec_flags, set_init_local_zero): New functions. (gfc_init_options): Use set_init_local_zero and post_dec_flags. (gfc_handle_options) : Use SET_BITFLAG. : Use set_init_local_zero. : Pass value to set_dec_flags. : Remove. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #14 from Alexander Monakov --- With -fno-tree-fre it's still broken. How long will GCC play this sort of whack-a-mole with ad-hoc restrictions to gimple optimizations (PR 29877, PR 42491, PR 61572)? And this: > for fixed registers there is no need to specify them in clobbers, but users > might still use those fixed registers in asm) as possibly modifying content > of local or global register vars. is not true, we do require inline asm to properly inform the compiler about accessing global register variables by mentioning them in constraints.
[Bug bootstrap/88321] New: Crosscompiled gcc does not use precompiled as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88321 Bug ID: 88321 Summary: Crosscompiled gcc does not use precompiled as Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- I have build gcc 8.2.0 as as crosscompiler for Centos 7 x86_64 -> MinGW x86_64. Before starting I installed gcc 4.9.3 MinGW crosscompiler from EPEL repository. My new crosscompiler was configured in following way: [root@localhost build]# ../gcc-8.2.0/configure --prefix=/gcc-8.2-mingw/ --enable-languages=c,c++ --disable-multilib --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-w64-mingw32 --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-threads=posix --enable-libgomp --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++ checking build system type... x86_64-redhat-linux-gnu checking host system type... x86_64-redhat-linux-gnu checking target system type... x86_64-w64-mingw32 checking for a BSD-compatible install... /bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libitm support... no checking for libsanitizer support... no checking for libvtv support... yes checking for libmpx support... no checking for libhsail-rt support... no checking for x86_64-redhat-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for x86_64-redhat-linux-gnu-g++... no checking for x86_64-redhat-linux-gnu-c++... no checking for x86_64-redhat-linux-gnu-gpp... no checking for x86_64-redhat-linux-gnu-aCC... no checking for x86_64-redhat-linux-gnu-CC... no checking for x86_64-redhat-linux-gnu-cxx... no checking for x86_64-redhat-linux-gnu-cc++... no checking for x86_64-redhat-linux-gnu-cl.exe... no checking for x86_64-redhat-linux-gnu-FCC... no checking for x86_64-redhat-linux-gnu-KCC... no checking for x86_64-redhat-linux-gnu-RCC... no checking for x86_64-redhat-linux-gnu-xlC_r... no checking for x86_64-redhat-linux-gnu-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... no checking for x86_64-redhat-linux-gnu-gnatbind... no checking for gnatbind... no checking for x86_64-redhat-linux-gnu-gnatmake... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check *** This configuration is not supported in the following subdirectories: zlib target-libitm target-libsanitizer target-libmpx target-libffi target-libgo gnattools gotools target-libada target-libhsail-rt target-libgfortran target-libbacktrace target-libobjc target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... no checking for runtest... no checking for x86_64-redhat-linux-gnu-ar... no checking for ar... ar checking for x86_64-redhat-linux-gnu-as... no checking for as... as checking for x86_64-redhat-linux-gnu-dlltool... no checking for dlltool... no checking for x86_64-redhat-linux-gnu-ld... no checking for ld... ld checking for x86_64-redhat-linux-gnu-lipo... no checking for lipo... no checking for x86_64-redhat-linux-gnu-nm... no checking for nm... nm checking for x86_64-redhat-linux-gnu-ranlib... no checking for ranlib... ranlib checking for x86_64-redhat-linux-gnu-strip... no checking for strip... strip checking for x86_64-redhat-linux-gnu-windres... no checking for windres... no checking for x86_64-redhat-linux-gnu-windmc... no checking for windmc... no checking for
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 Ever confirmed|0 |1 --- Comment #2 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #1) > This was previously only run for GNU/Linux, Solaris and AIX, but is now > enabled for all pthreads targets. I don't think this particular test will > ever pass for targets where is_pointer is true. So - just skip this on Darwin, or invent some new target supports test for pthread-non-pointer? (not entirely sure that would be unequivocally trivial)
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek ---
For #c9, looks like FRE bug to me, which is optimizing correct:
a = 1;
__asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_13 = 1;
a = 1;
__asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_19 = 2;
a = 1;
__asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_25 = 3;
return o_24;
into:
a = 1;
__asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
__asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
__asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
return o_24;
We should treat function calls and inline asm (just with clobbers or all?
Argument for all is that e.g. for fixed registers there is no need to specify
them in clobbers, but users might still use those fixed registers in asm) as
possibly modifying content of local or global register vars.
[Bug c++/88320] GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320 --- Comment #1 from Jonny Grant --- Created attachment 45144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45144=edit test case
[Bug c++/88320] New: GCC suggests variables that don't exist yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88320 Bug ID: 88320 Summary: GCC suggests variables that don't exist yet Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Suggestion on line 5 of a variable which is acutally the return value, and doesn't exist yet. Better to only suggest alternative as variables that exist already in scope? $ g++-8 -Wall -O2 -o suggest var_suggest.cpp var_suggest.cpp: In function ‘int main()’: var_suggest.cpp:5:19: error: ‘aresults’ was not declared in this scope int aresult = aresults +1; ^~~~ var_suggest.cpp:5:19: note: suggested alternative: ‘aresult’ int aresult = aresults +1; ^~~~ aresult var_suggest.cpp:4:9: warning: unused variable ‘vresults1’ [-Wunused-variable] int vresults1 = 0;
[Bug libitm/88319] New: all-target and all-target-libitm build targets fail for libitm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88319 Bug ID: 88319 Summary: all-target and all-target-libitm build targets fail for libitm. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- the build fails with something along the following lines (the exact output depends on whether the build is parallel or not): make[3]: Entering directory `/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libitm' /bin/sh ./libtool --tag=CXX --mode=compile -B/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/iains/gcc-trunk/install/x86_64-pc-linux-gnu/bin/ -B/home/iains/gcc-trunk/install/x86_64-pc-linux-gnu/lib/ -isystem /home/iains/gcc-trunk/install/x86_64-pc-linux-gnu/include -isystem /home/iains/gcc-trunk/install/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libitm -I../../../src/libitm/config/linux/x86 -I../../../src/libitm/config/linux -I../../../src/libitm/config/x86 -I../../../src/libitm/config/posix -I../../../src/libitm/config/generic -I../../../src/libitm -mrtm -Wall -Werror -Wc,-pthread -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -D_GNU_SOURCE -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c -o aatree.lo ../../../src/libitm/aatree.cc libtool: compile: unrecognized option `-B/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs' libtool: compile: Try `libtool --help' for more information. make[3]: *** [aatree.lo] Error 1 make[3]: Leaving directory `/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libitm' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libitm' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/iains/gcc-trunk/bld/x86_64-pc-linux-gnu/libitm' make: *** [all-target-libitm] Error 2 ry `libtool --help' for more information. *** [barrier.lo] Error 1
[Bug other/88318] New: new test case gcc.dg/independent-cloneids-1.c fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88318 Bug ID: 88318 Summary: new test case gcc.dg/independent-cloneids-1.c fails on big endian Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This works fine on powerpc64le but fails on be. spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/independent-cloneids-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O3 -fipa-cp -fipa-cp-clone -ffat-lto-objects -fno-ident -S -o independent-cloneids-1.s PASS: gcc.dg/independent-cloneids-1.c (test for excess errors) gcc.dg/independent-cloneids-1.c: (?n)\\m_*bar[.$_]constprop[.$_]0: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*bar[.$_]constprop[.$_]0: 1 gcc.dg/independent-cloneids-1.c: (?n)\\m_*bar[.$_]constprop[.$_]1: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*bar[.$_]constprop[.$_]1: 1 gcc.dg/independent-cloneids-1.c: (?n)\\m_*bar[.$_]constprop[.$_]2: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*bar[.$_]constprop[.$_]2: 1 gcc.dg/independent-cloneids-1.c: (?n)\\m_*foo[.$_]constprop[.$_]0: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*foo[.$_]constprop[.$_]0: 1 gcc.dg/independent-cloneids-1.c: (?n)\\m_*foo[.$_]constprop[.$_]1: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*foo[.$_]constprop[.$_]1: 1 gcc.dg/independent-cloneids-1.c: (?n)\\m_*foo[.$_]constprop[.$_]2: found 2 times FAIL: gcc.dg/independent-cloneids-1.c scan-assembler-times (?n)\\m_*foo[.$_]constprop[.$_]2: 1 PASS: gcc.dg/independent-cloneids-1.c scan-assembler-not (?n)\\m_*foo[.$_]constprop[.$_]3: PASS: gcc.dg/independent-cloneids-1.c scan-assembler-not (?n)\\m_*foo[.$_]constprop[.$_]4: testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes3 # of unexpected failures6
[Bug c++/88313] generic lambda in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/88317] New: ICE: Segmentation fault (in split_reg -> bitmap_set_bit -> bitmap_list_link_element)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88317 Bug ID: 88317 Summary: ICE: Segmentation fault (in split_reg -> bitmap_set_bit -> bitmap_list_link_element) Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-invalid-code, ra Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu Created attachment 45143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45143=edit The testcase gcc-9.0.0-alpha20181202 snapshot (r266729) ICEs when compiling the attached testcase w/ -O1 -fschedule-insns -fselective-scheduling -ftrapv -funroll-all-loops -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-tree-sra: % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -O1 -fschedule-insns -fselective-scheduling -ftrapv -funroll-all-loops -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-tree-sra -w -c ovoyxfol.c -v Using built-in specs. COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 Target: x86_64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/9.0.0-alpha20181202 --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/include --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/9.0.0-alpha20181202 --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/man --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/include/g++-v9 --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=yes --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 9.0.0-alpha20181202 20181202 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O1' '-fschedule-insns' '-fselective-scheduling' '-ftrapv' '-funroll-all-loops' '-fno-tree-ccp' '-fno-tree-dce' '-fno-tree-dominator-opts' '-fno-tree-fre' '-fno-tree-sra' '-w' '-c' '-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/cc1 -quiet -v ovoyxfol.c -quiet -dumpbase ovoyxfol.c -mtune=generic -march=x86-64 -auxbase ovoyxfol -O1 -w -version -fschedule-insns -fselective-scheduling -ftrapv -funroll-all-loops -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-tree-sra -o /tmp/ccZdGkhr.s GNU C17 (GCC) version 9.0.0-alpha20181202 20181202 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 9.0.0-alpha20181202 20181202 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/include /usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181202/include-fixed /usr/include End of search list. GNU C17 (GCC) version 9.0.0-alpha20181202 20181202 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 9.0.0-alpha20181202 20181202 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: a92a885da50bf198a0c1fc913bab14ec during RTL pass: reload ovoyxfol.c: In function 'vb': ovoyxfol.c:661:1: internal compiler error: Segmentation fault 661 | } | ^ 0xd0821f crash_signal /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/toplev.c:326 0x88ea20 bitmap_list_link_element /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/bitmap.c:212 0x88ea20 bitmap_set_bit(bitmap_head*, int)
[Bug libgomp/88303] libgomp does not repect RUNTESTFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88303 --- Comment #4 from Steve Kargl --- On Mon, Dec 03, 2018 at 08:37:32AM +, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88303 > > --- Comment #1 from Jakub Jelinek --- > Libgomp certainly does respect RUNTESTFLAGS, I use > make check-target-libgomp RUNTESTFLAGS=c.exp=atomic-2.c > and similar very often. > > Isn't the problem that toplevel check-fortran depends on > check-target-libgomp-fortran which does: > check-target-libgomp-fortran: > $(MAKE) RUNTESTFLAGS="$(RUNTESTFLAGS) fortran.exp" > check-target-libgomp > and thus checks all fortran? > I don't know what the problem is other than it appears to have arrived with r261717 | ebotcazou | 2018-06-18 15:01:58 -0700 (Mon, 18 Jun 2018) | 4 lines * Makefile.def (fortran): Add check-target-libgomp-fortran. * Makefile.tpl (check-target-libgomp-fortran): New phony target. * Makefile.in: Regenerate. So, prior to this commit, exactly 5 tests were compiled, which takes on the order of 3 seconds on this old hardware (see below). Now, with libgomp not respecting RUNTESTFLAGS (or not receiving RUNTESTFLAGS from make in obj/), building all libgomp takes 15 minutes. % time gmake check-fortran RUNTESTFLAGS="dg.exp=pr88249.f90" 886.46 real 746.40 user 132.63 sys > I have no idea what to change it to support what you want though, I'd suggest > just do > make -C gcc check-gfortran RUNTESTFLAGS="dg.exp=pr88269.f90" if you want to > check something in the GCC testsuite, not use the toplevel check-fortran. I have no idea how to fix the problem, but your suggested workaround seems to work. % time gmake -C gcc check-fortran RUNTESTFLAGS="dg.exp=pr88249.f90" ... === gfortran Summary === # of expected passes5 /usr/home/kargl/gcc/obj/gcc/gfortran version 9.0.0 20181202 \ (experimental) (GCC) gmake[1]: Leaving directory '/usr/home/kargl/gcc/obj/gcc' gmake: Leaving directory '/usr/home/kargl/gcc/obj/gcc' 2.56 real 1.72 user 0.76 sys
