[Bug bootstrap/28472] -B$(build_tooldir)/bin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-04 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Eric Gallager --- Is this still an issue with newer versions of gcc? Putting in WAITING as per https://gcc.gnu.org/bugs/management.html
[Bug bootstrap/5301] Cross-compiler docs problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5301 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to dank from comment #4) > http://kegel.com/crosstool has come a ways since I last posted. > It's now quite easy to build and test crosscompilers. > My script still doesn't run the glibc regression test, but at > least it runs the gcc/g++/stdlibc++ tests. Anyone who's having > trouble building or testing crosscompilers should have a look > at that page. In fact, it'd be nice if http://gcc.gnu.org/install/ > or a related page linked to http://kegel.com/crosstool. Link says that documentation is out of date and to see http://crosstool-ng.github.io/ instead.
[Bug bootstrap/12596] configure setting --with-libiconv-prefix doesn't get passed to gcc-subdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12596 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=78251 --- Comment #8 from Eric Gallager --- I think there's another bug open that's a duplicate of this one, but I can't remember which one right now... possibly bug 78251? Related at least.
[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77456 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=22141, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77482, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77485 --- Comment #9 from Eric Gallager --- (In reply to petschy from comment #2) > #22141 does not mention a DSE issue, nor a segfault of the compiler, so > hardly an exact duplicate. Even if it's not a duplicate, it's still related enough to go under "See Also"
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Eric Gallager changed: What|Removed |Added CC||dominiq at lps dot ens.fr, ||egallager at gcc dot gnu.org, ||gerhard.steinmetz.fortran@t ||-online.de See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=48279 Severity|normal |minor
[Bug c++/60335] confused by earlier errors, bailing out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60335
Eric Gallager changed:
What|Removed |Added
Keywords||needs-bisection
Status|ASSIGNED|WAITING
CC||egallager at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
Severity|normal |minor
--- Comment #3 from Eric Gallager ---
I no longer get an ICE on this code with GCC 7. Was this fixed at some point?
The output I get is:
$ gcc -c 60335.c
60335.c:3:30: warning: 'struct bar0' declared inside parameter list will not be
visible outside of this definition or declaration
int baz1(void bar0, struct bar0 {} bar3);
^~~~
60335.c:3:17: warning: parameter 1 ('bar0') has void type
int baz1(void bar0, struct bar0 {} bar3);
^~~~
60335.c:3:7: error: field 'baz1' declared as a function
int baz1(void bar0, struct bar0 {} bar3);
^~~~
$
[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to Eric Botcazou from comment #8) > > It's probably too late to implement this in reload though. > > So an incentive for the switch to LRA if one was needed. Doesn't sparc default to LRA now?
[Bug middle-end/85620] Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Jul 4 03:01:33 2018 New Revision: 262370 URL: https://gcc.gnu.org/viewcvs?rev=262370=gcc=rev Log: i386: Add indirect_return function attribute On x86, swapcontext may return via indirect branch when shadow stack is enabled. To support code instrumentation of control-flow transfers with -fcf-protection, add indirect_return function attribute to inform compiler that a function may return via indirect branch. Note: Unlike setjmp, swapcontext only returns once. Mark it return twice will unnecessarily disable compiler optimization as shown in the testcase here. gcc/ PR target/85620 * config/i386/i386.c (rest_of_insert_endbranch): Also generate ENDBRANCH for non-tail call which may return via indirect branch. * doc/extend.texi: Document indirect_return attribute. gcc/testsuite/ PR target/85620 * gcc.target/i386/pr85620-1.c: New test. * gcc.target/i386/pr85620-2.c: Likewise. * gcc.target/i386/pr85620-3.c: Likewise. * gcc.target/i386/pr85620-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr85620-1.c trunk/gcc/testsuite/gcc.target/i386/pr85620-2.c trunk/gcc/testsuite/gcc.target/i386/pr85620-3.c trunk/gcc/testsuite/gcc.target/i386/pr85620-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86274] [7/8 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274 Martin Sebor changed: What|Removed |Added Summary|[7/8/9 Regression] SEGFAULT |[7/8 Regression] SEGFAULT |when logging|when logging |std::to_string(NAN) |std::to_string(NAN) Known to fail|9.0 | --- Comment #16 from Martin Sebor --- Fixed on trunk via r262368.
[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274 --- Comment #15 from Martin Sebor --- Author: msebor Date: Wed Jul 4 02:19:35 2018 New Revision: 262368 URL: https://gcc.gnu.org/viewcvs?rev=262368=gcc=rev Log: PR tree-optimization/86274 - SEGFAULT when logging std::to_string(NAN) gcc/ChangeLog: PR tree-optimization/86274 * gimple-ssa-sprintf.c (fmtresult::type_max_digits): Verify precondition. (format_floating): Correct handling of infinities and NaNs. gcc/testsuite/ChangeLog: PR tree-optimization/86274 * gcc.dg/tree-ssa/builtin-sprintf-9.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust. * gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Same. * gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Same. * gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same. * gcc.dg/tree-ssa/builtin-sprintf.c: Same. * gcc.dg/tree-ssa/pr83198.c: Same. Added: trunk/gcc/testsuite/gcc.dg/torture/builtin-sprintf.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-15.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83198.c
[Bug c++/86398] New: is_trivially_constructible always returns true even when is_constructible returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86398
Bug ID: 86398
Summary: is_trivially_constructible always returns true even
when is_constructible returns false
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
This actually looks like a duplicate of PR80682, but that one was closed as
"fixed" a while back, and the bug is still present.
// https://godbolt.org/g/SfcQiC
#include
int x[] = {
std::is_trivially_constructible_v,
std::is_constructible_v,
};
int main() {
printf("%d %d\n", x[0], x[1]);
}
On Clang this prints "0 0" because `int` is not constructible from `void*`.
On GCC this prints "1 0": `int` is trivially constructible, yet not
constructible, from `void*`.
[Bug c++/86397] New: g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397
Bug ID: 86397
Summary: g++ ICE at on valid code in nothrow_spec_p, at
cp/except.c:1158
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
g++-6.1 compiles. g++-8.1 and the trunk version crash.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180703 (experimental) [trunk revision 262340] (GCC)
$ g++-trunk abc.c
abc.c: In instantiation of ‘void f(int (*)() noexcept (e)) [with bool
= false]’:
abc.c:3:29: required from here
abc.c:2:22: internal compiler error: in nothrow_spec_p, at cp/except.c:1158
template void f(int() noexcept(e)) {}
^
0x615664 nothrow_spec_p(tree_node const*)
../../gcc/gcc/vec.h:972
0x9b91b7 canonical_eh_spec(tree_node*)
../../gcc/gcc/cp/tree.c:2598
0x8ddfdd canonicalize_for_substitution
../../gcc/gcc/cp/mangle.c:422
0x8ddfdd write_type
../../gcc/gcc/cp/mangle.c:2107
0x8dd9cc write_type
../../gcc/gcc/cp/mangle.c:2306
0x8df6f4 write_method_parms
../../gcc/gcc/cp/mangle.c:2799
0x8e564a write_bare_function_type
../../gcc/gcc/cp/mangle.c:2735
0x8e6534 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3795
0x8e6a50 get_mangled_id
../../gcc/gcc/cp/mangle.c:3817
0x8e6a50 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3855
0x11172cd decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:691
0x115bd9f notice_global_symbol(tree_node*)
../../gcc/gcc/varasm.c:1675
0xadc8fa cgraph_node::finalize_function(tree_node*, bool)
../../gcc/gcc/cgraphunit.c:451
0x9a1c5f expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:4272
0x961483 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:24084
0x9873d3 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:24179
0x8b0448 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4707
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.
$ cat abc.c
void e();
template void f(int() noexcept(e)) {}
template void f(int());
[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #14 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00165.html
[Bug middle-end/86380] incorrect comparison in function chose_multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86380 --- Comment #4 from Colin Bartlett --- >(In reply to Eric Botcazou from comment #3) > > I suspected that when compiled programs didn't show the error, but: > > > > 1. Is that documented anywhere? It might be useful if that was documented > > also in choose_multiplier? > > > > 2. Is that anyway any reason not to use the correct comparison, unless there > > is a good reason to use the wrong comparison? > > No and no. In that case I suggest that: (a) There's no need for any urgency at all for this as it won't affect anything. (b) But at an appropriate time in the future one of the following is done: (b1) The comparison is changed to the correct comparison, maybe with a comment that in previous versions ">=" was used which went wrong in the circumstances set out above but choose_multiplier was never called with those arguments. (b2) The comparison is left unchanged, but a comment is added that strictly speaking we should use ">" but as choose_multiplier should never be called with arguments for which ">" has a different effect to ">=" we can just use ">=". My (strong) preference is for (b1).
[Bug tree-optimization/86396] New: fold calls to strtod() into constants where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86396
Bug ID: 86396
Summary: fold calls to strtod() into constants where possible
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The canonical C interface to obtain the values of infinity and NaN are the
strtod(), strtof(), and strtold() family of functions. The C standard defines
other functions such as atof(), nan() or fscanf() (and macros such as INFINITY
and NAN) but they are all specified in terms of strtod() et alia. GCC provides
__builtin_nan(const char*) and __builtin_inf(), but as the test case below
shows it doesn't make use of these built-ins to fold calls to strtod(). It
would be a worthwhile improvement to add this feature, not just for infinity
and NaN, but for all other constant arguments. For example, there is no reason
why the call atof("3.14") or any other call with a constant string that is
representable in the return type couldn't be folded into the corresponding
constant.
$ cat c.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout c.c
extern double atof (const char*);
extern double strtod (const char*, char **);
extern double nan (const char*);
double f0 (void)
{
return atof ("nan"); // not folded but could be
}
double f1 (void)
{
return nan ("0"); // folded into NaN
}
double f2 (void)
{
return strtod ("inf", 0); // not folded but could be
}
double f3 (void)
{
return strtod ("nan", 0); // not folded but could be
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1905, cgraph_uid=1, symbol_order=0)
f0 ()
{
double _3;
[local count: 1073741825]:
_3 = atof ("nan"); [tail call]
return _3;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1908, cgraph_uid=2, symbol_order=1)
f1 ()
{
[local count: 1073741825]:
return Nan;
}
;; Function f2 (f2, funcdef_no=2, decl_uid=1911, cgraph_uid=3, symbol_order=2)
f2 ()
{
double _3;
[local count: 1073741825]:
_3 = strtod ("inf", 0B); [tail call]
return _3;
}
;; Function f3 (f3, funcdef_no=3, decl_uid=1914, cgraph_uid=4, symbol_order=3)
f3 ()
{
double _3;
[local count: 1073741825]:
_3 = strtod ("nan", 0B); [tail call]
return _3;
}
[Bug tree-optimization/86396] fold calls to strtod() into constants where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86396 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug middle-end/86380] incorrect comparison in function chose_multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86380 --- Comment #3 from Eric Botcazou --- > I suspected that when compiled programs didn't show the error, but: > > 1. Is that documented anywhere? It might be useful if that was documented > also in choose_multiplier? > > 2. Is that anyway any reason not to use the correct comparison, unless there > is a good reason to use the wrong comparison? No and no.
[Bug ipa/86395] add support of -fopt-info-inline in early inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug target/86387] [RISCV][ABI] GCC fails to sign/zero-ext integers as necessary for passing/returning int+fp structs on hard-float ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-03 Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jim Wilson --- I don't see any gcc regression. I think the psABI spec was updated without checking gcc. Unfortunately, fixing gcc would cause a non-backward compatible ABI change. Given that we fixed the ABI back in January when we upstreamed glibc, we can't change it now without causing a lot of trouble. Hence, the easy solution is to fix the paABI spec to match what gcc actually emits.
[Bug ipa/86395] New: add support of -fopt-info-inline in early inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395
Bug ID: 86395
Summary: add support of -fopt-info-inline in early inliner
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
currently, -fopt-info-inline does not report any info from early inliner.
for example:
[qinzhao@localhost inline_report]$ cat inline_1.c
static int foo (int a)
{
return a + 10;
}
static int bar (int b)
{
return b - 20;
}
static int boo (int a, int b)
{
return foo (a) + bar (b);
}
extern int v_a, v_b;
extern int result;
int compute ()
{
result = boo (v_a, v_b);
return result;
}
[qinzhao@localhost inline_report]$ /home/qinzhao/Install/latest/bin/gcc -O3
-fopt-info-inline-optimized-missed=inline.txt inline_1.c -S
[qinzhao@localhost inline_report]$ ls -l inline.txt
-rw-rw-r--. 1 qinzhao qinzhao 0 Jul 3 11:25 inline.txt
[qinzhao@localhost inline_report]$ cat inline_1.s
.file "inline_1.c"
.text
.p2align 4,,15
.globl compute
.type compute, @function
compute:
.LFB3:
.cfi_startproc
movlv_a(%rip), %edx
movlv_b(%rip), %eax
leal-10(%rdx,%rax), %eax
movl%eax, result(%rip)
ret
.cfi_endproc
.LFE3:
.size compute, .-compute
.ident "GCC: (GNU) 9.0.0 20180702 (experimental)"
.section.note.GNU-stack,"",@progbits
From the above, we can see:
1. the call chains to —>“boo”->”foo”, “bar” in the routine “compute” are
completely inlined by early inliner into “compute”;
2. However, there is NO any inline information is dumped into “inline.txt”.
This PR is to request -fopt-info-inline support for early inliner
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2 from H.J. Lu ---
There is:
(insn 152 173 157 2 (set (reg:V16QI 21 xmm0 [168])
(mem/c:V16QI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [3 %sfp+-16 S16 A128]))
"x.i":14 1283 {movv16qi_internal}
(nil))
A128 seems incorrect.
[Bug middle-end/86380] incorrect comparison in function chose_multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86380 --- Comment #2 from Colin Bartlett --- I suspected that when compiled programs didn't show the error, but: 1. Is that documented anywhere? It might be useful if that was documented also in choose_multiplier? 2. Is that anyway any reason not to use the correct comparison, unless there is a good reason to use the wrong comparison?
[Bug target/86394] New: Broken -falign-functions=512 on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86394
Bug ID: 86394
Summary: Broken -falign-functions=512 on m68k
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org, schwab at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: m68k-linux
$ cat /tmp/main.c
static int foo()
{
return 123;
}
int main()
{
return foo();
}
$ ./xgcc -B. -O2 /tmp/main.c -falign-functions=128 -S -o/dev/stdout
#NO_APP
.file "main.c"
.text
.section.text.startup,"ax",@progbits
.align 2
.align 128
.globl main
.type main, @function
Value of '.align 128' is wrong, should be '.align 7'.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 85694, which changed state. Bug 85694 Summary: Generation of vectorized AVG (Average) instruction https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #11 from Uroš Bizjak --- Fixed also for x86 targets.
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jul 3 17:33:28 2018 New Revision: 262354 URL: https://gcc.gnu.org/viewcvs?rev=262354=gcc=rev Log: PR target/85694 * config/i386/sse.md (uavg3_ceil): New expander. (_uavg3): Simplify expander. testsuite/ChangeLog: PR target/85694 * gcc.target/i386/pr85694.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85694.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 --- Comment #4 from Mikael Slevinsky --- I'm not sure if this answers your question, but compiling the same program (modifying 8 to 128 to tease the compiler into using zmm registers) with clang-6 works fine.
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Mikael Slevinsky from comment #2) > If I call it `testavx512.c`, then AVX512-like assembly is created, but it > errors when trying to create an executable: > > dhcp-10-45-0-78:FastTransforms mikael$ gcc-8 -S -O3 -mavx512f testavx512.c > -o testavx512.s > dhcp-10-45-0-78:FastTransforms mikael$ gcc-8 -O3 -mavx512f testavx512.c -o > testavx512 > /var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:45:2: error: > instruction requires: AVX-512 ISA > vmovupd 0(%r13), %zmm0 > ^ > /var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:46:2: error: > instruction requires: AVX-512 ISA > vaddpd (%r12), %zmm0, %zmm0 > ^ > /var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:47:2: error: > instruction requires: AVX-512 ISA > vmovupd %zmm0, (%rax) > ^ Does your assembler support AVX512F at all? And if it does, does it require some magic options to be passed to the assembler so that it is supported? Usually on x86_64 assemblers accept all ISAs by default without special magic options, but perhaps the assembler on darwin violates this.
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Jul 3 16:38:16 2018 New Revision: 262353 URL: https://gcc.gnu.org/viewcvs?rev=262353=gcc=rev Log: PR c++/86201 * typeck.c (cp_build_binary_op): Check c_inhibit_evaluation_warnings. * g++.dg/diagnostic/pr86201.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr86201.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 --- Comment #4 from Jason Merrill --- Author: jason Date: Tue Jul 3 16:27:04 2018 New Revision: 262352 URL: https://gcc.gnu.org/viewcvs?rev=262352=gcc=rev Log: PR c++/86378 - functional cast in noexcept-specifier. * tree.c (strip_typedefs_expr) [TREE_LIST]: Fix iteration. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/noexcept33.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/tree.c
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Jul 3 16:25:55 2018 New Revision: 262351 URL: https://gcc.gnu.org/viewcvs?rev=262351=gcc=rev Log: PR c++/86378 - functional cast in noexcept-specifier. * tree.c (strip_typedefs_expr) [TREE_LIST]: Fix iteration. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/noexcept33.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/tree.c
[Bug c++/85155] Suboptimal error messages when using noexcept(false) on defaulted dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85155 --- Comment #2 from Jonathan Wakely --- GCC's behaviour is correct by the resolution of https://wg21.link/cwg1778 but apparently that rule causes problems. Maybe Clang doesn't support it yet.
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00130.html
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393
--- Comment #2 from Mikael Slevinsky ---
I'm not so sure. Consider the following minimal test file:
#include
#include
int main(void) {
double * X, * Y, * Z;
X = (double *) calloc(8, sizeof(double));
Y = (double *) calloc(8, sizeof(double));
Z = (double *) calloc(8, sizeof(double));
for (int i = 0; i < 8; i++) {
X[i] = (double) i;
Y[i] = ((double) i)*((double) 2*i+1);
}
for (int i = 0; i < 8; i++)
Z[i] = X[i] + Y[i];
printf("\n");
for (int i = 0; i < 8; i++) {
printf("%1.2e ", Z[i]);
}
printf("\n");
return 0;
}
If I call it `testavx512.c`, then AVX512-like assembly is created, but it
errors when trying to create an executable:
dhcp-10-45-0-78:FastTransforms mikael$ gcc-8 -S -O3 -mavx512f testavx512.c -o
testavx512.s
dhcp-10-45-0-78:FastTransforms mikael$ gcc-8 -O3 -mavx512f testavx512.c -o
testavx512
/var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:45:2: error:
instruction requires: AVX-512 ISA
vmovupd 0(%r13), %zmm0
^
/var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:46:2: error:
instruction requires: AVX-512 ISA
vaddpd (%r12), %zmm0, %zmm0
^
/var/folders/dy/wbvgp8656tg6kwtz8sx_9z_mgn/T//cchgQrNi.s:47:2: error:
instruction requires: AVX-512 ISA
vmovupd %zmm0, (%rax)
^
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 --- Comment #9 from Uroš Bizjak --- Created attachment 44348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44348=edit x86 target patch I'm testing the attached patch for x86 targets.
[Bug target/86388] Enhancement: sort "valid arguments to '-march=' switch" suggestions alphabetically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86388 --- Comment #3 from Eric Gallager --- (In reply to Alexander Monakov from comment #1) > I'd prefer existing ordering relative to alphabetical: the list produced by > GCC is mostly ordered first by manufacturer, then by > generation/capabilities. Placement of the 'x86-64' entry seems odd, but, > other than that, I like the order. > > The manual also orders -march entries in this "manufacturer-capabilities" > style. See I don't know my CPU generations/capabilities, all I want to do is find the one I meant to type, and the easiest way to do that would be to look for where it would be placed alphabetically
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #8 from rsandifo at gcc dot gnu.org --- Fixed on trunk for AArch64. Please could someone define the appropriate avgM3_floor, uavgM3_floor, avgM3_ceil and uavgM3_ceil patterns for x86?
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 Jonathan Wakely changed: What|Removed |Added Target||x86_64-*-* Component|c |target --- Comment #1 from Jonathan Wakely --- I think GCC correctly detects that your CPU supports AVX512 (see the -mtune option it chooses) but those instructions don't always result in faster code, so I think you need to enable them explicitly.
[Bug c++/86392] templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392 --- Comment #3 from rene.r...@fu-berlin.de --- Thank you very much for the explanation and sorry for using the wrong platform ;)
[Bug c++/86392] templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- (In reply to rene.rahn from comment #0) > The same behaviour happens with clang, so I think I am just missing > something here and I would appreciate a short explanation. Reporting a bug is not really appropriate way to ask somebody to explain how C++ works. You could have asked on the gcc-help mailing or somewhere like stackoverflow. When the compiler sees get<0 it doesn't know if it's parsing a template-name or a comparison to zero. Unqualified name lookup is performed for the name "get", and when it finds ::get it knows that it's dealing with a template-name. The rest of the expression get<0>(f) is then treated as a function call, and so argument dependent lookup is performed for the type foo, which finds the friend function.
[Bug c/86393] New: GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 Bug ID: 86393 Summary: GCC-8 appears to not detect AVX512 on iMac Pro 2018 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mrslevinsky at hotmail dot com Target Milestone: --- On GCC-8, build details: dhcp-10-45-0-78:~ mikael$ gcc-8 -v Using built-in specs. COLLECT_GCC=gcc-8 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.1.0/libexec/gcc/x86_64-apple-darwin17.5.0/8.1.0/lto-wrapper Target: x86_64-apple-darwin17.5.0 Configured with: ../configure --build=x86_64-apple-darwin17.5.0 --prefix=/usr/local/Cellar/gcc/8.1.0 --libdir=/usr/local/Cellar/gcc/8.1.0/lib/gcc/8 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC 8.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-nls Thread model: posix gcc version 8.1.0 (Homebrew GCC 8.1.0) the compiler appears to fail to detect that the iMac Pro 2018 with a Skylake W generation Intel Xeon W processor has AVX512 vectorization capabilities, turning many compiler optimizations off: dhcp-10-45-0-78:~ mikael$ gcc-8 -march=native -E -v - &1 | grep cc1 /usr/local/Cellar/gcc/8.1.0/libexec/gcc/x86_64-apple-darwin17.5.0/8.1.0/cc1 -E -quiet -v -D__DYNAMIC__ - -march=skylake-avx512 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mclwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=25344 -mtune=skylake-avx512 -fPIC -mmacosx-version-min=10.13.0 On the contrary, clang-6 appears to enable AVX512: dhcp-10-45-0-78:~ mikael$ /usr/local/opt/llvm/bin/clang -march=native -E -v - &1 | grep cc1 "/usr/local/Cellar/llvm/6.0.0/bin/clang-6.0" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu skylake-avx512 -target-feature +sse2 -target-feature +cx16 -target-feature -tbm -target-feature -avx512ifma -target-feature -gfni -target-feature -sha -target-feature -fma4 -target-feature -vpclmulqdq -target-feature +prfchw -target-feature +bmi2 -target-feature +xsavec -target-feature +fsgsbase -target-feature +popcnt -target-feature +aes -target-feature -avx512bitalg -target-feature +xsaves -target-feature -avx512er -target-feature -avx512vnni -target-feature -avx512vpopcntdq -target-feature +clwb -target-feature -avx512f -target-feature -clzero -target-feature -pku -target-feature +mmx -target-feature -lwp -target-feature -xop -target-feature +rdseed -target-feature -ibt -target-feature -sse4a -target-feature -avx512bw -target-feature +clflushopt -target-feature +xsave -target-feature -avx512vbmi2 -target-feature -avx512vl -target-feature -avx512cd -target-feature +avx -target-feature -vaes -target-feature +rtm -target-feature +fma -target-feature +bmi -target-feature +rdrnd -target-feature -mwaitx -target-feature +sse4.1 -target-feature +sse4.2 -target-feature +avx2 -target-feature +sse -target-feature +lzcnt -target-feature +pclmul -target-feature -prefetchwt1 -target-feature +f16c -target-feature +ssse3 -target-feature -sgx -target-feature -shstk -target-feature +cmov -target-feature -avx512vbmi -target-feature +movbe -target-feature +xsaveopt -target-feature -avx512dq -target-feature +adx -target-feature -avx512pf -target-feature +sse3 -dwarf-column-info -debugger-tuning=lldb -target-linker-version 305 -v -resource-dir /usr/local/Cellar/llvm/6.0.0/lib/clang/6.0.0 -fdebug-compilation-dir /Users/mikael -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.13.0 -fmax-type-align=16 -fdiagnostics-show-option -o - -x c - clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target x86_64-apple-darwin17.4.0
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #5 from Jonathan Wakely --- (In reply to Hannes Hauswedell from comment #3) > BUT if this code generates warnings there is a problem: obviously I don't > want to tell downstream developers that "it's ok, just ignore the warnings" > (since I have a header-only library I cannot pre-decide this). And I cannot > workaround this in code short of introducing a MACRO. Strictly speaking, you can: #ifdef __has_cpp_attribute # if __has_cpp_attribute(likely) [[likely]] # endif #endif statement; It might be ugly, but it doesn't introduce any macro.
[Bug target/86388] Enhancement: sort "valid arguments to '-march=' switch" suggestions alphabetically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86388 Andrew Pinski changed: What|Removed |Added Target||x86_64 Component|driver |target --- Comment #2 from Andrew Pinski --- The order is what is specified in the .opt file.
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #4 from Martin Sebor --- It's quite unlikely (pun intended) that code randomly sprinkled with various non-standard annotations (attributes, pragmas, or otherwise) will eventually have the same effect across all implementations once they recognize it. With the attribute spec as loose as it is, implementations haven't even converged on the same effect for the standard attributes, so there is little chance that they will for those that aren't specified. I think the expected progression of new attributes is from vendor namespaces to the standard global namespace and so, as Jonathan suggests, not warning by default for unknown attributes in other vendor's namespaces (e.g., [[foo:unlikely]] might be reasonable. Warning for unknown attributes in the global namespace (i.e., [[unlikely]]) or in our own (i.e., [[gnu::unlikely]]) is the right choice. As an aside, while the C++ standard doesn't allow C++ programs to define macros with the same names as those of standard attributes, nothing prevents a non-standard attributes from being #defined as macros (and since C doesn't support attributes of any kind yet, nothing prevents library headers written in C from #defining even C++ standard attributes as macros). This makes relying on non-standard attributes in library headers problematic in either language (and points to a design flaw in the attribute design).
[Bug c++/86392] templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392 --- Comment #1 from rene.r...@fu-berlin.de --- Created attachment 44347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44347=edit The example
[Bug c++/86392] New: templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392
Bug ID: 86392
Summary: templatized friend member function needs declaration
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi, I need some help to understand the following behaviour.
I have a class with a friend get function which implements the
behaviour of std::get. However, the compiler can't find the get function in my
namespace unless I either declare some global function template with the name
get. But it does not even have to match the friend's declaration, as long as
the name is declared once in the namespace or I made with using std::get some
get visible in the context.
Now, I was wondering why for such a template function ADL doesn't work.
Note that it works without out-of-class declaration if the friend template
function uses all it's template parameters as arguments.
So for example:
template
class foo
{
template
friend auto bar(_t && a, foo && b) { ... }
};
would work and the compiler will find bar(3, foo{});
The same behaviour happens with clang, so I think I am just missing something
here and I would appreciate a short explanation.
Sorry for bothering you with probably such simple concerns.
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 --- Comment #7 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jul 3 14:27:28 2018 New Revision: 262347 URL: https://gcc.gnu.org/viewcvs?rev=262347=gcc=rev Log: [17/n] PR85694: AArch64 support for AVG_FLOOR/CEIL This patch adds AArch64 patterns for the new AVG_FLOOR/CEIL operations. AVG_FLOOR is [SU]HADD and AVG_CEIL is [SU]RHADD. 2018-07-03 Richard Sandiford gcc/ PR tree-optimization/85694 * config/aarch64/iterators.md (HADD, RHADD): New int iterators. (u): Handle UNSPEC_SHADD, UNSPEC_UHADD, UNSPEC_SRHADD and UNSPEC_URHADD. * config/aarch64/aarch64-simd.md (avg3_floor) (avg3_ceil): New patterns. gcc/testsuite/ PR tree-optimization/85694 * lib/target-supports.exp (check_effective_target_vect_avg_qi): Return true for AArch64 without SVE. * gcc.target/aarch64/vect_hadd_1.h: New file. * gcc.target/aarch64/vect_shadd_1.c: New test. * gcc.target/aarch64/vect_srhadd_1.c: Likewise. * gcc.target/aarch64/vect_uhadd_1.c: Likewise. * gcc.target/aarch64/vect_urhadd_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/vect_hadd_1.h trunk/gcc/testsuite/gcc.target/aarch64/vect_shadd_1.c trunk/gcc/testsuite/gcc.target/aarch64/vect_srhadd_1.c trunk/gcc/testsuite/gcc.target/aarch64/vect_uhadd_1.c trunk/gcc/testsuite/gcc.target/aarch64/vect_urhadd_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/config/aarch64/iterators.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug c++/84306] Wrong overload selected with -std=c++17, explicit and {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84306 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Added.
[Bug c++/84306] Wrong overload selected with -std=c++17, explicit and {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84306 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Tue Jul 3 14:25:38 2018 New Revision: 262345 URL: https://gcc.gnu.org/viewcvs?rev=262345=gcc=rev Log: PR c++/84306 * g++.dg/overload/conv-op3.C: New test. Added: trunk/gcc/testsuite/g++.dg/overload/conv-op3.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/86391] New: Cannot pass array as aliased formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86391 Bug ID: 86391 Summary: Cannot pass array as aliased formal parameter Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: laguest at archeia dot com Target Milestone: --- When passing an initialised array as an aliased formal, the compiler complains: mem.adb:13:11: untagged actual does not match aliased formal "B" Source: procedure Mem is type IA is array (Positive range <>) of Integer; type IA_Ptr is access all IA; procedure Inner (B : aliased in out IA) is null; -- S : aliased IA (1 .. 10) := (others => 0); -- This does not work for some reason?? -- S : aliased IA (1 .. 10) := (1 .. 10 => 0); -- This does not work for some reason?? -- S : aliased IA := (1 .. 10 => 0); -- This works. -- S : aliased IA := (0, 1, 2, 3, 4, 5); -- This works. begin Inner (S); end Mem;
[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info calling an invalid memcpy() declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Tue Jul 3 14:21:15 2018 New Revision: 262344 URL: https://gcc.gnu.org/viewcvs?rev=262344=gcc=rev Log: PR middle-end/86202 * gimple-fold.c (size_must_be_zero_p): Check the type of the size. * gcc.dg/Wint-conversion-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wint-conversion-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Jul 3 14:13:02 2018 New Revision: 262343 URL: https://gcc.gnu.org/viewcvs?rev=262343=gcc=rev Log: PR c++/86378 - functional cast in noexcept-specifier. * tree.c (strip_typedefs_expr) [TREE_LIST]: Fix iteration. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #3 from Hannes Hauswedell --- (In reply to Jonathan Wakely from comment #2) > It might be reasonable for GCC to silently ignore attributes that use an > unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or > [[acme::rocketboots]] they probably aren't expecting GCC to handle it. > > This could mean silently ignoring typos like [[ngu::unused]] but it's > arguably easier to spot a typo like "ngu" than to spot "warn_unsued_result" > or "alwasy_inlne". That's true, but I would still argue that *by default* GCC should also ignore [[foobar]] if it doesn't know it. Let me elaborate: I develop a header-only library and want to start including [[likely]] so that for newer compilers things "start working" as soon as they pick up the feature. I am ok with [[likely]] not being interpreted by the compiler, that's why a choose an attribute to begin with and not some low-level magic, but if it works, all the better. This is precisely what attributes are designed for and why they are supposed to be ignored if unknown. BUT if this code generates warnings there is a problem: obviously I don't want to tell downstream developers that "it's ok, just ignore the warnings" (since I have a header-only library I cannot pre-decide this). And I cannot workaround this in code short of introducing a MACRO. Note that not being able to workaround the warning makes this different from almost all other warnings I am aware of. And wrapping future attributes in MACROs just to be able to ship code that is warning/error-free clearly defeats the intent of the standard, or not? I am not sure, maybe we should take the question to a reflector?
[Bug ipa/86389] execute FAILs with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86389 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Jul 3 13:56:58 2018 New Revision: 262341 URL: https://gcc.gnu.org/viewcvs?rev=262341=gcc=rev Log: 2018-07-03 Richard Biener PR ipa/86389 * tree-ssa-structalias.c (find_func_clobbers): Properly handle indirect calls. * gcc.dg/torture/pr86389.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr86389.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 --- Comment #11 from c...@mnet-mail.de --- Thanks for the fix! On 07/03/2018 12:48 PM, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 > > Paul Thomas changed: > > What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #10 from Paul Thomas --- > Fixed on 6- through 9-branches. > > The I used the wrong logfile for the commits to 8- and 9-branches; it went to > PR45305 instead. > > Thanks for the report. > > Paul >
[Bug target/86390] ICE in output_branch, at config/sh/sh.c:2740 for sh-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86390 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-7-3 Target Milestone|--- |9.0
[Bug target/86390] New: ICE in output_branch, at config/sh/sh.c:2740 for sh-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86390
Bug ID: 86390
Summary: ICE in output_branch, at config/sh/sh.c:2740 for
sh-linux
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Following causes ICE:
$ cat ice.c
typedef int a;
int *b;
a c, d;
void e() {
a f, g;
while (d)
while (1) {
while (1)
if (g)
break;
c = b[f];
f++;
if (c)
break;
f++;
while (1) {
if (f > g)
break;
c = b[g];
if (c) {
g--;
continue;
}
break;
}
if (f > g)
break;
}
}
$ /dev/shm/gcc-batch-builds/objs/sh-linux/gcc/xg++ -B
/dev/shm/gcc-batch-builds/objs/sh-linux/gcc/ -O2 -S
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/params/blocksort-part.c -o
/tmp/tmp1xxph4eh -falign-jumps=1024
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/params/blocksort-part.c: In
function ‘void fallbackQSort3(UInt32*, UInt32*, Int32, Int32)’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/params/blocksort-part.c:199:1:
internal compiler error: in output_branch, at config/sh/sh.c:2740
}
^
0x769c311a __libc_start_main
../csu/libc-start.c:308
0x862669 ???
../sysdeps/x86_64/start.S:120
[Bug bootstrap/86376] recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from Martin Liška --- (In reply to David Binderman from comment #0) > Doing a ubsan build with revision 261981 worked. > > Doing same with revision 262304 doesn't. It breaks at > the compare of stage 2 and stage 3. > > Configure line is > > ../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \ > --with-build-config=bootstrap-ubsan \ > --disable-multilib \ > --disable-werror \ > --enable-checking=df,extra,fold,rtl,yes \ > --enable-languages=c,c++,fortran Works for me for trunk@262278.
[Bug target/86387] [RISCV][ABI] GCC fails to sign/zero-ext integers as necessary for passing/returning int+fp structs on with hard-float ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387
Alex Bradbury changed:
What|Removed |Added
Summary|[RISCV][ABI] GCC fails to |[RISCV][ABI] GCC fails to
|sign/zero-ext integers as |sign/zero-ext integers as
|necessary for return of |necessary for
|int+fp structs in with |passing/returning int+fp
|hard-float ABIs |structs on with hard-float
||ABIs
--- Comment #1 from Alex Bradbury ---
Changing title as this bug affects both return and argument passing. I could
create a separate bug report if preferred, but the issues seem so closely
related it might make most sense to keep here.
No sign or zero-extension takes place in the following example, but as-per the
ABI it should.
I actually sought clarification on this aspect of the ABI last September, to
perhaps this is a regression in GCC behaviour?
https://github.com/riscv/riscv-elf-psabi-doc/issues/37
$ cat foo.c
#include
struct s_u8_f { uint8_t i; float f; };
struct s_i8_f { int8_t i; float f; };
void must_receive_zext_arg(struct s_u8_f);
void must_receive_sext_arg(struct s_i8_f);
void should_zext_arg(int8_t i, float f) {
struct s_u8_f s;
s.i = i;
s.f = f;
must_receive_zext_arg(s);
}
void should_sext_arg(uint8_t i, float f) {
struct s_i8_f s;
s.i = i;
s.f = f;
must_receive_sext_arg(s);
}
./riscv32-unknown-elf-gcc -march=rv32imf -mabi=ilp32f foo.c -S -o - -O1
.file "foo.c"
.option nopic
.text
.align 2
.globl should_zext_arg
.type should_zext_arg, @function
should_zext_arg:
addisp,sp,-32
sw ra,28(sp)
callmust_receive_zext_arg
lw ra,28(sp)
addisp,sp,32
jr ra
.size should_zext_arg, .-should_zext_arg
.align 2
.globl should_sext_arg
.type should_sext_arg, @function
should_sext_arg:
addisp,sp,-32
sw ra,28(sp)
callmust_receive_sext_arg
lw ra,28(sp)
addisp,sp,32
jr ra
.size should_sext_arg, .-should_sext_arg
.ident "GCC: (GNU) 9.0.0 20180703 (experimental)"
[Bug driver/86388] Enhancement: sort "valid arguments to '-march=' switch" suggestions alphabetically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86388 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- I'd prefer existing ordering relative to alphabetical: the list produced by GCC is mostly ordered first by manufacturer, then by generation/capabilities. Placement of the 'x86-64' entry seems odd, but, other than that, I like the order. The manual also orders -march entries in this "manufacturer-capabilities" style.
[Bug c++/86082] user-defined literals are not converted to the execution charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86082 --- Comment #7 from Jonathan Wakely --- I can't approve that, I was just checking if this should be closed now (and testing updates to a version=8.0.1 bug after Richi made some Bugzilla config changes).
[Bug bootstrap/86376] recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 --- Comment #5 from Martin Liška --- My UBSAN bootstrap is broken by a recent commit: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00111.html I'll try a bit older revision to see if I see also the debug info comparison failure.
[Bug ipa/86389] execute FAILs with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86389 Richard Biener changed: What|Removed |Added Blocks||85960 --- Comment #2 from Richard Biener --- Caused by the PR85960 fix, testing fix. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960 [Bug 85960] -fipa-pta and ifunc are incompatible
[Bug ipa/86389] New: execute FAILs with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86389
Bug ID: 86389
Summary: execute FAILs with -fipa-pta
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Running target unix/-fipa-pta
FAIL: gfortran.dg/array_constructor_8.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/array_constructor_8.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test
FAIL: go.test/test/fixedbugs/bug262.go execution, -O2 -g
FAIL: go.test/test/fixedbugs/bug286.go execution, -O2 -g
FAIL: go.test/test/fixedbugs/bug293.go execution, -O2 -g
FAIL: go.test/test/fixedbugs/issue6899.go execution
FAIL: go.test/test/goprint.go execution
FAIL: go.test/test/helloworld.go execution
...
FAIL: 30_threads/call_once/call_once1.cc execution test
most simple is
FAIL: gcc.target/i386/pr85044.c execution test
which can be reduced to the following aborting() with -O -fipa-pta
void callme (void (*callback) (void));
int
main (void)
{
int ok = 0;
void callback (void) { ok = 1; }
callme ();
if (!ok)
__builtin_abort ();
return 0;
}
__attribute__((noinline, noclone))
void
callme (void (*callback) (void))
{
(*callback) ();
}
[Bug ipa/86389] execute FAILs with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86389 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug driver/86388] New: Enhancement: sort "valid arguments to '-march=' switch" suggestions alphabetically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86388
Bug ID: 86388
Summary: Enhancement: sort "valid arguments to '-march='
switch" suggestions alphabetically
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
Target Milestone: ---
I typed:
$ gcc -c -march=1486 15896.c
cc1: error: bad value ('1486') for '-march=' switch
cc1: note: valid arguments to '-march=' switch are: nocona core2 nehalem corei7
westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2
broadwell skylake skylake-avx512 bonnell atom silvermont slm knl x86-64 eden-x2
nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron
opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2
bdver3 bdver4 znver1 btver1 btver2
$
It'd be easier to look thru the list if they were sorted alphabetically like
this:
$ gcc -c -march=1486 15896.c
cc1: error: bad value ('1486') for '-march=' switch
cc1: note: valid arguments to '-march=' switch are: amdfam10 athlon-fx athlon64
athlon64-sse3 atom barcelona bdver1 bdver2 bdver3 bdver4 bonnell broadwell
btver1 btver2 core-avx-i core-avx2 core2 corei7 corei7-avx eden-x2 eden-x4
haswell ivybridge k8 k8-sse3 knl nano nano-1000 nano-2000 nano-3000 nano-x2
nano-x4 nehalem nocona opteron opteron-sse3 sandybridge silvermont skylake
skylake-avx512 slm westmere x86-64 znver1
$
[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Segher Boessenkool --- Fixed.
[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Tue Jul 3 11:22:24 2018 New Revision: 262340 URL: https://gcc.gnu.org/viewcvs?rev=262340=gcc=rev Log: Remove powerpc-linux_paired from config-list.mk The target has been removed, so we shouldn't try to build it. PR target/86382 * contrib/config-list.mk: Remove powerpc-linux_paired. Modified: trunk/ChangeLog trunk/contrib/config-list.mk
[Bug target/86387] New: [RISCV][ABI] GCC fails to sign/zero-ext integers as necessary for return of int+fp structs in with hard-float ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387
Bug ID: 86387
Summary: [RISCV][ABI] GCC fails to sign/zero-ext integers as
necessary for return of int+fp structs in with
hard-float ABIs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The psABI is documented here:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
Structs of containing one int and one fp value are passed in int+fp registers,
as described here:
"""
A struct containing one floating-point real and one integer, in either order,
is passed in a floating-point register and an integer register, with the
integer zero- or sign-extended as though it were a scalar, provided the
floating-point real is no more than FLEN bits wide and the integer is no more
than XLEN bits wide, and at least one floating-point argument register and at
least one integer argument register is available. Otherwise, it is passed
according to the integer calling convention.
"""
Scalar sign/zero-extension is specified as "When passed in registers, scalars
narrower than XLEN bits are widened according to the sign of their type up to
32 bits, then sign-extended to XLEN bits."
As for return, the document states "Values are returned in the same manner as a
first named argument of the same type would be passed."
Assume a struct consisting of a uint8 and a float:
struct s_u8_f { uint8_t i; float f; };
By the above rules if passed as the first argument to a function, we would
expect to see i in a0 (zero-extended), and f in fa0. As specified above, we
expect the same if this struct is returned by value.
GCC does not sign or zero-extend as it should as demonstrated in the program
below.
$ cat foo.c
#include
struct s_u8_f { uint8_t i; float f; };
struct s_i8_f { int8_t i; float f; };
struct s_u8_f should_zext_arg(int8_t i, float f) {
struct s_u8_f s;
s.i = i;
s.f = f;
return s;
}
struct s_i8_f should_sext_arg(uint8_t i, float f) {
struct s_i8_f s;
s.i = i;
s.f = f;
return s;
}
$ ./riscv32-unknown-elf-gcc -march=rv32imf -mabi=ilp32f foo.c -S -o - -O1
.file "foo.c"
.option nopic
.text
.align 2
.globl should_zext_arg
.type should_zext_arg, @function
should_zext_arg:
addisp,sp,-32
addisp,sp,32
jr ra
.size should_zext_arg, .-should_zext_arg
.align 2
.globl should_sext_arg
.type should_sext_arg, @function
should_sext_arg:
addisp,sp,-32
addisp,sp,32
jr ra
.size should_sext_arg, .-should_sext_arg
.ident "GCC: (GNU) 9.0.0 20180703 (experimental)"
[Bug c++/84306] Wrong overload selected with -std=c++17, explicit and {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84306 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-03 Target Milestone|--- |8.2 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Looks like the stack is not aligned for some odd reason. Doesn't need AVX512 at runtime btw, just the flag somehow triggers it... -mavx is enough btw.
[Bug target/86386] New: [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386 Bug ID: 86386 Summary: [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 44346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44346=edit reduced testcase I am not 100% sure the testcase has defined behavior (due to the cast to char*), but there are no compilation warning and -fsanitize=undefined does not give any error. Output: $ x86_64-pc-linux-gnu-gcc -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw testcase.c $ ./a.out Segmentation fault Program received signal SIGSEGV, Segmentation fault. 0x00400529 in a (g=g@entry=0 '\000', h=h@entry=0, i=i@entry=0, j=j@entry=0, k=k@entry=0 '\000', l=l@entry=4, m=1, n=) at testcase.c:14 14__builtin_memcpy (, 2 + (char *) , 1); 0x0040051f <+61>:mov-0x8(%rsp),%rcx 0x00400524 <+66>:mov%rax,-0x10(%rsp) => 0x00400529 <+71>:vmovdqa -0x10(%rsp),%xmm0 0x0040052f <+77>:mov-0x10(%rsp),%rax 0x00400534 <+82>:vpextrb $0x2,%xmm0,0x10(%rbp) (gdb) p $rsp $1 = (void *) 0x7fffd648 $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-262329-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-262329-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix gcc version 9.0.0 20180703 (experimental) (GCC)
[Bug fortran/82969] [6/7/8/9 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Fixed on 6- through 9-branches. The I used the wrong logfile for the commits to 8- and 9-branches; it went to PR45305 instead. Thanks for the report. Paul
[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on 6- through 9-branches. The I used the wrong logfile for the commits to 8- and 9-branches; it went to PR45305 instead. Thanks for the report. Paul
[Bug c++/84893] Rejects a valid code with variadic function template taking a function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84893
Jonathan Wakely changed:
What|Removed |Added
Version|8.0.1 |8.1.0
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=83672
--- Comment #2 from Jonathan Wakely ---
EDG accepts it but Clang doesn't:
84893.cc:7:5: error: no matching function for call to 'f'
f(g);
^~~
84893.cc:2:6: note: candidate template ignored: failed template argument
deduction
void f(void(*)(T..., int)) { }
^
1 error generated.
[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 --- Comment #9 from Paul Thomas --- Author: pault Date: Tue Jul 3 10:45:52 2018 New Revision: 262339 URL: https://gcc.gnu.org/viewcvs?rev=262339=gcc=rev Log: 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * trans-array.c (structure_alloc_comps): Do not explicitly copy procedure pointer components. 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * gfortran.dg/proc_ptr_50.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-array.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/82969] [6/7/8/9 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969 --- Comment #6 from Paul Thomas --- Author: pault Date: Tue Jul 3 10:45:52 2018 New Revision: 262339 URL: https://gcc.gnu.org/viewcvs?rev=262339=gcc=rev Log: 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * trans-array.c (structure_alloc_comps): Do not explicitly copy procedure pointer components. 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * gfortran.dg/proc_ptr_50.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-array.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/85569] [8/9 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Version|8.0.1 |8.1.0
Keywords||rejects-valid
Last reconfirmed||2018-07-03
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
Summary|is_invocable(F, |[8/9 Regression]
|decltype(objs)...) fails |is_invocable(F,
|with "not supported by |decltype(objs)...) fails
|dump_expr#" unless via |with "not supported by
|indirection |dump_expr#" unless via
||indirection
Known to fail||8.1.0, 9.0
--- Comment #4 from Jonathan Wakely ---
Preprocessing it with GCC 7.3 and trying to compile it shows it started to be
rejected with r251433 ("Reimplement handling of lambdas in templates") with
this diagnostic:
85569-gcc7.cc: In instantiation of ‘compose(F&&, Fs&& ...) [with F = const
equal(T&&) [with T = int]::&; Fs =
{std::plus}]:: [with auto:2 = {int, int}; decltype
(detail::compose(typename std::is_invocable, decltype
(objs)...>::type{}, f, compose(forward >(fs#0)),
(forward)(compose::__lambda1::operator()::objs)...))
= bool; decltype (objs) = int&&]’:
85569-gcc7.cc:90:23: required from here
85569-gcc7.cc:79:20: error: use ‘...’ to expand argument pack
85569-gcc7.cc:89:1: error: non-constant condition for static assertion
85569-gcc7.cc:90:23: in constexpr expansion of ‘compose&, std::plus >(eq<3>,
std::plus{}).compose(F&&, Fs&& ...) [with F = const equal(T&&) [with T =
int]::&; Fs = {std::plus}]::(1, 2)’
85569-gcc7.cc:89:1: error: constexpr call flows off the end of the function
Then the diagnostic regressed with r257018 ("PR c++/82249 - wrong mismatched
pack length error"):
85569-gcc7.cc: In instantiation of ‘constexpr auto compose(F&&, Fs&& ...) [with
F = const equal(T&&) [with T = int]::&; Fs =
{std::plus}]’:
85569-gcc7.cc:90:22: required from here
85569-gcc7.cc:79:20: error: expansion pattern ‘decltype
(#‘nontype_argument_pack’ not supported by dump_expr#)’
contains no argument packs
85569-gcc7.cc:90:23: error: non-constant condition for static assertion
85569-gcc7.cc:90:23: error: call to non-‘constexpr’ function ‘compose(F&&, Fs&&
...) [with F = const equal(T&&) [with T = int]::&; Fs =
{std::plus}]:: [with auto:2 = {int, int}; decltype
(detail::compose(typename std::is_invocable, decltype
(objs)...>::type{}, f, compose(forward >(fs#0)),
(forward)(compose::__lambda1::operator()::objs)...))
= bool; decltype (objs) = int&&]’
85569-gcc7.cc:68:8: note: ‘compose(F&&, Fs&& ...) [with F = const equal(T&&)
[with T = int]::&; Fs =
{std::plus}]:: [with auto:2 = {int, int}; decltype
(detail::compose(typename std::is_invocable, decltype
(objs)...>::type{}, f, compose(forward >(fs#0)),
(forward)(compose::__lambda1::operator()::objs)...))
= bool; decltype (objs) = int&&]’ is not usable as a ‘constexpr’ function
because:
[Bug c++/86082] user-defined literals are not converted to the execution charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86082 --- Comment #6 from Andreas Krebbel --- (In reply to jwakely from comment #5) > On 03/07/18 10:07 +, r...@gcc.gnu.org wrote: > >--- Comment #4 from Jonathan Wakely --- > >Is this fixed now? > > Or do you plan to backport it? I would like to backport it to GCC 7 and 8 branch as well. Ok?
[Bug c++/84893] Rejects a valid code with variadic function template taking a function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84893 --- Comment #1 from Jonathan Wakely --- We have a number of very similar bugs related to deducing function types from function pointers.
[Bug c++/85155] Suboptimal error messages when using noexcept(false) on defaulted dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85155
Jonathan Wakely changed:
What|Removed |Added
Version|8.0.1 |8.1.0
--- Comment #1 from Jonathan Wakely ---
struct B {
virtual ~B() noexcept(false) = default;
};
struct D : B {
virtual ~D() { throw 17; }
};
int main()
{
try {
D d;
return 1;
} catch (int n) {
return n;
}
}
EDG gives a similar result to GCC:
"85155.cc", line 6: error: nondeleted function overrides deleted function
"B::~B"
virtual ~D() { throw 17; }
^
"85155.cc", line 6: error: function "B::~B()" (declared at line 2) cannot be
referenced -- it is a deleted function
virtual ~D() { throw 17; }
^
"85155.cc", line 12: error: the default constructor of "D" cannot be referenced
-- it is a deleted function
D d;
^
3 errors detected in the compilation of "85155.cc".
Clang gives an error as soon as it sees the defaulted destructor, that's why
there are no errors given for the derived class:
struct B {
virtual ~B() noexcept(false) = default;
};
85155.cc:2:11: error: exception specification of explicitly defaulted
destructor does not match the calculated one
virtual ~B() noexcept(false) = default;
^
1 error generated.
I can't find any justification in the standard for Clang's behaviour, the
destructor should only be ill-formed if it is potentially invoked.
[Bug c++/84306] Wrong overload selected with -std=c++17, explicit and {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84306 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-03 Known to work||8.1.0, 9.0 Version|8.0.1 |7.3.1 Ever confirmed|0 |1 Known to fail||7.3.0 --- Comment #1 from Jonathan Wakely --- This was fixed by r258755 so seems to be a dup of PR 81311 but we should add the testcase.
[Bug c++/86082] user-defined literals are not converted to the execution charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86082 --- Comment #5 from jwakely at redhat dot com --- On 03/07/18 10:07 +, r...@gcc.gnu.org wrote: >--- Comment #4 from Jonathan Wakely --- >Is this fixed now? Or do you plan to backport it?
[Bug c++/86082] user-defined literals are not converted to the execution charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86082 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-03 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- Is this fixed now?
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jul 3 10:03:44 2018 New Revision: 262335 URL: https://gcc.gnu.org/viewcvs?rev=262335=gcc=rev Log: [16/n] PR85694: Add detection of averaging operations This patch adds detection of average instructions: a = (((wide) b + (wide) c) >> 1); --> a = (wide) .AVG_FLOOR (b, c); a = (((wide) b + (wide) c + 1) >> 1); --> a = (wide) .AVG_CEIL (b, c); in cases where users of "a" need only the low half of the result, making the cast to (wide) redundant. The heavy lifting was done by earlier patches. This showed up another problem in vectorizable_call: if the call is a pattern definition statement rather than the main pattern statement, the type of vectorised call might be different from the type of the original statement. 2018-07-03 Richard Sandiford gcc/ PR tree-optimization/85694 * doc/md.texi (avgM3_floor, uavgM3_floor, avgM3_ceil) (uavgM3_ceil): Document new optabs. * doc/sourcebuild.texi (vect_avg_qi): Document new target selector. * internal-fn.def (IFN_AVG_FLOOR, IFN_AVG_CEIL): New internal functions. * optabs.def (savg_floor_optab, uavg_floor_optab, savg_ceil_optab) (savg_ceil_optab): New optabs. * tree-vect-patterns.c (vect_recog_average_pattern): New function. (vect_vect_recog_func_ptrs): Add it. * tree-vect-stmts.c (vectorizable_call): Get the type of the zero constant directly from the associated lhs. gcc/testsuite/ PR tree-optimization/85694 * lib/target-supports.exp (check_effective_target_vect_avg_qi): New proc. * gcc.dg/vect/vect-avg-1.c: New test. * gcc.dg/vect/vect-avg-2.c: Likewise. * gcc.dg/vect/vect-avg-3.c: Likewise. * gcc.dg/vect/vect-avg-4.c: Likewise. * gcc.dg/vect/vect-avg-5.c: Likewise. * gcc.dg/vect/vect-avg-6.c: Likewise. * gcc.dg/vect/vect-avg-7.c: Likewise. * gcc.dg/vect/vect-avg-8.c: Likewise. * gcc.dg/vect/vect-avg-9.c: Likewise. * gcc.dg/vect/vect-avg-10.c: Likewise. * gcc.dg/vect/vect-avg-11.c: Likewise. * gcc.dg/vect/vect-avg-12.c: Likewise. * gcc.dg/vect/vect-avg-13.c: Likewise. * gcc.dg/vect/vect-avg-14.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-avg-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-10.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-11.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-12.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-13.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-14.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-2.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-3.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-4.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-5.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-6.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-7.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-8.c trunk/gcc/testsuite/gcc.dg/vect/vect-avg-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/md.texi trunk/gcc/doc/sourcebuild.texi trunk/gcc/internal-fn.def trunk/gcc/optabs.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-stmts.c
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 Richard Biener changed: What|Removed |Added Version|unknown |9.0 Target Milestone|--- |9.0
[Bug fortran/82969] [6/7/8/9 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue Jul 3 09:46:31 2018 New Revision: 262331 URL: https://gcc.gnu.org/viewcvs?rev=262331=gcc=rev Log: 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * trans-array.c (structure_alloc_comps): Do not explicitly copy procedure pointer components. 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * gfortran.dg/proc_ptr_50.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-array.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 --- Comment #8 from Paul Thomas --- Author: pault Date: Tue Jul 3 09:46:31 2018 New Revision: 262331 URL: https://gcc.gnu.org/viewcvs?rev=262331=gcc=rev Log: 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * trans-array.c (structure_alloc_comps): Do not explicitly copy procedure pointer components. 2018-07-03 Paul Thomas PR fortran/82969 PR fortran/86242 * gfortran.dg/proc_ptr_50.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-array.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/86285] We don't mangle __ieee128 correctly using -mlong-double-64 -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Segher Boessenkool --- Fixed everywhere.
[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Mine.
[Bug c++/86385] calling wrong constructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385
--- Comment #2 from Jonathan Wakely ---
Reduced slightly:
struct A {
int* a;
A(int a) : a(new int(a)) {}
~A() { delete a; }
A(const A&) = delete;
A(A&& other) { a = other.a; other.a = 0; };
operator bool() { return true; }
};
A makeA(int x) { return A(x); }
int main() {
makeA(42) ?: makeA(-1);
}
Valgrind shows:
==26332== Memcheck, a memory error detector
==26332== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26332== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26332== Command: ./a.out
==26332==
==26332== Invalid free() / delete / delete[] / realloc()
==26332==at 0x4C2E1E8: operator delete(void*) (vg_replace_malloc.c:576)
==26332==by 0x40078A: A::~A() (tern.cc:4)
==26332==by 0x400714: main (tern.cc:15)
==26332== Address 0x5ae4c80 is 0 bytes inside a block of size 4 free'd
==26332==at 0x4C2E1E8: operator delete(void*) (vg_replace_malloc.c:576)
==26332==by 0x40078A: A::~A() (tern.cc:4)
==26332==by 0x400708: main (tern.cc:15)
==26332== Block was alloc'd at
==26332==at 0x4C2D1CA: operator new(unsigned long)
(vg_replace_malloc.c:334)
==26332==by 0x400756: A::A(int) (tern.cc:3)
==26332==by 0x4006B1: makeA(int) (tern.cc:12)
==26332==by 0x4006D1: main (tern.cc:15)
==26332==
==26332==
==26332== HEAP SUMMARY:
==26332== in use at exit: 0 bytes in 0 blocks
==26332== total heap usage: 2 allocs, 3 frees, 72,708 bytes allocated
==26332==
==26332== All heap blocks were freed -- no leaks are possible
==26332==
==26332== For counts of detected and suppressed errors, rerun with: -v
==26332== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Asan shows:
=
==26649==ERROR: AddressSanitizer: attempting double-free on 0x60200010 in
thread T0:
#0 0x7f81bb1dc2c8 in operator delete(void*, unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:151
#1 0x400d4b in A::~A() /tmp/tern.cc:4
#2 0x400bdc in main /tmp/tern.cc:15
#3 0x7f81ba478f29 in __libc_start_main ../csu/libc-start.c:308
#4 0x400989 in _start (/tmp/a.out+0x400989)
0x60200010 is located 0 bytes inside of 4-byte region
[0x60200010,0x60200014)
freed by thread T0 here:
#0 0x7f81bb1dc2c8 in operator delete(void*, unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:151
#1 0x400d4b in A::~A() /tmp/tern.cc:4
#2 0x400bbf in main /tmp/tern.cc:15
#3 0x7f81ba478f29 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7f81bb1daed0 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:90
#1 0x400c9e in A::A(int) /tmp/tern.cc:3
#2 0x400a51 in makeA(int) /tmp/tern.cc:12
#3 0x400b25 in main /tmp/tern.cc:15
#4 0x7f81ba478f29 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: double-free
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:151 in operator
delete(void*, unsigned long)
==26649==ABORTING
Maybe the object is being copied by an implicitly-defined copy constructor, but
that's meant to be deleted and overload resolution should have used the move
constructor.
[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 --- Comment #1 from Segher Boessenkool --- *** Bug 86381 has been marked as a duplicate of this bug. ***
[Bug target/86381] New: Configuration powerpc-unknown-linux-gnu_paired not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86381 Bug ID: 86381 Summary: Configuration powerpc-unknown-linux-gnu_paired not supported Product: gcc Version: unknown Status: RESOLVED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- Status: RESOLVED Resolution: DUPLICATE It's listed in contrib/config-list.mk, should I remove that? --- Comment #1 from Segher Boessenkool --- dup *** This bug has been marked as a duplicate of bug 86382 ***
[Bug c++/86385] calling wrong constructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- You already reported this one too (PR 86184), and it already compiles on trunk, but crashes at runtime with a double-free. Please stop using 8.0.1 and test with current trunk.
[Bug c++/86384] Scoped enumeration instantiated even if not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86384 --- Comment #2 from Jonathan Wakely --- And please stop reporting bugs for 8.0.1 -- that's an unsupported pre-release build that could be from any time between January and April. Use 8.1.0 or trunk.
[Bug c++/86385] New: calling wrong constructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385
Bug ID: 86385
Summary: calling wrong constructors?
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
struct A {
int* a;
A(int a) : a(new int(a)) {}
~A() { delete a; }
A(const A&) = delete;
A(A&& other) { a = other.a; other.a = 0; };
operator bool() { return true; }
int operator*() { return *a; }
};
static A makeA(int x) { return A(x); }
int main() {
A c = makeA(42) ?: makeA(-1);
return *c;
}
g++ error:
error: lvalue required as unary '&' operand
A c = makeA(42) ?: makeA(-1);
It seems that g++ considers 42 and -1 as const A& or A&& other, instead of
integer values. Or else, it does not produce such a message. I tried clang++.
It accepts the code. For me, the results of clang++ are more reasonable.
[Bug c++/86183] Scoped enumeration instantiated even if not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86183 --- Comment #4 from Jonathan Wakely --- *** Bug 86384 has been marked as a duplicate of this bug. ***
