[Bug target/88189] New: ix86_expand_sse_movcc and blend for scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88189
Bug ID: 88189
Summary: ix86_expand_sse_movcc and blend for scalars
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
double f(double a,double b){
return (a<0)?a:b;
}
typedef double vec __attribute__((vector_size(16)));
vec g(vec a,vec b){
return (a<0)?a:b;
}
I am compiling with -O3, and the most interesting pass is ce1 with
noce_try_cmove. Using -msse2, both functions generate similar code
andpd %xmm2, %xmm0
andnpd %xmm1, %xmm2
orpd%xmm2, %xmm0
With -mxop they also generate similar code
vpcmov %xmm2, %xmm1, %xmm0, %xmm0
However, with -msse4, they differ, the vector version gets
blendvpd%xmm0, %xmm2, %xmm1
while the scalar version is stuck with the SSE2 and+andn+or. Is there a
particular reason for this inconsistency?
[Bug target/88188] New: ICE in print_operand, at config/rs6000/rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88188 Bug ID: 88188 Summary: ICE in print_operand, at config/rs6000/rs6000.c Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu rs6000 and powerpcspe backends ICE processing some kinds of invalid assembly. Namely, they hit gcc_unreachable() or gcc_assert() compiling gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c, gcc/testsuite/gcc.target/cris/20011127-1.c, and gcc/testsuite/gcc.target/msp430/msp_abi_div_funcs.c: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -c gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c during RTL pass: final gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c: In function 'foo': gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c:10:1: internal compiler error: in print_operand, at config/rs6000/rs6000.c:20992 10 | } | ^ 0x6da7e3 print_operand(_IO_FILE*, rtx_def*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/config/rs6000/rs6000.c:20992 0x9eb84f output_operand(rtx_def*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:4042 0x9ec4d6 output_asm_insn(char const*, rtx_def**) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:3935 0x9ee6a6 final_scan_insn_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:2712 0x9ee998 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:3149 0x9eecae final_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:2019 0x9ef838 rest_of_handle_final /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:4649 0x9ef838 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:4723 (for cris test it ICEs on line 21062 and for msp430 on line 20647 instead).
[Bug bootstrap/88157] [9 Regression] ICE when building libgo encoding/gob.lo starting with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157 --- Comment #8 from Vladimir Makarov --- Author: vmakarov Date: Sun Nov 25 05:46:44 2018 New Revision: 266435 URL: https://gcc.gnu.org/viewcvs?rev=266435=gcc=rev Log: 2018-11-25 Vladimir Makarov PR bootstrap/88157 * ira-costs.c (record_operand_costs): Initiate register move cost for mode. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug libstdc++/70694] 50 experimental/filesystem/* failures on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70694 --- Comment #9 from Eric Gallager --- (In reply to Iain Sandoe from comment #8) > Author: iains > Date: Sat Aug 25 09:02:28 2018 > New Revision: 263850 > > URL: https://gcc.gnu.org/viewcvs?rev=263850=gcc=rev > Log: > Don't force visibility to hidden for Darwin > 8. > > PR libstdc++/70694 > * configure.host (OPT_LDFLAGS): Don't append > -fvisibility-inlines-hidden for newer Darwin. > > > > Modified: > trunk/libstdc++-v3/ChangeLog > trunk/libstdc++-v3/configure.host Can this bug be closed now?
[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #14 from nightstrike --- FWIW, I get this on 8.2 on Linux.
[Bug c++/88187] New: ICE on (invalid) C++ code when compiled with -std=c++17: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88187 Bug ID: 88187 Summary: ICE on (invalid) C++ code when compiled with -std=c++17: Segmentation fault Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- This appears to be a recent regression. $ g++tk -v Using built-in specs. COLLECT_GCC=g++tk COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap Thread model: posix gcc version 9.0.0 20181124 (experimental) [trunk revision 266429] (GCC) $ $ g++tk -std=c++11 tmp.cpp tmp.cpp:3:9: error: variable or field ‘f’ declared void 3 | void f (A ()); | ^ tmp.cpp:3:11: error: missing template arguments before ‘(’ token 3 | void f (A ()); | ^ $ $ g++tk -std=c++17 tmp.cpp tmp.cpp:3:12: internal compiler error: Segmentation fault 3 | void f (A ()); |^ 0xfd219f crash_signal ../../gcc-source-trunk/gcc/toplev.c:326 0x9354a2 dguide_name_p(tree_node*) ../../gcc-source-trunk/gcc/cp/pt.c:26623 0x856d3d grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) ../../gcc-source-trunk/gcc/cp/decl.c:11281 0x917e0b cp_parser_parameter_declaration_list ../../gcc-source-trunk/gcc/cp/parser.c:21813 0x91850f cp_parser_parameter_declaration_clause ../../gcc-source-trunk/gcc/cp/parser.c:21728 0x90761d cp_parser_direct_declarator ../../gcc-source-trunk/gcc/cp/parser.c:20494 0x90761d cp_parser_declarator ../../gcc-source-trunk/gcc/cp/parser.c:20368 0x919911 cp_parser_init_declarator ../../gcc-source-trunk/gcc/cp/parser.c:19885 0x91a9c6 cp_parser_simple_declaration ../../gcc-source-trunk/gcc/cp/parser.c:13398 0x923b90 cp_parser_declaration ../../gcc-source-trunk/gcc/cp/parser.c:13087 0x922b05 cp_parser_translation_unit ../../gcc-source-trunk/gcc/cp/parser.c:4674 0x922b05 c_parse_file() ../../gcc-source-trunk/gcc/cp/parser.c:40680 0xa7e34a c_common_parse_file() ../../gcc-source-trunk/gcc/c-family/c-opts.c:1151 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ - template < int > struct A; void f (A ());
[Bug other/88141] Issues with texinfo when building GCC r266351 in MSYS2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88141 --- Comment #5 from Joshua Morrison --- It seems as though I misconfigured the repository when I pulled it via Git. The line endings were being switched to CRLF instead of just LF, and that in turn caused makeinfo to give the errors I was getting during the build. Sorry about that, it was just a mistake on my part when pulling the repo.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #11 from kargl at gcc dot gnu.org --- (In reply to Neil Carlson from comment #9) > Actually I think the usage in comment 8 is an intentional extension. There > is a test in the dg test suite that does exactly this if I remember > correctly. The test was namelist_use.f90. I was told that gfortran will give > an error if compiled with something like -std=f95. See > https://github.com/nncarlson/gfortran.dg/issues/3 Yep. Just found the code in gfc_match_namelist.c that indeed accepts the code (-std=gnu is the default standard) in comment 8. A quick test with -std=f2003 gives gfcx -o z -std=f2003 a.f90 && ./z a.f90:11:17: 11 |namelist /foo/ i | 1 Error: GNU Extension: Namelist group name 'foo' at (1) already is USE associated and cannot be respecified. So, AFAICT, the patch in comment 7 fixes the issue.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #10 from Neil Carlson --- Also a remark about the output of comment 7 just in case someone is thinking it ought to say "" (like I was expecting/hoping when I started experimenting with the original example). 13.11.3.1 says 1 Input for a namelist input statement consists of (2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST statement, and 13.11.4.1 says 1 The form of the output produced by intrinsic namelist output shall be suitable for input, [...] So "" is correct (and what Intel and NAG both do as well).
[Bug tree-optimization/88186] New: GCC Fails to optimize arithmetic progression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88186 Bug ID: 88186 Summary: GCC Fails to optimize arithmetic progression Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: giuliano.belinassi at usp dot br Target Milestone: --- Created attachment 45087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45087=edit Somewhat a test case. GCC fails to optimize simple arithmetic progressions. See attached code. gcc -Ofast -o induction induction_test.c ./induction 1 Sum is 0, elapsed time: 0 Sum is 0, elapsed time: 0 ./induction 6 Sum is 179997, elapsed time: 203883 Sum is 179997, elapsed time: 0 It takes O(n), but the expected time would be O(1) after the optimization.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #9 from Neil Carlson --- Actually I think the usage in comment 8 is an intentional extension. There is a test in the dg test suite that does exactly this if I remember correctly. The test was namelist_use.f90. I was told that gfortran will give an error if compiled with something like -std=f95. See https://github.com/nncarlson/gfortran.dg/issues/3
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #8 from kargl at gcc dot gnu.org --- As expected, the following invalid code via C8102 in F2018 compiles and executes module foo_nml implicit none real :: x namelist /foo/ x end module program main use foo_nml implicit none integer i namelist /foo/ i ! Invalid via F18:C8102 i = 42 x = 42 write(*,nml=foo) end program % gfcx -o z a.f90 && ./z X= 42.000, I=42 , /
[Bug target/85644] [8 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644 --- Comment #8 from Mark Harris --- Thanks for fixing this. I can confirm that with gcc trunk, -fstack-protector, -fstack-protector-all, and -fstack-protector-strong are now working for me on macOS 10.12.6, for both -m64 and -m32.
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on 7-9 branches. Thanks for the report Paul
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> (In reply to Neil Carlson from comment #5)
> > Stated a bit more clearly, the question is, whether in
> >
> > The namelist-group-name shall not be a name accessed by use association.
> >
> > the name (in the scope of the declaration) is accessed by use association,
> > or the name is accessed in another scope by use association.
>
> I've asked on the J3 mailing list for clairfication. 14.2.2
> say ", identifiers, and namelist groups in a module." Namelist
> groups is a bit vague, here. Does this mean namelist group names
> or namelist group objects. My current thinking is C8102 is to
> prevent
>
> module foo
>
> namelist /bar/ ...
> end module
>
> program bah
> use foo
> real x
> namelist /bar/x
> ...
> end program bah
>
> where program bar is trying to extend the namelist-group-object-list.
So, I've asked on J3 mailing list (and after a rather condescending reply),
it is definitely a bug in gfortran. Constraint c8102 from F2018 applies
to a namelist-group-name in the scoping unit that USEs the module. Thus,
in the above code, using 'bar' in program 'bah' as a namelist-group-name is
invalid as 'bar' has been made available via USE association.
This patch allows a slightly modify version of Neil's code to compile and
run (x in main is implicitly defined local variable, which is different
than the x in module foo).
Index: module.c
===
--- module.c(revision 266386)
+++ module.c(working copy)
@@ -3711,7 +3711,6 @@ static void
mio_namelist (gfc_symbol *sym)
{
gfc_namelist *n, *m;
- const char *check_name;
mio_lparen ();
@@ -3722,17 +3721,6 @@ mio_namelist (gfc_symbol *sym)
}
else
{
- /* This departure from the standard is flagged as an error.
-It does, in fact, work correctly. TODO: Allow it
-conditionally? */
- if (sym->attr.flavor == FL_NAMELIST)
- {
- check_name = find_use_name (sym->name, false);
- if (check_name && strcmp (check_name, sym->name) != 0)
- gfc_error ("Namelist %s cannot be renamed by USE "
- "association to %s", sym->name, check_name);
- }
-
m = NULL;
while (peek_atom () != ATOM_RPAREN)
{
% cat a.f90
module foo_nml
implicit none
real :: x
namelist /foo/ x
end module
program main
use foo_nml, only: bar => foo, x
implicit none
x = 42
write(*,nml=bar)
end program
% gfcx -o z a.f90 && ./z
X= 42.000,
/
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #9 from Paul Thomas --- Author: pault Date: Sat Nov 24 18:54:52 2018 New Revision: 266431 URL: https://gcc.gnu.org/viewcvs?rev=266431=gcc=rev Log: 2018-11-24 Paul Thomas PR fortran/88143 * resolve.c (resolve_variable): Check for associate names with NULL target. 2018-11-24 Paul Thomas PR fortran/88143 * gfortran.dg/associate_46.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_46.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #8 from Paul Thomas --- Author: pault Date: Sat Nov 24 18:08:59 2018 New Revision: 266430 URL: https://gcc.gnu.org/viewcvs?rev=266430=gcc=rev Log: 2018-11-24 Paul Thomas PR fortran/88143 * resolve.c (resolve_variable): Check for associate names with NULL target. 2018-11-24 Paul Thomas PR fortran/88143 * gfortran.dg/associate_46.f90: New test. Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/87968] [7/8/9 Regression] Warning about uninizialized variables in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87968 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-24 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88154 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for 8.2.0 and trunk (9.0).
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073 --- Comment #14 from Jorn Wolfgang Rennecke --- (In reply to Jorn Wolfgang Rennecke from comment #12) > If we are right shifting a signed type, we could apply a MAX operation to the > shift count. Oops, I mean MIN of course. So that we can guarantee that the maximum applied shift count is one less than the bitsize of the shifted value.
[Bug lto/88185] New: LTO merges -fPIC/fpie and -fPIE/-fpie options to nothing - fails to warn when both are specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185 Bug ID: 88185 Summary: LTO merges -fPIC/fpie and -fPIE/-fpie options to nothing - fails to warn when both are specified Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu The systemd package fails to build on hppa-linux with gcc-8. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909396 The build fails when it tries to link a pie executable. It's main object was compiled with -fPIE. Several archive libraries are linked against the main object. These contain objects compiled with both the -fPIE and -fPIC options. Only the -fPIC option is recorded for LTO. In gcc-8, -fPIE + -fPIC are merged to nothing. So, the link fails when non position-independent object is generated for an LTO object. There is no warning about using -fPIE and -fPIC together. The documentation implies these options are not compatible. In the systemd build, the addition of these options is done by meson and it's not clear why both are added.
[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #8 from Jonny Grant --- Hi Jonathan Do you agree this warning output should be changed to clarify? I understand your reply about it being non-POD when a C++ STL string is added. Which adds the implicitly-defined copy constructor. Should it not say "implicitly-defined copy constructor for 'struct info'"? instead of "this function" ? Think also better for GCC to show the typedef 'info_t' - would you agree? GCC might be outputting a lot of unnecessary output... Jonny
[Bug bootstrap/88157] [9 Regression] ICE when building libgo encoding/gob.lo starting with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Bootstrap works now, thanks.
[Bug c++/88184] New: ICE on (invalid) C++ code when compiled with -std=c++2a: unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88184
Bug ID: 88184
Summary: ICE on (invalid) C++ code when compiled with
-std=c++2a: unexpected expression ‘f’ of kind
template_id_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It appears to be a recent regression.
$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20181124 (experimental) [trunk revision 266426] (GCC)
$
$ g++tk -std=c++17 -c tmp.cpp
tmp.cpp: In function ‘void g()’:
tmp.cpp:10:9: error: expected primary-expression before ‘>’ token
10 | f < T > ();
| ^
tmp.cpp:10:12: error: expected primary-expression before ‘)’ token
10 | f < T > ();
|^
$
$ g++tk -std=c++2a -c tmp.cpp
tmp.cpp: In function ‘void g()’:
tmp.cpp:10:12: internal compiler error: unexpected expression ‘f’ of kind
template_id_expr
10 | f < T > ();
|^
0x7f1508 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:4921
0x7f6c59 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:5033
0x7faa27 fold_non_dependent_expr(tree_node*, int)
../../gcc-source-trunk/gcc/cp/constexpr.c:5334
0x93473e build_non_dependent_expr(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:26299
0x9b88ea finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2434
0x90d2f3 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:7303
0x8f3e8f cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8382
0x8ed1bf cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9265
0x8ed84e cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9367
0x8ee133 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9663
0x8ee3d4 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9830
0x8f2ea4 cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:11365
0x900ea9 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:11161
0x90208f cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11508
0x90217f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:11462
0x90239b cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:22266
0x90239b cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:22301
0x902c42 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:27333
0x91a53a cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:27250
0x91a53a cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19995
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.
$
--
namespace A
{
void f ();
}
using A::f;
template < typename T > void g ()
{
f < T > ();
}
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING CC||hjl.tools at gmail dot com --- Comment #9 from H.J. Lu --- Please try binutils 2.31 branch. This may be: https://sourceware.org/bugzilla/show_bug.cgi?id=23465
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #16 from H.J. Lu --- (In reply to janus from comment #15) > (In reply to H.J. Lu from comment #14) > > Please try kernel 4.17.xx or above. > > Unfortunately I can not easily test a newer kernel on that hardware right > now :( Please try binutils 2.31 branch. This may be: https://sourceware.org/bugzilla/show_bug.cgi?id=23465
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=23465 Resolution|--- |MOVED --- Comment #29 from H.J. Lu --- This is a binutils bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23465
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
--- Comment #28 from Alexander Monakov ---
It seems like object file is not correctly assembled, note wrong offset to the
last instruction (movdqu):
.s:
vpgatherqd (%rax,%ymm3,4), %xmm4{%k4}
vpgatherqd (%rax,%ymm1,4), %xmm0{%k1}
vshufi32x4 $0, %ymm0, %ymm4, %ymm0
vmovdqu32 %ymm0, 32(,%rsi,4)
.o:
52a: 62 f2 7d 2c 91 24 98vpgatherqd (%rax,%ymm3,4),%xmm4{%k4}
531: 62 f2 7d 29 91 04 88vpgatherqd (%rax,%ymm1,4),%xmm0{%k1}
538: 62 f3 5d 28 43 c0 00vshufi32x4 $0x0,%ymm0,%ymm4,%ymm0
53f: 62 f1 7e 28 7f 04 b5vmovdqu32 %ymm0,0x1(,%rsi,4)
546: 01 00 00 00
On older Binutils I get vmovdqu32 %ymm0,0x20(,%rsi,4) as expected.
Probably relevant Binutils bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=23465
https://sourceware.org/bugzilla/show_bug.cgi?id=23314
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #27 from janus at gcc dot gnu.org --- Created attachment 45086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45086=edit object file
[Bug fortran/88043] Runtime Error when calling deferred member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88043 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-24 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed from 7.3.0 up to trunk (9.0). Before 2016-11-14 I get a segfault at runtime.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #12 from Eric Gallager --- (In reply to Jonathan Wakely from comment #11) > (In reply to felix from comment #7) > > I made the feature closely mimic The Other Compiler's behaviour: only > > function built-ins are recognised. This includes generic functions like > > __builtin_add_overflow and C library functions specially handled by the > > front-end like printf (unless -fno-builtin is used), but excludes types like > > __builtin_va_list and function-like constructs (implemented as keywords) > > like __builtin_offsetof and __builtin_types_compatible_p. This is not so > > much of a problem for them, since they also provide __has_feature(), > > __has_extension() and __is_identifier() macros. > > I hate that behaviour. Having to use !__is_identifier(__builtin_launder) is > confusing (and not just to me, but to developers of LLVM's own libc++, who > I've had to explain the problem to). > > But consistency with Clang is probably more important than making > __has_builtin behave sanely. maybe have a separate __sane_has_builtin? That way __has_builtin could still be compatible with clang, but there'd also be a sane alternative
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #26 from janus at gcc dot gnu.org --- (In reply to janus from comment #25) > Created attachment 45085 [details] > assembler output In fact this seems to be identical to Jakub's assembly (except for filenames and versions strings), but while it works for him, it fails for me.
[Bug fortran/88099] ICE in maybe_legitimize_operand, at optabs.c:7170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88099 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from at least 4.9. > so the FE creates invalid IL (from valid input?) Since n2 is not initialized, I think the code is invalid (but should not gives an ICE). Note that I still get the ICE if I compile the test with -finit-integer=4.
[Bug c++/88183] [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183 --- Comment #2 from Ruben Van Boxem --- Additionally I tested compiling the GCC7 preprocessed source with GCC 8.2.1, which expectedly leads to an ICE as well. Simple attempts to trigger the same issue (e.g. http://coliru.stacked-crooked.com/a/6982545ffce8c57d) fail. I'm not familiar enough with Boost.Spirit.X3 and/or fusion to further reduce this.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #25 from janus at gcc dot gnu.org --- Created attachment 45085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45085=edit assembler output assembler output obtained from comment 0 via "gfortran-9 c0.f90 -march=skylake-avx512 -Ofast -S", exhibiting wrong results
[Bug c++/88183] [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183
--- Comment #1 from Ruben Van Boxem ---
Created attachment 45084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45084=edit
compressed preprocessed source causing ICE
Attached preprocessed source file ICEs GCC 8.2.1 20180831 on Arch Linux.
It compiles and works just fine on Clang 7.0.0, MSVC 19.16.27023.1, and GCC
7.3.1 20180814.
It uses Boost.Spirit.X3 from Boost 1.68.
Compile with 'g++ -std=c++17 -c ice.ii' produces:
In file included from
/home/ruben/Development/skui/css/grammar/background.h++:33,
from /home/ruben/Development/skui/css/grammar.h++:40,
from
/home/ruben/Development/skui/tests/css/grammar.test.c++:30:
/home/ruben/Development/skui/css/grammar/make_property.h++: In instantiation of
'auto skui::css::grammar::make_property(const PropertyType&, const ValueType&,
PointerToMemberType ...) [with PropertyType = char [14]; ValueType =
skui::css::grammar::align_content_table; PointerToMemberType =
{skui::css::align_content skui::css::declaration_block::*}]':
/home/ruben/Development/skui/css/grammar.h++:56:112: required from here
/home/ruben/Development/skui/css/grammar/make_property.h++:43:39: internal
compiler error: Segmentation fault
(_val(context).* ... .* member) = _attr(context);
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/88183] New: [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183 Bug ID: 88183 Summary: [GCC7 Regression] Fold expression with operator . Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanboxem.ruben at gmail dot com Target Milestone: ---
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #24 from Alexander Monakov --- Janus, can you attach your .s and .o files please?
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #23 from Jakub Jelinek --- Created attachment 45083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45083=edit pr86735.s Assembly I get which works for me.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #22 from Jakub Jelinek --- Fedora 27, kernel 4.16.4-200 Intel(R) Core(TM) i9-7960X CPU glibc 2.26-30, binutils, 2.29-13
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #21 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #20) > Tried again, this time on real hw (i9-7960X) and still can't reproduce, Thanks for the data point, Jakub. Could you please share your kernel and glibc version? H.J.'s comment 15 sounds like the kernel version might make a difference. (Unfortunately I am stuck with kernel 4.15 right now and cannot verify this.) In any case, I still see the problem with current trunk and this config: * Ubuntu 18.04, kernel 4.15.0 * Intel(R) Core(TM) i9-7980XE CPU * glibc 2.27, binutils 2.30 My trunk build has been configured with: configure --program-suffix=-9 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-arch=skylake-avx512 --prefix=/ --enable-languages=c,c++,fortran --disable-multilib
[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 --- Comment #9 from Christoph Conrads --- nan-lhs.cpp with `float` instead of `double` triggers the same error messages with `QNaNf` in place of `QNaN`.
[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 --- Comment #8 from Christoph Conrads --- Created attachment 45082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45082=edit nan-lhs.cpp
[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 --- Comment #7 from Christoph Conrads --- Created attachment 45081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45081=edit nan-lhs.ii created by GCC 6.3.0 on Raspbian 9.4
[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 --- Comment #6 from Christoph Conrads --- Created attachment 45080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45080=edit nan-lhs.ii created by GCC 7.3.0 on Ubuntu 18.04 LTS
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #14) > Please try kernel 4.17.xx or above. Unfortunately I can not easily test a newer kernel on that hardware right now :(
[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #5 from Christoph Conrads ---
Having read the comments, I began to modify code in the bug report. Apparently,
the bug is only triggered if QNaN is on the wrong side of the comparison
operator:
christoph:~$ cat nan-lhs.cpp
#include
constexpr bool rhs(double f)
{
return !(0 <= f);
}
constexpr bool lhs(double f)
{
return !(f <= 0);
}
int main()
{
static_assert(std::numeric_limits::has_quiet_NaN, "");
static_assert(!(std::numeric_limits::quiet_NaN() <= 0), "");
static_assert(!(0 <= std::numeric_limits::quiet_NaN()), "");
static_assert(lhs(std::numeric_limits::quiet_NaN()), "");
static_assert(rhs(std::numeric_limits::quiet_NaN()), "");
}
christoph:~$ g++ -Wextra -Wall -std=c++11 -pedantic nan-lhs.cpp
nan-lhs.cpp: In function ‘int main()’:
nan-lhs.cpp:16:2: error: non-constant condition for static assertion
static_assert(!(std::numeric_limits::quiet_NaN() <= 0), "");
^
nan-lhs.cpp:16:59: error: ‘(+QNaN <= 0.0)’ is not a constant expression
static_assert(!(std::numeric_limits::quiet_NaN() <= 0), "");
~~^
nan-lhs.cpp:18:2: error: non-constant condition for static assertion
static_assert(lhs(std::numeric_limits::quiet_NaN()), "");
^
nan-lhs.cpp:18:19: in constexpr expansion of
‘lhs(std::numeric_limits::quiet_NaN())’
nan-lhs.cpp:10:13: error: ‘(+QNaN <= 0.0)’ is not a constant expression
return !(f <= 0);
~~~^
nan-lhs.cpp:19:2: error: non-constant condition for static assertion
static_assert(rhs(std::numeric_limits::quiet_NaN()), "");
^
nan-lhs.cpp:19:19: in constexpr expansion of
‘rhs(std::numeric_limits::quiet_NaN())’
nan-lhs.cpp:5:13: error: ‘(+QNaN >= 0.0)’ is not a constant expression
return !(0 <= f);
~~~^
Note that QNaN only appears on the left-hand side in the error messages,
irrespective of the user input.
christoph:~$ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename: bionic
christoph:~$ g++ -Wextra -Wall -std=c++11 -pedantic -v nan-lhs.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-Wpedantic' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE nan-lhs.cpp -quiet -dumpbase nan-lhs.cpp -mtune=generic
-march=x86-64 -auxbase nan-lhs -Wextra -Wall -Wpedantic -std=c++11 -version
-fstack-protector-strong -Wformat-security -o /tmp/ccOYNOxa.s
GNU C++11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/7
/usr/include/x86_64-linux-gnu/c++/7
/usr/include/c++/7/backward
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP
GGC
[Bug tree-optimization/88182] New: [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88182 Bug ID: 88182 Summary: [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6465 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling gcc/testsuite/c-c++-common/gomp/pr60823-2.c w/ -O1 (-O2) -fopenmp -ftree-loop-if-convert -fno-ssa-phiopt: % g++-9.0.0-alpha20181118 -O1 -fopenmp -ftree-loop-if-convert -fno-ssa-phiopt -c gcc/testsuite/c-c++-common/gomp/pr60823-2.c during GIMPLE pass: vect gcc/testsuite/c-c++-common/gomp/pr60823-2.c: In function 'int foo(double, double)': gcc/testsuite/c-c++-common/gomp/pr60823-2.c:8:1: internal compiler error: in vectorizable_reduction, at tree-vect-loop.c:6465 8 | foo (double c1, double c2) | ^~~ 0x76cde7 vectorizable_reduction(_stmt_vec_info*, gimple_stmt_iterator*, _stmt_vec_info**, _slp_tree*, _slp_instance*, vec*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vect-loop.c:6465 0x11398ec vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vect-stmts.c:9539 0x114e6d0 vect_analyze_loop_operations /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vect-loop.c:1576 0x114fd4a vect_analyze_loop_2 /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vect-loop.c:1971 0x114fd4a vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vect-loop.c:2270 0x116c358 try_vectorize_loop_1 /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vectorizer.c:873 0x116d199 vectorize_loops() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree-vectorizer.c:1101
[Bug d/87866] gdc fails to compile minimal test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Based on what you described is the problem, I think this is done.
[Bug d/87866] gdc fails to compile minimal test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sat Nov 24 09:51:03 2018 New Revision: 266429 URL: https://gcc.gnu.org/viewcvs?rev=266429=gcc=rev Log: gcc/d/ChangeLog: 2018-11-24 Iain Buclaw PR d/87866 * d-incpath.cc (add_globalpaths): Use lrealpath to get canonical name. (add_filepaths): Likewise. Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/d-incpath.cc
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073 --- Comment #13 from Jorn Wolfgang Rennecke --- If the shifted value is 16 bit and int is 32 bit wide, then, depending on target costs, instead of a vector compare, we might decide to use a sign extract of bit 4 of the shift count instead.
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #7 from Paul Thomas --- (In reply to Paul Thomas from comment #6) > Author: pault > Date: Sat Nov 24 09:10:00 2018 > New Revision: 266428 > > URL: https://gcc.gnu.org/viewcvs?rev=266428=gcc=rev > Log: > 2018-11-24 Paul Thomas > > PR fortran/88143 > * resolve.c (resolve_variable): Check for associate names with > NULL target. > > 2018-11-24 Paul Thomas > > PR fortran/88143 > * gfortran.dg/associate_46.f90: New test. > > > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/testsuite/ChangeLog I erroneously checked in the patch as PR888143 - the patch is that of comment #5. Paul
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #6 from Paul Thomas --- Author: pault Date: Sat Nov 24 09:10:00 2018 New Revision: 266428 URL: https://gcc.gnu.org/viewcvs?rev=266428=gcc=rev Log: 2018-11-24 Paul Thomas PR fortran/88143 * resolve.c (resolve_variable): Check for associate names with NULL target. 2018-11-24 Paul Thomas PR fortran/88143 * gfortran.dg/associate_46.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073 --- Comment #12 from Jorn Wolfgang Rennecke --- If we are left shifting a narrow signed type for the result, and no defined overflow semantics are in place, it should be OK to just vectorize the code using the result type. If we are right shifting a signed type, we could apply a MAX operation to the shift count. If we are shifting an unsigned type, we can do a vector compare to check if the shift count exceeds the range, and use an AND to zero the result if that is the case. If we are doing a shift right of a signed value where -fwrapv semantics are required or allowed, we can do the same as for unsigned shift. Thus, a shift is replaced by two or three vactor operations, which should be a win if the vectorization factor is four or more. The MAX and compare operations might subsequently be eliminated if value range propagation finds that the value can't be out of range.
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #11 from Jorn Wolfgang Rennecke --- Created attachment 45079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45079=edit testcase using restricted shift count Even if the shift count is restricted in range by applying an AND first, which also further boosts the optimization potential for SHIFT_COUNT_TRUNCATED targets, the code is not vectorized.
