[Bug c++/82085] Crash: Template variable reference used in nested template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085 --- Comment #1 from Roland B --- Forgot to mention: The command line I used: /usr/local/gcc-trunk/bin/g++ -std=c++1z -Wall -Wpedantic -Wextra gcc-crash.cpp Output: gcc-crash.cpp:8:41: internal compiler error: Segmentation fault using type = char_sequence_t>; ^~ 0xe281af crash_signal ../../trunk/gcc/toplev.c:341 0x8184ec tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../trunk/gcc/cp/pt.c:17077 0x81c87b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../trunk/gcc/cp/pt.c:16708 0x827552 tsubst_template_args ../../trunk/gcc/cp/pt.c:11805 0x82bd2b tsubst(tree_node*, tree_node*, int, tree_node*) ../../trunk/gcc/cp/pt.c:13982 0x82c208 tsubst(tree_node*, tree_node*, int, tree_node*) ../../trunk/gcc/cp/pt.c:13578 0x83c682 lookup_template_class_1 ../../trunk/gcc/cp/pt.c:8880 0x83c682 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../trunk/gcc/cp/pt.c:9130 0x87b93d finish_template_type(tree_node*, tree_node*, int) ../../trunk/gcc/cp/semantics.c:3174 0x7dee18 cp_parser_template_id ../../trunk/gcc/cp/parser.c:15729 0x7defea cp_parser_class_name ../../trunk/gcc/cp/parser.c:22144 0x7d3ee0 cp_parser_qualifying_entity ../../trunk/gcc/cp/parser.c:6402 0x7d3ee0 cp_parser_nested_name_specifier_opt ../../trunk/gcc/cp/parser.c:6088 0x7ee9e1 cp_parser_simple_type_specifier ../../trunk/gcc/cp/parser.c:17055 0x7c9a2d cp_parser_type_specifier ../../trunk/gcc/cp/parser.c:16730 0x7ca9b2 cp_parser_type_specifier_seq ../../trunk/gcc/cp/parser.c:20976 0x7db074 cp_parser_type_id_1 ../../trunk/gcc/cp/parser.c:20819 0x7e3e51 cp_parser_type_id ../../trunk/gcc/cp/parser.c:20887 0x7e3e51 cp_parser_alias_declaration ../../trunk/gcc/cp/parser.c:18803 0x7e9b57 cp_parser_template_declaration_after_parameters ../../trunk/gcc/cp/parser.c:26549
[Bug c/82088] New: Implicit conversion "const char *x=" to "const char x[sizeof(...)]="
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82088 Bug ID: 82088 Summary: Implicit conversion "const char *x=" to "const char x[sizeof(...)]=" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- $ cat a.c const char * const a = "ABCD"; const char b[5] = "EFGH"; $ gcc -O3 -o a.o -c a.c && nm a.o 0008 R a R b $ gcc -fPIC -O3 -o a.o -c a.c && nm a.o D a R b Why doesn't gcc for PIC convert implicitly "const char *x=" to "const char x[sizeof(...)]=" in order to create more read-only data?
[Bug middle-end/82089] New: emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
Bug ID: 82089
Summary: emit_cstore sign-extends BImode result for
STORE_FLAG_VALUE == 1
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Say that in bfin.md, we redefine cstoresi4 in the following way:
...
(define_expand "cstoresi4"
[(set (match_operand:BI 0 "")
(match_operator:BI 1 "ordered_comparison_operator"
[(match_operand:SI 2 "register_operand" "")
(match_operand:SI 3 "reg_or_const_int_operand" "")]))]
"" {})
...
Then for a test-case:
...
int
foo (int a, int b)
{
return a == b;
}
...
compiled like this:
...
$ gcc test.c -S -O2 -fdump-rtl-all-all
...
we expand into this:
...
(insn 7 6 8 (set (reg:BI 62)
(ne:BI (reg/v:SI 58 [ aD.1438 ])
(reg/v:SI 59 [ bD.1439 ]))) "test.c":4 -1
(nil))
(insn 8 7 9 (set (reg:SI 61)
(ashift:SI (subreg:SI (reg:BI 62) 0)
(const_int 31 [0x1f]))) "test.c":4 -1
(nil))
(insn 9 8 10 (set (reg:SI 61)
(ashiftrt:SI (reg:SI 61)
(const_int 31 [0x1f]))) "test.c":4 -1
(nil))
(insn 10 9 11 (set (reg:SI 57 [ ])
(reg:SI 61)) "test.c":4 -1
(nil))
...
before ICE-ing in vregs because insn 7 does not match any insn.
Note that we sign-extend the BImode result of insn 7, using insn 8 and 9.
The sign-extend is generated here in emit_cstore:
...
/* If we are converting to a wider mode, first convert to
INT_TARGET_MODE, then normalize. This produces better combining
opportunities on machines that have a SIGN_EXTRACT when we are
testing a single bit. This mostly benefits the 68k.
If STORE_FLAG_VALUE does not have the sign bit set when
interpreted in MODE, we can do this conversion as unsigned, which
is usually more efficient. */
if (GET_MODE_SIZE (int_target_mode) > GET_MODE_SIZE (result_mode))
{
convert_move (target, subtarget,
val_signbit_known_clear_p (result_mode,
STORE_FLAG_VALUE));
op0 = target;
result_mode = int_target_mode;
}
...
We call
val_signbit_known_clear_p (mode == BImode, val == 1)
which returns false, so then we call
convert_move (to == reg:SI 61, from == reg:BI 62, unsignedp == false)
which generates the sign-extend because unsignedp == false.
Disregarding other STORE_FLAG_VALUES for the moment, the idea of the code is to
sign-extend if STORE_FLAG_VALUE is -1, and to zero-extend if STORE_FLAG_VALUE
is 1.
However, 1 and -1 are indistinguishable in BImode, so this happens to go the
sign-extend way. [ The comment mentions 68k, which has STORE_FLAG_VALUE -1, so
that might be reason it choose the sign-extend in this case. ]
[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089 --- Comment #1 from Tom de Vries --- Created attachment 42108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42108&action=edit minimal patch This patch addresses the issue in a point-fix manner. With this patch, we generate instead: ... (insn 7 6 8 (set (reg:BI 62) (ne:BI (reg/v:SI 58 [ aD.1438 ]) (reg/v:SI 59 [ bD.1439 ]))) "test.c":4 -1 (nil)) (insn 8 7 9 (set (reg:SI 61) (zero_extend:SI (reg:BI 62))) "test.c":4 -1 (nil)) (insn 9 8 10 (set (reg:SI 57 [ ]) (reg:SI 61)) "test.c":4 -1 (nil)) ...
[Bug c/82088] Implicit conversion "const char *x=" to "const char x[sizeof(...)]="
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82088 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- Because the types are not compatible.
[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-03 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (8.0). The test works if I remove the count in '170902a.txt': &n ta(1:8)%c = 'bogus' /
[Bug libfortran/81937] stack-buffer-overflow on memcpy in libgfortran/io/unix.c on character(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81937 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-03 CC||jvdelisle at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed with 7.2.0 and trunk (8.0).
[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089 --- Comment #2 from Tom de Vries --- I do wonder though about val_signbit_known_clear_p (and friends): ... /* Test whether the most significant bit of mode MODE is clear in VAL. Returns false if the precision of MODE is too large to handle. */ bool val_signbit_known_clear_p (machine_mode mode, unsigned HOST_WIDE_INT val) ... Returning false for mode == BImode and val == 1 corresponds to the comment: the msb is set, so it's not known to be clear. It's just confusing that the msb is also the lsb. But the fact that we're using 'signbit' in the name suggests that we're interpreting the value as 1-bit signed, which is rather exceptional. We could handle BImode conservatively in these functions, by always returning false. Note that this does not fix the original problem. Likewise, it might silently introduce wrong-code bugs. So we might wanna assert in these functions that mode != BImode, and handle the triggers.
[Bug fortran/82065] gfortran rejects redundant use of intrinsic module constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82065 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-09-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on x86_64-apple-darwin16 from 4.8 up to trunk (8.0). Note that the error is given by the as. Is it the case on linux?
[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Say that in bfin.md, we redefine cstoresi4 in the following way:
> ...
> (define_expand "cstoresi4"
> [(set (match_operand:BI 0 "")
> (match_operator:BI 1 "ordered_comparison_operator"
>[(match_operand:SI 2 "register_operand" "")
> (match_operand:SI 3 "reg_or_const_int_operand" "")]))]
> "" {})
> ...
>
Written to make it easy to reproduce this wrong-code bug encountered for target
gcn on branch gcn for this insn from gcn.md:
...
(define_insn "cstoresi4"
[(set (match_operand:BI 0 "gcn_conditional_register_operand" "=cs,cs,cs,cs")
(match_operator:BI 1 "gcn_compare_operator"
[(match_operand:SI 2 "gcn_alu_operand" "SSA,SSA,SSB,SS")
(match_operand:SI 3 "gcn_alu_operand" "SSA,SSK,SS ,SSB")]))]
""
"@
s_cmp%D1\t%2, %3
s_cmpk%D1\t%2, %3
s_cmp%D1\t%2, %3
s_cmp%D1\t%2, %3"
[(set_attr "type" "sopc,sopk,sopk,sopk")
(set_attr "mode" "SI")])
...
[Bug fortran/82064] [7/8 Regression] [OOP] multiple incompatible definitions of extended derived type via module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid |wrong-code CC||pault at gcc dot gnu.org Target Milestone|--- |7.3 --- Comment #3 from janus at gcc dot gnu.org --- It appears that the regression has been introduced by r241450, which was the fix for PR 69834. Reverting it, in particular the changes to resolve_select_type, makes the error go away.
[Bug rtl-optimization/66087] Invalid narrowing of MEM with containing POST_INC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66087 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- Still miscompiled by gcc-8.0, 7.2, and 6.4.
[Bug fortran/81735] [5/6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.9.3 Keywords||wrong-code Last reconfirmed||2017-09-03 CC||pault at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 Summary|double free or corruption |[5/6/7/8 Regression] double |(fasttop) error (SIGABRT) |free or corruption |with character(:) and |(fasttop) error (SIGABRT) |custom return type with |with character(:) and |allocatable |custom return type with ||allocatable --- Comment #3 from Dominique d'Humieres --- Confirmed from 5.4 up to trunk. The change occurred between revisions r232451 + 1 patch (2016-01-15, OK) and r233563 + 2 patches (2016-02-19, pointer being freed was not allocated). AFAICT one of the patch is for pr69423 (r233589) and the second for pr67451 (r233625), but I cannot see why it can cause the problem.
[Bug bootstrap/82087] HEAD fails to bootstrap on x86_64-apple-darwin16.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82087 --- Comment #1 from d25fe0be@ --- Sorry, the command invoked was missing: ``` clang++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I/usr/local/opt/gmp/include -I/usr/local/opt/mpfr/include -I/usr/local/opt/libmpc/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -I/usr/local/opt/isl/include -o builtins.o -MT builtins.o -MMD -MP -MF ./.deps/builtins.TPo ../../gcc/builtins.c ```
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #14 from Romain Bossart --- Thank you Jack, gcc-7.2.0 now compiles correctly on my i7 system (8 cores HT) with encrypted APFS Best regards
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #15 from Jack Howarth --- Maybe I'm just thick, but from the generated x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely unclear to me how the stamp mechanism and the current install-headers insures that install-headers has completed in its entirety. The way I read the current Makefile is that it is merely checking for the existence of the include subdirectories having been installed and not that that they have been completely populated. Looks like a broken implementation of stamps to me.
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #16 from Jack Howarth --- The component on this bug should probably be switched back off of 'target' to 'libstdc++' as the broken stamps implementation is likely just latent on other targets because none of them have filesystems with the fine time granularity of APFS yet,
[Bug bootstrap/82087] HEAD fails to bootstrap on x86_64-apple-darwin16.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82087 --- Comment #2 from d25fe0be@ --- After suppressing Clang's error about passing POD through varargs, bootstrapping r251624 now fails with: ``` libtool: compile: /private/tmp/gcc-20170903-13173-cfn0kc/build/./gcc/xgcc -B/private/tmp/gcc-20170903-13173-cfn0kc/build/./gcc/ -B/usr/local/Cellar/gcc/HEAD-251624/x86_64-apple-darwin16.7.0/bin/ -B/usr/local/Cellar/gcc/HEAD-251624/x86_64-apple-darwin16.7.0/lib/ -isystem /usr/local/Cellar/gcc/HEAD-251624/x86_64-apple-darwin16.7.0/include -isystem /usr/local/Cellar/gcc/HEAD-251624/x86_64-apple-darwin16.7.0/sys-include -DHAVE_CONFIG_H -I. -I../../../../libgomp -I../../../../libgomp/config/bsd -I../../../../libgomp/config/darwin -I../../../../libgomp/config/posix -I../../../../libgomp -I../../../../libgomp/../include -Wall -pthread -Werror -g -O2 -m32 -MT iter_ull.lo -MD -MP -MF .deps/iter_ull.Tpo -c ../../../../libgomp/iter_ull.c -fno-common -DPIC -o .libs/iter_ull.o during RTL pass: expand ../../../../libgomp/iter_ull.c: In function 'gomp_iter_ull_static_next': ../../../../libgomp/iter_ull.c:40:1: internal compiler error: Illegal instruction: 4 gomp_iter_ull_static_next (gomp_ull *pstart, gomp_ull *pend) ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://github.com/Homebrew/homebrew-core/issues> for instructions. make[9]: *** [iter_ull.lo] Error 1 make[8]: *** [all-recursive] Error 1 make[7]: *** [all] Error 2 make[6]: *** [multi-do] Error 1 make[5]: *** [all-multi] Error 2 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libgomp] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 ``` And I have no idea about what's going on here this time..
[Bug c/82090] New: Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
Bug ID: 82090
Summary: Bogus warning: ‘magic_p’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-efi-2 tmp]$ cat foo.c
typedef int __libc_lock_t;
void malloc_printerr(const char *str) __attribute__ ((noreturn));
extern __libc_lock_t foo;
static void *
mem2chunk_check (void *mem, unsigned char **magic_p)
{
if (!mem)
return (( void *)0) ;
if (magic_p)
*magic_p = (unsigned char *) mem;
return mem;
}
void *
realloc_check (void *oldmem, unsigned int bytes, const void *caller)
{
unsigned char *magic_p;
void * oldp = mem2chunk_check (oldmem, &magic_p);
(void) ({ int ignore; if (__builtin_constant_p (0) && (0) == 0) __asm
__volatile ("cmpl $0, __libc_multiple_threads(%%rip)\n\t" "je 0f\n\t" "lock;
decl %0\n\t" "jne 1f\n\t" "jmp 24f\n\t" "0:\tdecl %0\n\t" "je 24f\n\t" "1:\tlea
%0, %%" "rdi" "\n" "2:\tsub $128, %%" "rsp" "\n" ".cfi_adjust_cfa_offset 128\n"
"3:\tcallq __lll_unlock_wake_private\n" "4:\tadd $128, %%" "rsp" "\n"
".cfi_adjust_cfa_offset -128\n" "24:" : "=m" (foo), "=&D" (ignore) : "m" (foo)
: "ax", "cx", "r11", "cc", "memory"); else __asm __volatile ("cmpl $0,
__libc_multiple_threads(%%rip)\n\t" "je 0f\n\t" "lock; decl %0\n\t" "jne
1f\n\t" "jmp 24f\n\t" "0:\tdecl %0\n\t" "je 24f\n\t" "1:\tlea %0, %%" "rdi"
"\n" "2:\tsub $128, %%" "rsp" "\n" ".cfi_adjust_cfa_offset 128\n" "3:\tcallq
__lll_unlock_wake\n" "4:\tadd $128, %%" "rsp" "\n" ".cfi_adjust_cfa_offset
-128\n" "24:" : "=m" (foo), "=&D" (ignore) : "m" (foo), "S" (0) : "ax", "cx",
"r11", "cc", "memory"); });
if (!oldp)
malloc_printerr ("realloc(): invalid pointer");
*magic_p ^= 0xFF;
return oldp;
}
[hjl@gnu-efi-2 tmp]$ gcc -Wall foo.c -S -O3
foo.c: In function ‘realloc_check’:
foo.c:25:12: warning: ‘magic_p’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
*magic_p ^= 0xFF;
~^~~
[hjl@gnu-efi-2 tmp]$
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #11 from Dominique d'Humieres --- > Where is > > and$0xfff0,%rsp I cannot find it!-( > my patch added? Yes.
[Bug fortran/81735] [5/6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 Dominique d'Humieres changed: What|Removed |Added Blocks||68241 --- Comment #4 from Dominique d'Humieres --- I still see "pointer being freed was not allocated" with r233625 reverted. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] [F03] Deferred-length character
[Bug bootstrap/82091] New: [5] Build failure on macOS 10.13 with Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091 Bug ID: 82091 Summary: [5] Build failure on macOS 10.13 with Xcode 9 Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- gcc 5.4.0 fails to build on macOS 10.13 with Xcode 9 with the following error: clang++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I/usr/local/opt/gmp/include -I/usr/local/opt/mpfr/include -I/usr/local/opt/libmpc/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -I/usr/local/opt/isl@0.14/include -o auto-profile.o -MT auto-profile.o -MMD -MP -MF ./.deps/auto-profile.TPo ../../gcc/auto-profile.c In file included from ../../gcc/auto-profile.c:25: In file included from /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/map:446: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ ../../gcc/system.h:700:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ Full logs can be found here: https://gist.github.com/anonymous/914e45c380ec81a524394098db4b5a64 The problem is that is included (via ) after abort has been defined as a macro to fancy_abort. And thus when the C++ standard headers try to call std::abort, they end up calling std::fancy_abort, which of course doesn't exist. A simple fix is to include in gcc/config.h before we mess with abort. Patch: https://raw.githubusercontent.com/Homebrew/formula-patches/078797f1/gcc%405/xcode9.patch
[Bug bootstrap/82091] [5 only] Build failure on macOS 10.13 with Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5 Summary|[5] Build failure on macOS |[5 only] Build failure on |10.13 with Xcode 9 |macOS 10.13 with Xcode 9 --- Comment #1 from Andrew Pinski --- IIRC this has been patched in GCC 7 (maybe GCC 6 also).
[Bug bootstrap/82091] [5 only] Build failure on macOS 10.13 with Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091 --- Comment #2 from Francois-Xavier Coudert --- Yes, on 6 and 7 the headers are included early, as my patch is doing here.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 H.J. Lu changed: What|Removed |Added Attachment #41917|0 |1 is obsolete|| --- Comment #12 from H.J. Lu --- Created attachment 42109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42109&action=edit An updated patch
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #13 from H.J. Lu --- (In reply to Dominique d'Humieres from comment #11) > > Where is > > > > and$0xfff0,%rsp > > I cannot find it!-( > > > my patch added? > > Yes. Please try my new patch.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #14 from Dominique d'Humieres --- > Please try my new patch. AFAICT it is not different from the one I have already applied (why the duplications?).
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 H.J. Lu changed: What|Removed |Added Attachment #42109|0 |1 is obsolete|| --- Comment #15 from H.J. Lu --- Created attachment 42110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42110&action=edit A new patch
[Bug bootstrap/82091] [5 only] Build failure on macOS 10.13 with Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091 Jack Howarth changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #3 from Jack Howarth --- Isn't this due to gcc-5-branch missing the proposed back port of... https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00476.html https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html Iain Sandoe said he could only approve the objc bits and was waiting for the appropriate maintainers to approve the rest of the patch before it could be applied to gcc-5-branch.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #16 from H.J. Lu --- (In reply to Dominique d'Humieres from comment #14) > > Please try my new patch. > > AFAICT it is not different from the one I have already applied (why the > duplications?). I updated it again. If it still doesn't work, please show me what you applied.
[Bug fortran/81735] [5/6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 --- Comment #5 from Dominique d'Humieres --- > I still see "pointer being freed was not allocated" with r233625 reverted. But it is gone if I revert r233589.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #17 from Dominique d'Humieres ---
> I updated it again. If it still doesn't work, please show me what
> you applied.
The test now pass in 64 bit mode, but not in 32 bit one:
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
% ./a.out
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
-m32
% ./a.out
Segmentation fault
Note that the guality tests are not run on darwin.
Patched with
--- ../_clean/gcc/testsuite/gcc.dg/torture/pr25967-1.c 2017-08-02
13:33:42.0 +0200
+++ gcc/testsuite/gcc.dg/torture/pr25967-1.c2017-09-03 20:28:09.0
+0200
@@ -17,6 +17,12 @@ typedef unsigned int uword_t __attribute
#define ASMNAME(cname) ASMNAME2 (__USER_LABEL_PREFIX__, cname)
#define ASMNAME2(prefix, cname) XSTRING (prefix) cname
+#if __LP64__
+# define STACK_POINTER "rsp"
+#else
+# define STACK_POINTER "esp"
+#endif
+
struct interrupt_frame
{
uword_t ip;
@@ -52,7 +58,9 @@ fn (void)
int
main ()
{
- asm ("push $" STRING (SS) "; \
+ /* Align exception handler stack to 16 bytes. */
+ asm ("and$-16, %" STACK_POINTER "; \
+push $" STRING (SS) "; \
push$" STRING (SP) "; \
push$" STRING (FLAGS) ";\
push$" STRING (CS) "; \
[Bug fortran/82065] gfortran rejects redundant use of intrinsic module constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82065 --- Comment #2 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #1) > Confirmed on x86_64-apple-darwin16 from 4.8 up to trunk (8.0). Note that the > error is given by the as. Is it the case on linux? Yes. Note that the error goes away when any of the print statements is commented out.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #18 from H.J. Lu --- (In reply to Dominique d'Humieres from comment #17) > > I updated it again. If it still doesn't work, please show me what > > you applied. > > The test now pass in 64 bit mode, but not in 32 bit one: > > % /opt/gcc/gcc8w/bin/gcc > /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c > % ./a.out > % /opt/gcc/gcc8w/bin/gcc > /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c -m32 > % ./a.out > Segmentation fault > Do you know why it fails in 32-bit mode?
[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf --- With gfortran 4.6 I get: At line 10 of file pr82086.f90 (unit = 1, file = '170902a.txt') Fortran runtime error: Repeat count too large for namelist object ta%c
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #19 from Dominique d'Humieres --- > Do you know why it fails in 32-bit mode? Nope! Are you sure that %esp is the stack in 32 bit mode?
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693 --- Comment #20 from H.J. Lu --- (In reply to Dominique d'Humieres from comment #19) > > Do you know why it fails in 32-bit mode? > > Nope! Are you sure that %esp is the stack in 32 bit mode? Yes, %esp is correct for 32-bit mode. Please compile gcc.dg/torture/pr25967-1.c with -g and run it under debugger.
[Bug c++/82092] New: gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Bug ID: 82092 Summary: gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1]) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeremyhu at macports dot org Target Milestone: --- Snapshot 8-20170604 (trunk r248863) builds fine on darwin. Snapshot 8-20170611 (trunk r249106) and later (through at least 8-20170827, r251369) fail to build on darwin. The build fails with the linker failing an assert due to invalid output produced by the compiler when building genmodes: make[3]: Entering directory `/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/gcc' /opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/xg++ -B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/ -B/opt/local/x86_64-apple-darwin17/bin/ -nostdinc++ -B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs -B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs -isystem /opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include/x86_64-apple-darwin17 -isystem /opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include -isystem /opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/gcc-8-20170827/libstdc++-v3/libsupc++ -L/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-no_pie -o build/genmodes \ build/genmodes.o build/errors.o .././libiberty/libiberty.a 0 0x101edfb1b __assert_rtn + 129 1 0x101ef323a mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 3030 2 0x101eeabcc mach_o::relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 282 3 0x101f2fae4 ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 830 4 0x101f3246d ld::tool::InputFiles::parseWorkerThread() + 497 5 0x7fff7ec806c1 _pthread_body + 340 6 0x7fff7ec8056d _pthread_body + 0 A linker snapshot was created at: /tmp/genmodes-2017-08-03-125525.ld-snapshot ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-302.4/src/ld/parsers/macho_relocatable_file.cpp, line 1898. collect2: error: ld returned 1 exit status This happens with all versions of macOS that I’ve tried (El Capitan through High Sierra). See also bug #57438
[Bug testsuite/82093] New: gfortran.dg/vect/pr70043.f90 contains out-of-bounds references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82093 Bug ID: 82093 Summary: gfortran.dg/vect/pr70043.f90 contains out-of-bounds references Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The test case contains out-of-bounds references to a(i) and b(i): subroutine fn1(a, b) real(8), intent(in) :: b(100) real(8), intent(inout) :: a(100) real(8) c do i=0,100 if( a(i) < 0.0 ) then c = a(i) * b(i) a(i) = a(i) - c / b(i) endif enddo end subroutine fn1 Are these necessary for the test, or can they just be fixed?
[Bug c++/81942] ICE on empty constexpr constructor with C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot com| --- Comment #13 from Paolo Carlini --- Patch passed testing on both x86_64-linux and aarch64-linux. I'll probably send it to the mailing list with minimal modifications.
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #21 from Dominique d'Humieres ---
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
-m32 -g
% lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (i386).
(lldb) run
Process 25578 launched:
'/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out' (i386)
Process 25578 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
frame #0: 0xa152b200 libdyld.dylib`misaligned_stack_error_
libdyld.dylib`misaligned_stack_error_:
-> 0xa152b200 <+0>: movdqa %xmm0, 0x10(%esp)
0xa152b206 <+6>: movdqa %xmm1, 0x20(%esp)
0xa152b20c <+12>: movdqa %xmm2, 0x30(%esp)
0xa152b212 <+18>: movdqa %xmm3, 0x40(%esp)
(lldb) b main
Breakpoint 1: where = a.out`main + 5 at pr25967-1.c:62, address = 0x1f44
(lldb) run
There is a running process, kill it and restart?: [Y/n] y
Process 25578 exited with status = 9 (0x0009)
Process 25583 launched:
'/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out' (i386)
Process 25583 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x1f44 a.out`main at pr25967-1.c:62
59 main ()
60 {
61 /* Align exception handler stack to 16 bytes. */
-> 62 asm ("and $-16, %" STACK_POINTER "; \
63 push$" STRING (SS) "; \
64 push$" STRING (SP) "; \
65 push$" STRING (FLAGS) ";\
(lldb) disass -a 0x1f44
a.out`main:
0x1f3f <+0>: calll 0x1f70; __x86.get_pc_thunk.ax
-> 0x1f44 <+5>: andl $-0x10, %esp
0x1f47 <+8>: pushl $0x12345675 ; imm = 0x12345675
0x1f4c <+13>: pushl $0x12345674 ; imm = 0x12345674
0x1f51 <+18>: pushl $0x12345673 ; imm = 0x12345673
0x1f56 <+23>: pushl $0x12345672 ; imm = 0x12345672
0x1f5b <+28>: pushl $0x12345671 ; imm = 0x12345671
0x1f60 <+33>: pushl $0x12345670 ; imm = 0x12345670
0x1f65 <+38>: jmp0x1ed0; fn at pr25967-1.c:38
0x1f6a <+43>: movl $0x0, %eax
0x1f6f <+48>: retl
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
-g
% lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) run
Process 25632 launched: './a.out' (x86_64)
Process 25632 exited with status = 0 (0x)
(lldb) b main
Breakpoint 1: where = a.out`main at pr25967-1.c:62, address =
0x00010f4b
(lldb) run
Process 25636 launched: './a.out' (x86_64)
Process 25636 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f4b a.out`main at pr25967-1.c:62
59 main ()
60 {
61 /* Align exception handler stack to 16 bytes. */
-> 62 asm ("and $-16, %" STACK_POINTER "; \
63 push$" STRING (SS) "; \
64 push$" STRING (SP) "; \
65 push$" STRING (FLAGS) ";\
(lldb) disass -a 0x00010f4b
a.out`main:
-> 0x10f4b <+0>: andq $-0x10, %rsp
0x10f4f <+4>: pushq $0x12345675 ; imm = 0x12345675
0x10f54 <+9>: pushq $0x12345674 ; imm = 0x12345674
0x10f59 <+14>: pushq $0x12345673 ; imm = 0x12345673
0x10f5e <+19>: pushq $0x12345672 ; imm = 0x12345672
0x10f63 <+24>: pushq $0x12345671 ; imm = 0x12345671
0x10f68 <+29>: pushq $0x12345670 ; imm = 0x12345670
0x10f6d <+34>: jmp0x10ed2 ; fn at pr25967-1.c:40
0x10f72 <+39>: movl $0x0, %eax
0x10f77 <+44>: retq
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #22 from Dominique d'Humieres ---
The test succeeds with -m32 (but fails with -m64) with the following change
+ /* Align exception handler stack to 16 bytes. */
+ asm ("and$-8, %" STACK_POINTER ";\
+push $" STRING (SS) "; \
[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #23 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #22)
> The test succeeds with -m32 (but fails with -m64) with the following change
>
> + /* Align exception handler stack to 16 bytes. */
> + asm ("and $-8, %" STACK_POINTER ";\
> +push $" STRING (SS) "; \
That is expected. Does gcc.dg/torture/pr25967-2.c pass for both
-m32 and -m64?
[Bug c/82094] New: error: inlining failed in call to always_inline ‘_mm512_permutexvar_epi8’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82094 Bug ID: 82094 Summary: error: inlining failed in call to always_inline ‘_mm512_permutexvar_epi8’ Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vasistavinay at gmail dot com Target Milestone: --- Created attachment 42111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42111&action=edit Permutation of uchar elements in an AVX-512 vector I get the following error, when I compile the attached source with the given command - $ gcc -march=skylake-avx512 -mavx512f test_avx512_permute.c In file included from /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/immintrin.h:67:0, from test_avx512_permute.c:4: test_avx512_permute.c: In function ‘main’: /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/avx512vbmiintrin.h:71:1: error: inlining failed in call to always_inline ‘_mm512_permutexvar_epi8’: target specific option mismatch _mm512_permutexvar_epi8 (__m512i __A, __m512i __B) ^~~ test_avx512_permute.c:13:7: note: called from here c = _mm512_permutexvar_epi8(a, b); ~~^~~ In file included from /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/immintrin.h:67:0, from test_avx512_permute.c:4: /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/avx512vbmiintrin.h:71:1: error: inlining failed in call to always_inline ‘_mm512_permutexvar_epi8’: target specific option mismatch _mm512_permutexvar_epi8 (__m512i __A, __m512i __B) ^~~ test_avx512_permute.c:13:7: note: called from here c = _mm512_permutexvar_epi8(a, b); ~~^~~ _ And strangely, if I comment out the epi8 set intrinsics (lines 12 and 13), and do just the permutation without initializing vectors a and b, the following error occurs for the same command string - $ gcc -march=skylake-avx512 -mavx512f test_avx512_permute.c In file included from /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/immintrin.h:67:0, from test_avx512_permute.c:5: test_avx512_permute.c: In function ‘main’: /in/gcc/7.1.0/Linux5/x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/avx512vbmiintrin.h:71:1: error: inlining failed in call to always_inline ‘_mm512_permutexvar_epi8’: target specific option mismatch _mm512_permutexvar_epi8 (__m512i __A, __m512i __B) ^~~ test_avx512_permute.c:16:7: note: called from here c = _mm512_permutexvar_epi8(a, b); ~~^~~ _ (In other words, the same error is duplicated in the first case) Please help me understand if there is anything wrong in my program. P.S: I'm cross-compiling the code since I don't have the access to a skylake machine yet. Thanks and Regards, ~ Vinay
