[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968

--- Comment #37 from Markus Trippelsdorf  ---
(In reply to Andreas Schwab from comment #36)
> mpolacek isn't a valid bugzilla user by itself.  You always need to type the
> whole email, or wait for the completion to appear and select it.

Yes when I wait for the completion to appear it works.
But in the previous version of bugzilla I could type mpolacek and hit 
"Save Changes" immediately (before the autocompletion kicked in).
Then on the next page it would show the list of hits.
Select the one you want (in the case of mpolacek there is only one hit)
and hit "Continue". This doesn't work anymore.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968

--- Comment #36 from Andreas Schwab  ---
mpolacek isn't a valid bugzilla user by itself.  You always need to type the
whole email, or wait for the completion to appear and select it.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968

--- Comment #35 from Markus Trippelsdorf  ---
CCing people doesn't work anymore.
For example on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
when I click edit in the CC List, and add "mpolacek" and then hit
save changes immediately. On the next page it shows:
 CC: mpolacek matched Marek Polacek 

Then I hit enter. And the name is not entered in CC.

[Bug c/66066] New: [6 Regression] r222889 causes bogus error: initializer element is not constant

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

Bug ID: 66066
   Summary: [6 Regression] r222889 causes bogus error: initializer
element is not constant
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

% cat decode.i
int a = -1 << 0 | 0;

 % gcc -c decode.i
decode.i:1:9: error: initializer element is not constant
 int a = -1 << 0 | 0;
 ^

[Bug c/66064] under O2 level ，x86-64 compiler ICE，informance：internal compiler error: in fold_convert_loc, at fold-const.c:1894

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66064

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.4
 Resolution|--- |FIXED
  Known to fail||4.7.4

--- Comment #1 from Marc Glisse  ---
4.7 is not supported anymore. All current release branches seem fine.

(if you have a contract with suse, you can try to ask them about backporting
patches in their distribution, I don't know how that works)

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #28 from Jürgen Reuter  ---
Dominique, comment #27 looks perfect. That would be great for us with the
upcoming revision of gfortran 6.0.0.

[Bug fortran/66065] New: ICE on assignment to deferred-length character array

[damian at sourceryinstitute dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66065

Bug ID: 66065
   Summary: ICE on assignment to deferred-length character array
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

I see several other deferred-length character variable bug reports, including a
few ICE report, but I think this is sufficiently different from the others to
warrant a separate submission:

$ cat parse_command_line.f90 
character(len=:), allocatable :: original,copy(:)
copy = [original]
end 

$ gfortran parse_command_line.f90 
parse_command_line.f90:2:0:

 copy = [original]
 ^
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1797

parse_command_line.f90:2:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (MacPorts gcc5 5.1.0_0) 5.1.0

[Bug c++/59012] alignas does not support parameter pack expansions

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59012

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri May  8 04:42:06 2015
New Revision: 222902

URL: https://gcc.gnu.org/viewcvs?rev=222902&root=gcc&view=rev
Log:
PR c++/59012
* parser.c (cp_parser_std_attribute_list): Handle attribute expansion.
(cp_parser_std_attribute_spec): Handle alignas pack expansion.
* decl2.c (is_late_template_attribute): An attribute exp is dependent.
* pt.c (make_pack_expansion): Allow TREE_LIST for attribute expansion.
(apply_late_template_attributes): Handle attribute pack expansion.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alignas4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug c++/60277] Bogus "inline function virtual ..." used but never defined

[maltsevm at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||maltsevm at gmail dot com

--- Comment #3 from Mikhail Maltsev  ---
I also wanted to report this bug (it reproduces on trunk), but found this
report and an old duplicate: PR11067 which is resolved as WONTFIX.

IMHO it's not too difficult to fix, including the case "f->Foo::func();"
(though I did not regtest the fix, so I can't say for sure).

The question is: should this warning be emitted or not? Clang does not produce
such warning.

[Bug c/66064] New: under O2 level ，x86-64 compiler ICE，informance：internal compiler error: in fold_convert_loc, at fold-const.c:1894

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66064

Bug ID: 66064
   Summary: under O2 level ，x86-64 compiler
ICE，informance：internal compiler error: in
fold_convert_loc, at fold-const.c:1894
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangcunjian at huawei dot com
  Target Milestone: ---

case context：
__attribute__ ((vector_size (16))) g_73 = {0x15FE687EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) g_1124;

int func_1(void)
{  
__attribute__ ((vector_size (16))) l_1117 = {0x15FE688EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) zhong = ( g_73 <= g_73);
 g_1124 = (((g_73 < l_1117) == (zhong)) << 9);

return 0;
}
target :x86_64-suse-linux
host: x86_64-suse-linux
build:x86_64-suse-linux

command:
../../compiler/hcc-x86_64-linux/bin/gcc-4.7 test_1.c -O2

output:
test_1.c:11:1: internal compiler error: in fold_convert_loc, at
fold-const.c:1894
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/66063] New: under O2 level ,compiler ICE: internal compiler error: in build_int_cst_wide, at tree.c:1222

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66063

Bug ID: 66063
   Summary: under O2 level ,compiler ICE: internal compiler error:
in build_int_cst_wide, at tree.c:1222
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangcunjian at huawei dot com
  Target Milestone: ---

case context:
int main(){
__attribute__((vector_size(16)))l_605= {0x111,0x222,0x222,0x222};
l_605=(l_605>>1)>>1;
return 0;

}


target:
Target: x86_64-suse-linux


command:
 ../../compiler/hcc-x86_64-linux/bin/gcc-4.7 test_2.c 

compiler output:

test_2.c: In function ‘main’:
test_2.c:3:1: internal compiler error: in build_int_cst_wide, at tree.c:1222
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/66062] New: under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062

Bug ID: 66062
   Summary: under O2 optimization level , aarch64 compiler give
informance  :  internal compiler error: in
expand_assignment, at expr.c:4838
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangcunjian at huawei dot com
  Target Milestone: ---

Created attachment 35493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35493&action=edit
testcase context

gcc version:
Target: aarch64-linux-gnu
Configured with:
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/configure
--build=x86_64-suse-linux --host=x86_64-suse-linux --target=aarch64-linux-gnu
--with-arch=armv8-a
--prefix=/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/install
--disable-multilib --enable-__cxa_atexit --with-gnu-as --with-gnu-ld
--disable-libmudflap --disable-libgomp --disable-libssp --enable-threads
--enable-plugin --enable-c99 --enable-long-long --disable-nls --enable-shared
--enable-poison-system-directories --enable-symvers=gnu --with-pkgversion='SDK
V100R005C00B101' --enable-languages=c,c++

command:
aarch64-linux-gnu-gcc -w -O2 EMI_61144035_2_rd.i

compiler actual output :
./testsuite/gcc.target/hidsp/emi/20150428_151230_normal1/output/2015-4-29_6-46-13_17379704/EMI_61144035_2_rd.c:
In function 'func_1':
./testsuite/gcc.target/hidsp/emi/20150428_151230_normal1/output/2015-4-29_6-46-13_17379704/EMI_61144035_2_rd.c:747:56:
internal compiler error: in expand_assignment, at expr.c:4838
0x670942 expand_assignment(tree_node*, tree_node*, bool)
   
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/gcc/expr.c:4838
0x5b4416 expand_gimple_stmt_1
   
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/gcc/cfgexpand.c:3226
0x5b4a70 expand_gimple_stmt
   
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/gcc/cfgexpand.c:3322
0x5b5588 expand_gimple_basic_block
   
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/gcc/cfgexpand.c:5162
0x5b93b6 gimple_expand_cfg
   
/usr1/code/CODE_SDKV1R5C00/code/current/V1R5/build/script/cpu_hcc/p660/p660_build_dir/src/gcc-4.9/gcc/cfgexpand.c:5741
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/192] String literals don't obey -fdata-sections

[gcc at mattwhitlock dot name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192

--- Comment #17 from Matt Whitlock  ---
(In reply to Segher Boessenkool from comment #16)

Thanks for the fix, Segher. Your patch seems more "right" than mine, although I
will point out that it doesn't precisely address this bug report, as it places
string literal data into unique sections only if -ffunction-sections is set,
whereas -fdata-sections has no impact. I can see arguments both ways, and
personally this distinction is irrelevant to me, as I always use for
-ffunction-sections and -fdata-sections, but the new behavior does seem
somewhat counter-intuitive to me.

Anyway, I tested your new patch (backported to GCC 4.9.2) with the use cases in
Comment 11 and Comment 15, and both produced the desired results (after I added
-ffunction-sections to the command lines in Comment 15). So I'm appeased.

[Bug c++/66061] New: Internal Compiler Error when specializing a variable template when the specialization is variadic

[david at doublewise dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061

Bug ID: 66061
   Summary: Internal Compiler Error when specializing a variable
template when the specialization is variadic
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

main.cpp:

template
int x = 1;

template
int x = 1;





david@i5-fedora ~/test> g++ source/main.cpp -c -std=c++14
source/main.cpp:5:5: internal compiler error: in
process_partial_specialization, at cp/pt.c:4248
 int x = 1;
 ^
0x63102e process_partial_specialization
../../gcc/gcc/cp/pt.c:4248
0x631517 push_template_decl_real(tree_node*, bool)
../../gcc/gcc/cp/pt.c:4892
0x60820f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4832
0x67e266 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17170
0x67ee14 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23811
0x67f0b8 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:23602
0x661f79 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11342
0x688a3a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11264
0x688d4f cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
0x688d4f c_parse_file()
../../gcc/gcc/cp/parser.c:33192
0x73b692 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/66043] ICE on storage_size of null or output of null array

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043

--- Comment #3 from Steve Kargl  ---
On Thu, May 07, 2015 at 05:39:44PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> The above patch is good enough to catch the direct use
> of NULL() in storage_size.   The following should also
> be rejected:
> 
> program p
>real, allocatable :: a
>real, pointer :: b => null()
>print *, storage_size(a)! unallocated allocatable
>print *, storage_size(b)! disassociated pointer
> end program p
> 
> For 'b' we need to check
> 
> a->symtree->n.sym->attr &&
> a->symtree->n->sym.value->expr_type = EXPR_NULL
> 

Dang.  Couldn't get gfc_check_storage_size to reject
this one.

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029

--- Comment #11 from JD  ---
Yes, it's non-empty:

$ ar --help | grep plugin
Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin
] [member-name] [count] archive-file file...
  --plugin  - load the specified plugin
ar: supported targets: elf64-x86-64 elf32-i386 elf32-x86-64 a.out-i386-linux
pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little
elf32-big plugin srec symbolsrec verilog tekhex binary ihex


$  echo "int main () {}" | gcc -x c++ -O2 - -flto -v 2>&1 | grep "collect2
-plugin"
 gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/collect2 -plugin
gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/liblto_plugin.so
-plugin-opt=gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccuU0Nuu.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
gcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/crtbegin.o
-Lgcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0
-Lgcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-Lgcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../.. /tmp/ccUoazVJ.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed gcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/crtend.o
/usr/lib/../lib64/crtn.o

[Bug tree-optimization/66013] Missed optimization after inlining va_list parameter, -m32 case

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66013

--- Comment #4 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/tree-stdarg.c b/gcc/tree-stdarg.c
index efabda7..b334e79 100644
--- a/gcc/tree-stdarg.c
+++ b/gcc/tree-stdarg.c
@@ -62,6 +62,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfg.h"
 #include "tree-pass.h"
 #include "tree-stdarg.h"
+#include "tree-ssa.h"

 /* A simple pass that attempts to optimize stdarg functions on architectures
that need to save register arguments to stack on entry to stdarg functions.
@@ -,6 +1112,7 @@ expand_ifn_va_arg_1 (function *fun)

   free_dominance_info (CDI_DOMINATORS);
   update_ssa (TODO_update_ssa);
+  execute_update_addresses_taken ();
 }

 /* Expand IFN_VA_ARGs in FUN, if necessary.  */
...

We just update address_taken between ifn_va_arg expansion and the pass_stdarg
optimization.

[Bug c/64918] invalid (?) warning when initializing structure

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64918

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu May  7 22:14:27 2015
New Revision: 222894

URL: https://gcc.gnu.org/viewcvs?rev=222894&root=gcc&view=rev
Log:
PR c/64918
* c.opt (Woverride-init-side-effects): New option.

* c-typeck.c (add_pending_init): Use OPT_Woverride_init_side_effects.
(output_init_element): Likewise.

* doc/invoke.texi: Document -Woverride-init-side-effects.

* gcc.dg/Woverride-init-side-effects-1.c: New test.
* gcc.dg/Woverride-init-side-effects-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Woverride-init-side-effects-1.c
trunk/gcc/testsuite/gcc.dg/Woverride-init-side-effects-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027

--- Comment #5 from JD  ---
Created attachment 35492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35492&action=edit
output of gcc -march=native -Q --help=target

[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027

--- Comment #4 from JD  ---
Removing the -O3 flag from the first two invocations changes the behavior:

g++ -std=c++14 -c -fPIC -march=native -flto -fuse-linker-plugin
-fno-fat-lto-objects ASTContext_preproc.cpp -o ASTContext_preproc.o
g++ -std=c++14 -c -fPIC -march=native -flto -fuse-linker-plugin
-fno-fat-lto-objects ASTConsumer_preproc.cpp -o ASTConsumer_preproc.o
ar cru libAST.a ASTContext_preproc.o ASTConsumer_preproc.o
g++ -flto=4 -std=c++14 -march=native -fuse-linker-plugin -shared -o bla.so
CIndex_preproc.cpp libAST.a
/usr/bin/ld: /tmp/ccPyzc8a.ltrans0.ltrans.o: relocation R_X86_64_32 against
`_ZZN4llvm11isa_impl_clIN5clang24OMPThreadPrivateDeclAttrEPKNS1_4AttrEE4doitES5_E19__PRETTY_FUNCTION__.lto_priv.73'
can not be used when making a shared object; recompile with -fPIC
/tmp/ccPyzc8a.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

Adding the -fPIC flag as told makes the example compile successfully with and
without -O3.
-

Removing the -march=native flags causes a compilation error:
g++ -std=c++14 -c -fPIC -O3 -flto -fuse-linker-plugin -fno-fat-lto-objects
ASTContext_preproc.cpp -o ASTContext_preproc.o
g++ -std=c++14 -c -fPIC -O3 -flto -fuse-linker-plugin -fno-fat-lto-objects
ASTConsumer_preproc.cpp -o ASTConsumer_preproc.o
ar cru libAST.a ASTContext_preproc.o ASTConsumer_preproc.o

g++ -flto=4 -std=c++14 -fuse-linker-plugin -shared -o bla.so CIndex_preproc.cpp
libAST.a
In file included from
gcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/include/x86intrin.h:27:0,
 from
gcc5.1/include/c++/5.1.0/x86_64-unknown-linux-gnu/bits/opt_random.h:33,
 from gcc5.1/include/c++/5.1.0/random:50,
 from gcc5.1/include/c++/5.1.0/bits/stl_algo.h:66,
 from gcc5.1/include/c++/5.1.0/algorithm:62,
 from llvm/include/llvm/ADT/StringRef.h:13,
 from CIndexer.h:19,
 from CIndex.cpp:15:
gcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/include/ia32intrin.h: In
function 'unsigned int __crc32b(unsigned int, unsigned char)':
gcc5.1/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/include/ia32intrin.h:63:42:
error: '__builtin_ia32_crc32qi' was not declared in this scope
   return __builtin_ia32_crc32qi (__C, __V);
  ^
...
...

I added the output of
gcc -march=native -Q --help=target

[Bug fortran/66041] [6 Regression] Matmul ICE

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041

--- Comment #3 from Thomas Koenig  ---
Created attachment 35491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35491&action=edit
Patch

When calling lbound for the lower bound of an array section, a reference to the
full array was built.  This still contained a reference to ar->start, which hit
an assert.

This rather obvious patch corrects this.

[Bug c/66060] New: struct member allocation off.

[darpeer at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66060

Bug ID: 66060
   Summary: struct member allocation off.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: darpeer at hotmail dot com
  Target Milestone: ---

Using gdb, two struct members end up at the same offset.

gcc (GCC) 6.0.0 20150418 (experimental) and older.

gcc -c -O0 -ggdb3 struct-example.C

cat struct-example.C
struct ODD_S {
char a[/*0x2000 */   2097152];
char b[/*0x400 */  536870912];
char c[/*0x8000 */  33554432];
} l_;

(gdb) p &l_.a
$1 = (char (*)[2097152]) 0x0 
(gdb) p &l_.b
$2 = (char (*)[536870912]) 0x20 
(gdb) p &l_.c
$3 = (char (*)[33554432]) 0x20 

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yep, been meaning to do this for some time.

[Bug bootstrap/65664] ARM bootstrap fails with --with-fpu=neon-vfpv4

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65664

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jim Wilson  ---
I was able to reproduce this with an armhf cross compiler, compiling the
testcase with -O -mfpu=neon-vfpv4.  It is not broken in gcc-4.9.2.  It was
fixed by this patch
https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01595.html
which has this ChangeLog entry

2014-03-03  Ramana Radhakrishnan  

* config/arm/neon.md (*movmisalign): Legitimize addresses
not handled by recognizers.

I don't know offhand if this is worth backporting to gcc-4.8.x.

[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027

--- Comment #3 from JD  ---
Created attachment 35490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35490&action=edit
preprocessed sources and makefile

[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027

--- Comment #2 from JD  ---
I managed create a minimal example.

bug66027 $ make -j 
g++ -std=c++14 -c -fPIC -march=native -O3 -flto -fuse-linker-plugin
-fno-fat-lto-objects ASTContext_preproc.cpp -o ASTContext_preproc.o
g++ -std=c++14 -c -fPIC -march=native -O3 -flto -fuse-linker-plugin
-fno-fat-lto-objects ASTConsumer_preproc.cpp -o ASTConsumer_preproc.o
ar cru libAST.a ASTContext_preproc.o ASTConsumer_preproc.o
g++ -flto=4 -std=c++14 -march=native -fuse-linker-plugin -shared -o bla.so
CIndex_preproc.cpp libAST.a
  constant 64>
unit size  constant 8>
align 8 symtab 0 alias set 0 canonical type 0x7f9352ff5d20
pointer_to_this  reference_to_this
>
lto1: internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1543
0x807397 odr_types_equivalent_p
../../gcc-5.1.0/gcc/ipa-devirt.c:1543
0x8076ad odr_types_equivalent_p
../../gcc-5.1.0/gcc/ipa-devirt.c:1440
0x804ca1 add_type_duplicate
../../gcc-5.1.0/gcc/ipa-devirt.c:1770
0x804ca1 get_odr_type(tree_node*, bool)
../../gcc-5.1.0/gcc/ipa-devirt.c:1959
0x80642c register_odr_type(tree_node*)
../../gcc-5.1.0/gcc/ipa-devirt.c:2034
0x63876d lto_read_decls
../../gcc-5.1.0/gcc/lto/lto.c:1952
0x6394ae lto_file_finalize
../../gcc-5.1.0/gcc/lto/lto.c:2249
0x6394ae lto_create_files_from_ids
../../gcc-5.1.0/gcc/lto/lto.c:2259
0x6394ae lto_file_read
../../gcc-5.1.0/gcc/lto/lto.c:2300
0x6394ae read_cgraph_and_symbols
../../gcc-5.1.0/gcc/lto/lto.c:3005
0x6394ae lto_main()
../../gcc-5.1.0/gcc/lto/lto.c:3475
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:7: recipe for target 'all' failed
make: *** [all] Error 1

ld -v
GNU ld (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/german/local/gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/home/german/local/gcc5.1
--enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)

ar --version
GNU ar (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1

[Bug rtl-optimization/48442] ICE: in init_seqno, at sel-sched.c:6767 with -Os -fselective-scheduling2 --param max-sched-extend-regions-iters=100

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Alexander Monakov  ---
.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #27 from Dominique d'Humieres  ---
With Mikael's patch I get


Testsuite summary for WHIZARD 2.2.6

# TOTAL: 280
# PASS:  249
# SKIP:  28
# XFAIL: 3
# FAIL:  0
# XPASS: 0
# ERROR: 0

in less than 12 minutes.

[Bug rtl-optimization/48302] ICE: SIGSEGV in reposition_prologue_and_epilogue_notes (function.c:5662) with -fcrossjumping -fselective-scheduling2

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Alexander Monakov  ---
.

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

[az.zaafrani at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052

--- Comment #12 from zaafrani  ---
Thank you for the feedback.

We excluded start value that is constant because it is already
working. To our knowledge, only when the start value is unknown and
the loop index type is of unsigned type that we fail to recognize
non-overflow for situations when it is possible to deduce so. For most
other cases, current analysis done in scev_probably_wraps_p seems to
be working fine. We also added the assumption of step equal 1 so that
we can make correct decision about non-overflow. So, basically we’d
rather catch few simple cases and make them work  then try to
generalize the scope and not being to prove much.


On Wed, May 6, 2015 at 1:56 AM, rguenth at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
>
> --- Comment #11 from Richard Biener  ---
> That's an interesting idea - your argument is that if niter analysis was able
> to compute an expression for the number of iterations and the cast we are
> looking at
> is a widening of a BIV then it is ok to assume the BIV does not wrap.
>
> Unfortunately this breaks down (eventually not in practice due to your
> exclusion of constant initial BIV value) for cases like
>
>
>   for (unsigned i = 3; i != 2; i+=7)
> ;
>
> where niter analysis can still compute the number of iterations (I've made
> the numbers up, so maybe that loop will never terminate...).
>
> Still the idea is interesting as we might be able to record whether BIVs
> overflow or not.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libstdc++/66059] New: make_integer_sequence should use a log(N) implementation

[rhalbersma at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059

Bug ID: 66059
   Summary: make_integer_sequence should use a log(N)
implementation
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

The following program fails to compile for g++ 4.9.0 and further 

#include 

int main()
{
constexpr auto N = 1024;
using T = std::make_integer_sequence;
static_assert(T::size() == N, "");
}

fatal error: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum)

Note that Clang with -stdlib=libc++ can compile integer sequences of up to one
million for machines with enough memory, and around 65K for online compilers
such as wandbox.com. Clang + libstdc++ requires -ftemplate-depth=N for N beyond
256. 

Changing g++ default template instantiation depth beyond 900 is not a viable
solution. It simply masks the problem of excessive template instantiations. 

Instead, the implementation of make_integer_sequence should be made to
scale as log(N). See e.g. http://stackoverflow.com/a/17426611/819272

[Bug fortran/66058] Backslash in comment kills compile

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66058

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Matt Thompson from comment #1)
> Addendum,
> 
> I've tried various gfortran flags, but for the life of me, none seem to get
> this to work.
> 
> Matt

You're getting the expected behaviour implied by the .F extention.
The pre-processor is doing what it is should (from n1256.pdf)

Each instance of a backslash character (\) immediately followed
by a new-line character is deleted, splicing physical source
lines to form logical source lines.  Only the last backslash on
any physical source line shall be eligible for being part of
such a splice. A source file that is not empty shall end in a
new-line character, which shall not be immediately preceded
by a backslash character before any such splicing takes place.

The option that you are looking for is -xf95.  It tells gfortran
to ignore the .F extension and treat the code as Fortran 95 without
doing the pre-processing.

[Bug c/65179] Introduce new C warning: -Wshift-negative-value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65179

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Done for GCC 6.

[Bug c/65179] Introduce new C warning: -Wshift-negative-value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65179

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu May  7 19:36:31 2015
New Revision: 222889

URL: https://gcc.gnu.org/viewcvs?rev=222889&root=gcc&view=rev
Log:
PR c/65179
* c-common.c (c_fully_fold_internal): Warn when left shifting a
negative value.
* c.opt (Wshift-negative-value): New option.
* c-opts.c (c_common_post_options): Set warn_shift_negative_value
when -Wextra and C99/C++11 mode.

* c-typeck.c (build_binary_op): Warn when left shifting a negative
value.

* typeck.c (cp_build_binary_op): Warn when left shifting a negative
value.

* doc/invoke.texi: Document -Wshift-negative-value.

* c-c++-common/Wshift-negative-value-1.c: New test.
* testsuite/c-c++-common/Wshift-negative-value-2.c: New test.
* testsuite/c-c++-common/Wshift-negative-value-3.c: New test.
* testsuite/c-c++-common/Wshift-negative-value-4.c: New test.
* testsuite/c-c++-common/Wshift-negative-value-5.c: New test.
* testsuite/c-c++-common/Wshift-negative-value-6.c: New test.
* testsuite/gcc.dg/c90-left-shift-1.c: New test.
* testsuite/gcc.dg/c99-const-expr-7.c: Add dg-error.
* testsuite/gcc.dg/c99-left-shift-1.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-1.c
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-2.c
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-3.c
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-4.c
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-5.c
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-6.c
trunk/gcc/testsuite/gcc.dg/c90-left-shift-1.c
trunk/gcc/testsuite/gcc.dg/c99-left-shift-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/c99-const-expr-7.c

[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ ("O2")))

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May  7 19:35:45 2015
New Revision: 222888

URL: https://gcc.gnu.org/viewcvs?rev=222888&root=gcc&view=rev
Log:
PR target/66015
* config/alpha/alpha.c (alpha_override_options_after_change): New.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New.
(alpha_override_options): Move align_loops, align_jumps and
align_functions handling into alpha_override_options_after_change.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/alpha/alpha.c

[Bug fortran/66058] Backslash in comment kills compile

[matthew.thompson at nasa dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66058

--- Comment #1 from Matt Thompson  ---
Addendum,

I've tried various gfortran flags, but for the life of me, none seem to get
this to work.

Matt

[Bug fortran/66058] New: Backslash in comment kills compile

[matthew.thompson at nasa dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66058

Bug ID: 66058
   Summary: Backslash in comment kills compile
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.thompson at nasa dot gov
  Target Milestone: ---

Created attachment 35489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35489&action=edit
Reproducer of compiler bug

I've discovered what I think is a bug in gfortran-5.1.0 but I'm not sure. To
wit, given the code attached, if you compile it:

**

(430) $ gfortran -c -v -save-temps TRAMP_coag.F
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/ford1/local/gcc/gcc-5.1.0
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /ford1/local/gcc/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/f951
TRAMP_coag.F -ffixed-form -cpp=TRAMP_coag.f90 -quiet -v TRAMP_coag.F -quiet
-dumpbase TRAMP_coag.F -mtune=generic -march=x86-64 -auxbase TRAMP_coag
-version -fintrinsic-modules-path
/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/finclude -o
TRAMP_coag.s
GNU Fortran (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/finclude
 /ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /ford1/local/gcc/gcc-5.1.0/include

/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
TRAMP_coag.F:27:31:

 IF( PUSE .GT. KIJ_PRES2 ) THEN
   1
Error: Symbol ‘kij_pres2’ at (1) has no IMPLICIT type
TRAMP_coag.F:23:31:

 IF( TUSE .GT. KIJ_TEMP2 ) THEN
   1
Error: Symbol ‘kij_temp2’ at (1) has no IMPLICIT type

**

Now, if you open that code and remove the backslashes at the end of lines 5 and
7, you get:

**

(431) $ gfortran -c -v -save-temps TRAMP_coag.works.F
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/ford1/local/gcc/gcc-5.1.0
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /ford1/local/gcc/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/f951
TRAMP_coag.works.F -ffixed-form -cpp=TRAMP_coag.works.f90 -quiet -v
TRAMP_coag.works.F -quiet -dumpbase TRAMP_coag.works.F -mtune=generic
-march=x86-64 -auxbase TRAMP_coag.works -version -fintrinsic-modules-path
/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/finclude -o
TRAMP_coag.works.s
GNU Fortran (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/finclude
 /ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /ford1/local/gcc/gcc-5.1.0/include

/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 as -v --64 -o TRAMP_coag.works.o TRAMP_coag.works.s
GNU assembler version 2.20.51.0.2 (x86_64-redhat-linux) using BFD version
version 2.20.51.0.2-5.42.el6 20100205
COMPILER_PATH=/ford1/local/gcc/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/:/ford1/local/gcc/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/:/ford1/local/gcc/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/:/ford1/local/gcc/gcc-5.1.0/lib/gcc/x86_64-unkn

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #26 from Dominique d'Humieres  ---
With Andre's patch on top of a clean tree at r222878, I get


Testsuite summary for WHIZARD 2.2.6

# TOTAL: 280
# PASS:  107
# SKIP:  28
# XFAIL: 1
# FAIL:  142
# XPASS: 2
# ERROR: 0

After 2 hours I lost patience and killed all the tests requiring more than
~10Gb or more than 5 minutes (~30 of them, on a Corei7 with 16Gb of RAM). I
have no idea if such huge memory usage or long time are expected.

I'll test Mikael's patch at
https://gcc.gnu.org/ml/fortran/2015-05/msg00027.html.

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862

--- Comment #8 from Vladimir Makarov  ---
(In reply to Matthew Fortune from comment #6)
> (In reply to Robert Suchanek from comment #5)
> > > I am not sure, that the result code is better as we access memory 3
> > > times instead of access to $f20.
> > 
> > On one hand, yes, it seems good but it's not always desirable to use FP regs
> > until absolutely necessary. For instance, compiling the dynamic linker that
> > uses FP regs does not seem to be right.
> 
> On the costs front then while it is true that moves between FPR and GPR are
> usually cheaper than moving to memory and back there is a secondary cost
> which is that simply turning on the FPU is costly. So, the reason for using
> FPRs needs to be that the floating point instructions are used rather than
> registers. Ideally we would not spill to FPRs unless there has been actual
> floating point code used, this suggests it would be good to set the cost of
> GPR->FPR higher than memory if no floating point code is present in the
> function. Otherwise if the FPU is in use anyway then using FPRs as
> scratch/spill for integer mode data is fine and the costs can be lower than
> memory. 

Thanks, Matt.  It is a good point.  As I wrote in my previous comment,
introducing target hook narrowing allocno class could help here.  Hook
implementation for MIPS could change ALL_REGS to general regs unless the pseudo
is of a floating point mode.

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862

--- Comment #7 from Vladimir Makarov  ---
(In reply to Robert Suchanek from comment #5)
> Sorry for late reply, I was on vacation.
> 
> > The costs are equal if cost of moving general regs to/from fp regs or
> > memory are equal.  So it looks ok to me.
> > 
> > r218 spilled in IRA is reassigned to a fp reg in *LRA*.  
> 
> > But I could try to use preferred class in LRA (after checking how it
> > affects x86/x86-64 performance), if such solution is ok for you.
> 
> Indeed, the above test case only shows the problem in LRA. If the preferred
> class would be the winner then why not. However, there are still some issues
> with IRA and I have another testcase to show it.
> 
> > I am not sure, that the result code is better as we access memory 3
> > times instead of access to $f20.
> 
> On one hand, yes, it seems good but it's not always desirable to use FP regs
> until absolutely necessary. For instance, compiling the dynamic linker that
> uses FP regs does not seem to be right.
> 
> I had another thought about spilling into registers and how we could
> guarantee
> spilling into the desirable class. In the majority of cases where integers
> end up
> in floating-point registers, I see the following in the dumps:
> ...
>   Reassigning non-reload pseudos
>Assign 52 to r217 (freq=46)
> ...
> 

If we use preferred class instead of allocno one, the problem goes away.  Of
course, if IRA does not assign ALL_REGS to the preferred class.

> 
> In the remaining 5% cases, IRA assigns FP regs with LRA blindly following
> IRA's decisions like in the following reduced case:
> 

I guess the same would happen for reload pass too, as it reassigns pseudos
spilled in reload when IRA assigns ALL_REGS to preferred class.

> int a, b, d, e, j, k, n, o;
> unsigned c, h, i, l, m, p;
> int *f;
> int *g;
> int fn1(int p1) { return p1 - a; }
> 
> int fn2() {
>   b = b + 1 - a;
>   e = 1 + o + 1518500249;
>   d = d + n;
>   c = (int)c + g[0];
>   b = b + m + 1;
>   d = d + p + 1518500249;
>   d = d + k - 1;
>   c = fn1(c + j + 1518500249);
>   e = fn1(e + i + 1);
>   d = d + h + 1859775393 - a;
>   c = fn1(c + (d ^ 1 ^ b) + g[1] + 1);
>   b = fn1(b + m + 3);
>   d = fn1(d + l + 1);
>   b = b + (c ^ 1) + p + 1;
>   e = fn1(e + (b ^ c ^ d) + n + 1);
>   d = o;
>   b = 0;
>   e = e + k + 1859775393;
>   f[0] = e;
> }
> 
> I'm not sure how this could be fixed in LRA and again this is related to
> ALL_REGS for allocnos. Perhaps changing the class for reloads to the spill
> class in LRA would do the trick but it may have other problems.
> My last attempt was to increase the cost of FP_REGS in IRA for integral
> modes (similar effect to increasing the costs of moving FP<>GR in the
> backend) but the cost pass looks complicated and I'm not entirely sure where
> to tweak it. Any suggestions/ideas?
> 

Currently, I see the solution in introducing a target hook which can narrow
allocno class for given pseudo in IRA.  For pseudo of non fp-mode, it should
narrow ALL_REGS to general regs in MIPS case.

Actually, I was already asked for such hook from ARM people but their case was
not convincible. 


> > I tried reverting the ALL_REGS patch and I don't see any regressions - in
> > fact allocations are slightly better (fewer registers with ALL_REGS
> > preference which is what we need - a strong decision to allocate to either
> > FP or int regs). So what was the motivation for it?
> 
> AFAICS, the aim was to fix the code generation regression for x86. x86
> doesn't seem to be as much affected as others. I did not notice code size
> differences with -O2 and default arch for x86_64-unknown-linux-gnu triplet
> and CSiBE benchmark, -Os showed some minor improvements/regression with the
> largest difference in mpeg2dec-0.3.1 yielding ~0.3% improvement. I haven't
> evaluated performance changes.
> 
> For MIPS, I also saw allocation improvements, more erratic than x86 with
> improvement about 0.5% on average. Reverting the patch does bring the old
> issue back but I wonder what is the impact of it and whether it is a
> justifiable fix to the extent it outweights the disadvantages. Or maybe the
> original problem could be fixed differently?

I'll try to investigate this more.  But first, I'd like to make a patch for the
new hook in order you evaluate it usefulness for MIPS.  I hope to make it and
send it to you tomorrow.

[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.

This patch

Index: decl.c
===
--- decl.c  (revision 222869)
+++ decl.c  (working copy)
@@ -8510,6 +8511,11 @@ gfc_match_generic (void)
gfc_op2string (op));
   break;

+case INTERFACE_NAMELESS:
+  gfc_error ("Malformed GENERIC statement at %C");
+  goto error;
+  break;
+
 default:
   gcc_unreachable ();
 }

generates

gfc6 -c -O qo.f90
qo.f90:5:16:

   generic :: !
1
Error: Malformed GENERIC statement at (1)

[Bug c++/58616] [meta-bug] nsdmi

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616
Bug 58616 depends on bug 60125, which changed state.

Bug 60125 Summary: [DR 1351] defaulted constructor with throwing NSDMI still 
declared as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60125

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

[Bug c++/60125] [DR 1351] defaulted constructor with throwing NSDMI still declared as noexcept

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60125

Jason Merrill  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #2 from Jason Merrill  ---
Fixed by r209907.

[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[brobecker at gnat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352

Joel Brobecker  changed:

   What|Removed |Added

 CC||brobecker at gnat dot com

--- Comment #13 from Joel Brobecker  ---
Sorry guys, but dsymutil is not working very well. I have a couple of examples
where, either dsymutil is excluding some DIEs from the DWARF image, or where
dsymutil actually segfaults. There is also the fact that dsymutil doesn't know
about recent DWARF enhancements, and doesn't work well when compiling code with
-gno-strict-dwarf.

GDB should be able to use the debug info from the object files without
requiring the use of dsymutil. Since we do not control dsymutil and its quality
level (or lack thereof), I suggest the best course of action is trying to
figure out why GDB doesn't pick the debugging info up from the .o files, and
then fix that.

In the meantime, I suggest we revert this change, or else make it optional at
the very least.

PS: Our experiments are on Darwin 13.4 and 14.3.

[Bug fortran/66056] Segmentation fault for lonely label in type

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This one is interesting.  If you compile with -O or -O2,
then there is no ICE.

[Bug fortran/66043] ICE on storage_size of null or output of null array

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043

--- Comment #2 from Steve Kargl  ---
On Thu, May 07, 2015 at 03:52:24PM +, kargl at gcc dot gnu.org wrote:
> 
> Index: check.c
> ===
> --- check.c (revision 222869)
> +++ check.c (working copy)
> @@ -6243,6 +6243,16 @@ gfc_check_and (gfc_expr *i, gfc_expr *j)
>  bool
>  gfc_check_storage_size (gfc_expr *a, gfc_expr *kind)
>  {
> +  if (a->expr_type == EXPR_NULL)
> +{
> +  gfc_error ("%qs argument of %qs intrinsic at %L shall not be an "
> +"unallocated allocatable variable or a disassociated or "
> +"undefined pointer",
> +gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
> +&a->where);
> +  return false;
> +}
> +
>if (a->ts.type == BT_ASSUMED)
>  {
>gfc_error ("%qs argument of %qs intrinsic at %L shall not be TYPE(*)",
> 
> 

The above patch is good enough to catch the direct use
of NULL() in storage_size.   The following should also
be rejected:

program p
   real, allocatable :: a
   real, pointer :: b => null()
   print *, storage_size(a)! unallocated allocatable
   print *, storage_size(b)! disassociated pointer
end program p

For 'b' we need to check

a->symtree->n.sym->attr &&
a->symtree->n->sym.value->expr_type = EXPR_NULL

For 'a', something similar is needed.

[Bug fortran/66057] New: ICE for incomplete generic statement (gfc_match_generic)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057

Bug ID: 66057
   Summary: ICE for incomplete generic statement
(gfc_match_generic)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code fragment with an incomplete generic statement ...
   program p
  type t
  contains
  generic :: !
  end type
   end

or this variation ...
   program p
  type t
  contains
  generic :: ;
  end type
   end

produces (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: in gfc_match_generic, at fortran/decl.c:8514

---

Other illegal characters produce the same error :
   program p
  type t
  contains
  generic :: 1
  generic :: 2
  generic :: .
  generic :: ,
  generic :: +
  generic :: -
  generic :: *
  generic :: /
  generic :: =
  generic :: '
  generic :: "
  generic :: %
  generic :: ?
  generic :: (
  generic :: )
  !...
  generic :: 1 =
  generic :: 1 =>
  generic :: 1 => 2
  generic :: 1 => x
  !...
  end type
   end

Kind regards.

[Bug fortran/66056] New: Segmentation fault for lonely label in type

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

Bug ID: 66056
   Summary: Segmentation fault for lonely label in type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code fragment with a lonely label in a type ...
   program p
  type t
  1 !
  end type
   end

or this variation ...
   program p
  type t
  ; 1 ;
  end type
   end

produces (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
internal compiler error: Segmentation fault

---

Similar, but with a lonely real number instead ...
   program p
  type t
  1.2 !
  end type
   end

or this variation ...
   program p
  type t
  ; 1.2 ;
  end type
   end

leads to ...
Warning: Ignoring statement label in empty statement at (1)
(null):0: confused by earlier errors, bailing out

Kind regards.

[Bug libstdc++/66055] hash containers missing required reserving constructors

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 Ever confirmed|0   |1

[Bug libstdc++/66055] hash containers missing required reserving constructors

[ncm at cantrip dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055

ncm at cantrip dot org changed:

   What|Removed |Added

  Attachment #35487|0   |1
is obsolete||

--- Comment #1 from ncm at cantrip dot org ---
Created attachment 35488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35488&action=edit
Better fix

Previous patch was incompletely edited for inclusion.

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #15 from Jason Merrill  ---
Fixed.

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Thu May  7 16:46:49 2015
New Revision: 222881

URL: https://gcc.gnu.org/viewcvs?rev=222881&root=gcc&view=rev
Log:
DR 1467
PR c++/51747
* typeck2.c (digest_init_r): Fix single element list.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist95.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Thu May  7 16:46:58 2015
New Revision: 222882

URL: https://gcc.gnu.org/viewcvs?rev=222882&root=gcc&view=rev
Log:
DR 1467
PR c++/51747
* typeck2.c (digest_init_r): Fix single element list.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/initlist95.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/typeck2.c

[Bug libstdc++/66055] New: hash containers missing required reserving constructors

[ncm at cantrip dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055

Bug ID: 66055
   Summary: hash containers missing required reserving
constructors
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ncm at cantrip dot org
  Target Milestone: ---

Created attachment 35487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35487&action=edit
missing hash container constructors, provided.

Hash containers in libstdc++ each lack two required reserving constructors from
size_type and other arguments.

[Bug jit/66054] New: bootstrap comparison failure with --enable-host-shared

[aldot at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66054

Bug ID: 66054
   Summary: bootstrap comparison failure with --enable-host-shared
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: minor
  Priority: P3
 Component: jit
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Bootstrapping with --enable-host-shared fails stage2/3 comparison for all but
crt files.

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
gcc/builtins.o differs
[snip gcc/{,*/}*.o libbacktrace/{,.libs/}*.o libcpp/*.o libdecnumber/*.o
libiberty/*.o lto-plugin/.libs/*.o zlib/*.o]
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/obj.x86_64/gcc-6.0.orig'
make[1]: *** [stage3-bubble] Error 2

for me when i

../../src/gcc-6.0.orig/configure \
  -v \
  --enable-languages=c,lto,fortran,c++,go,objc,obj-c++,jit \
  LD="ld" \
  CFLAGS="-g -O2" \
  CXXFLAGS="-g -O2" \
  BOOT_CFLAGS="-g -O2" \
  BOOT_CXXFLAGS="-g -O2" \
  CFLAGS_FOR_TARGET="-g -O2" \
  CXXFLAGS_FOR_TARGET="-g -O2" \
  --prefix=/opt/x86_64/gcc-6.0.orig// \
  --enable-shared \
  --without-system-zlib \
  --enable-nls \
  --without-included-gettext \
  --enable-threads=posix \
  --enable-__cxa_atexit \
  --enable-libstdcxx-allocator=mt \
  --enable-clocale=gnu \
  --enable-libstdcxx-debug \
  --enable-mpfr \
  --disable-werror \
  --enable-debug \
  --with-isl=/opt/x86_64/isl \
  -C \
  --disable-intermodule \
  --enable-multilib \
  --disable-libstdcxx-pch \
  --enable-bootstrap \
  --enable-host-shared \
  --enable-checking=yes \
  --with-cpu=native \
  --with-tune=native \
  --enable-plugin

ISTM that nowadays at least some libraries already have pic/*.o (libiberty
comes to mind)

[Bug c++/66053] New: openmp target data mappings containing this pointers

[cesar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66053

Bug ID: 66053
   Summary: openmp target data mappings containing this pointers
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35486&action=edit
omp target data map test

I know that the openmp spec states that incomplete types are prohibited from
being used in target data maps. However, what about this pointers? E.g. 

#pragma omp target data map (tofrom:this[0:1])

In this case, the entire object is getting transferred to the device. Should
this be ok? Currently gcc emits an "expected unqualified-id before ‘this’"
error message. Maybe cp_parser_omp_var_list_no_open needs to be made aware of
this pointers?

I've seen some examples of openacc programs using this pointers, but the
openacc 2.0a spec is unclear on c++ in general. So, if this pointers aren't
supported in openmp, I'm not planning on supporting it in openacc until the
spec explicitly demands it.

[Bug c++/62212] ICE compiling template function with array reference parameter whose size depends on a template parameter

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212

--- Comment #2 from Lewis Hyatt  ---
Hello-

FYI, I have located the commit which broke this testcase, it is this one:

==
Author: jason
Date: Fri Oct 15 21:15:13 2010
New Revision: 165521

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165521
Log:
PR c++/45983
* tree.c (cp_build_qualified_type_real): Don't reuse a variant
with a different typedef variant of the element type.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr45983_0.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog
==

Thanks...

-Lewis

[Bug fortran/66043] ICE on storage_size of null or output of null array

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmned.

In reviewing the draft of the F2008 standard, the argument of
storage_size "shall not be an unallocated allocatable variable
or a disassociated or undefined pointer."

This suggests the following patch (watch cut-n-paste tab
corruption):


Index: check.c
===
--- check.c (revision 222869)
+++ check.c (working copy)
@@ -6243,6 +6243,16 @@ gfc_check_and (gfc_expr *i, gfc_expr *j)
 bool
 gfc_check_storage_size (gfc_expr *a, gfc_expr *kind)
 {
+  if (a->expr_type == EXPR_NULL)
+{
+  gfc_error ("%qs argument of %qs intrinsic at %L shall not be an "
+"unallocated allocatable variable or a disassociated or "
+"undefined pointer",
+gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+&a->where);
+  return false;
+}
+
   if (a->ts.type == BT_ASSUMED)
 {
   gfc_error ("%qs argument of %qs intrinsic at %L shall not be TYPE(*)",


This then yields

% gfc6 -c po.f90
po.f90:2:28:

   print *, storage_size(null())
1
Error: 'a' argument of 'storage_size' intrinsic at (1) shall not be an
unallocated allocatable variable or a disassociated or undefined pointer

[Bug middle-end/192] String literals don't obey -fdata-sections

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192

--- Comment #16 from Segher Boessenkool  ---
Author: segher
Date: Thu May  7 15:51:01 2015
New Revision: 222880

URL: https://gcc.gnu.org/viewcvs?rev=222880&root=gcc&view=rev
Log:
PR middle-end/192
PR middle-end/54303
* varasm.c (function_mergeable_rodata_prefix): New function.
(mergeable_string_section): Use it.
(mergeable_constant_section): Use it.

gcc/testsuite/
* gcc.dg/fdata-sections-2.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/fdata-sections-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303

--- Comment #17 from Segher Boessenkool  ---
Author: segher
Date: Thu May  7 15:51:01 2015
New Revision: 222880

URL: https://gcc.gnu.org/viewcvs?rev=222880&root=gcc&view=rev
Log:
PR middle-end/192
PR middle-end/54303
* varasm.c (function_mergeable_rodata_prefix): New function.
(mergeable_string_section): Use it.
(mergeable_constant_section): Use it.

gcc/testsuite/
* gcc.dg/fdata-sections-2.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/fdata-sections-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug fortran/66050] ICE: FORALL with operation on matrix columns

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66050

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
The test in comment 2 compiles with -O1 -fno-frontend-optimize.

[Bug fortran/66044] ICE on misplaced entry statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-05-07
 CC||kargl at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Confirmed.

This appears to be an intentional ICE as gfc_match_entry
explicitly calls gfc_internal_error.  As this is a programmer
error and not an internal compiler error.  The following 
patch is probably the correct solution:

Index: decl.c
===
--- decl.c  (revision 222869)
+++ decl.c  (working copy)
@@ -5592,7 +5592,7 @@ gfc_match_entry (void)
   "a contained subprogram");
break;
  default:
-   gfc_internal_error ("gfc_match_entry(): Bad state");
+   gfc_error ("Unexpected ENTRY statement at %C");
}
   return MATCH_ERROR;
 }

This then yields

% gfc6 -c po.f90
po.f90:4:7:

 entry e
   1
Error: Unexpected ENTRY statement at (1)
po.f90:10:13:

   entry e
 1
Error: Unexpected ENTRY statement at (1)

[Bug fortran/66045] ICE on incorrect code with null

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66045

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.

This patch (watch copy-n-paste tab corruption)

Index: expr.c
===
--- expr.c  (revision 222869)
+++ expr.c  (working copy)
@@ -3118,19 +3118,22 @@ gfc_check_assign (gfc_expr *lvalue, gfc_
bad_proc = true;

   /* (ii) The assignment is in the main program; or  */
-  if (gfc_current_ns->proc_name->attr.is_main_program)
+  if (gfc_current_ns->proc_name
+ && gfc_current_ns->proc_name->attr.is_main_program)
bad_proc = true;

   /* (iii) A module or internal procedure...  */
-  if ((gfc_current_ns->proc_name->attr.proc == PROC_INTERNAL
-  || gfc_current_ns->proc_name->attr.proc == PROC_MODULE)
+  if (gfc_current_ns->proc_name
+ && (gfc_current_ns->proc_name->attr.proc == PROC_INTERNAL
+ || gfc_current_ns->proc_name->attr.proc == PROC_MODULE)
  && gfc_current_ns->parent
  && (!(gfc_current_ns->parent->proc_name->attr.function
|| gfc_current_ns->parent->proc_name->attr.subroutine)
  || gfc_current_ns->parent->proc_name->attr.is_main_program))
{
  /* ... that is not a function...  */
- if (!gfc_current_ns->proc_name->attr.function)
+ if (gfc_current_ns->proc_name
+ && !gfc_current_ns->proc_name->attr.function)
bad_proc = true;

  /* ... or is not an entry and has a different name.  */

yields

gfc6 -c po.f90
po.f90:3:19:

integer :: null=null()
   1
Error: NULL appears on right-hand side in assignment at (1)

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029

--- Comment #10 from Markus Trippelsdorf  ---
Is the output of the following commands non-empty?

 % ar --help | grep plugin

 % echo "int main () {}" | gcc -x c++ -O2 - -flto -v 2>&1 | grep "collect2
-plugin"

[Bug fortran/66052] Segmentation fault for misplaced protected statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-07
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.

This patch

Index: decl.c
===
--- decl.c  (revision 222869)
+++ decl.c  (working copy)
@@ -6968,7 +6968,8 @@ gfc_match_protected (void)
   gfc_symbol *sym;
   match m;

-  if (gfc_current_ns->proc_name->attr.flavor != FL_MODULE)
+  if (gfc_current_ns->proc_name &&
+  gfc_current_ns->proc_name->attr.flavor != FL_MODULE)
 {
gfc_error ("PROTECTED at %C only allowed in specification "
  "part of a module");

gives

% gfc6 -c po.f90
po.f90:3:13:

   protected x
 1
Error: Unexpected attribute declaration statement in CONTAINS section at (1)

[Bug testsuite/66046] UBSan output pattern tests fail on target ARM board.

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66046

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 6.

[Bug testsuite/66046] UBSan output pattern tests fail on target ARM board.

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66046

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Thu May  7 14:44:26 2015
New Revision: 222878

URL: https://gcc.gnu.org/viewcvs?rev=222878&root=gcc&view=rev
Log:
PR testsuite/66046
* c-c++-common/ubsan/align-6.c: Don't match trailing newlines in the
last dg-output.
* c-c++-common/ubsan/align-7.c: Likewise.
* c-c++-common/ubsan/bounds-8.c: Likewise.
* c-c++-common/ubsan/float-cast-overflow-9.c: Likewise.
* c-c++-common/ubsan/load-bool-enum.c: Likewise.
* c-c++-common/ubsan/null-1.c: Likewise.
* c-c++-common/ubsan/null-10.c: Likewise.
* c-c++-common/ubsan/null-11.c: Likewise.
* c-c++-common/ubsan/null-2.c: Likewise.
* c-c++-common/ubsan/null-3.c: Likewise.
* c-c++-common/ubsan/null-4.c: Likewise.
* c-c++-common/ubsan/null-5.c: Likewise.
* c-c++-common/ubsan/null-6.c: Likewise.
* c-c++-common/ubsan/null-7.c: Likewise.
* c-c++-common/ubsan/null-8.c: Likewise.
* c-c++-common/ubsan/null-9.c: Likewise.
* c-c++-common/ubsan/object-size-1.c: Likewise.
* c-c++-common/ubsan/object-size-10.c: Likewise.
* c-c++-common/ubsan/object-size-4.c: Likewise.
* c-c++-common/ubsan/object-size-5.c: Likewise.
* c-c++-common/ubsan/object-size-7.c: Likewise.
* c-c++-common/ubsan/object-size-8.c: Likewise.
* c-c++-common/ubsan/object-size-9.c: Likewise.
* c-c++-common/ubsan/overflow-add-2.c: Likewise.
* c-c++-common/ubsan/overflow-int128.c: Likewise.
* c-c++-common/ubsan/overflow-mul-2.c: Likewise.
* c-c++-common/ubsan/overflow-mul-4.c: Likewise.
* c-c++-common/ubsan/overflow-negate-1.c: Likewise.
* c-c++-common/ubsan/overflow-negate-3.c: Likewise.
* c-c++-common/ubsan/overflow-sub-2.c: Likewise.
* c-c++-common/ubsan/overflow-sub-4.c: Likewise.
* c-c++-common/ubsan/pr59333.c: Likewise.
* c-c++-common/ubsan/pr59667.c: Likewise.
* c-c++-common/ubsan/pr60613-2.c: Likewise.
* c-c++-common/ubsan/pr60636.c: Likewise.
* c-c++-common/ubsan/pr63802.c: Likewise.
* c-c++-common/ubsan/recovery-1.c: Likewise.
* c-c++-common/ubsan/recovery-3.c: Likewise.
* c-c++-common/ubsan/shift-1.c: Likewise.
* c-c++-common/ubsan/shift-2.c: Likewise.
* c-c++-common/ubsan/shift-4.c: Likewise.
* c-c++-common/ubsan/shift-7.c: Likewise.
* c-c++-common/ubsan/undefined-2.c: Likewise.
* c-c++-common/ubsan/vla-1.c: Likewise.
* g++.dg/ubsan/null-1.C: Likewise.
* g++.dg/ubsan/null-3.C: Likewise.
* g++.dg/ubsan/null-4.C: Likewise.
* g++.dg/ubsan/vptr-8.C: Likewise.
* g++.dg/ubsan/vptr-9.C: Likewise.
* gcc.dg/ubsan/bounds-2.c: Likewise.
* gcc.dg/ubsan/object-size-9.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/align-6.c
trunk/gcc/testsuite/c-c++-common/ubsan/align-7.c
trunk/gcc/testsuite/c-c++-common/ubsan/bounds-8.c
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-9.c
trunk/gcc/testsuite/c-c++-common/ubsan/load-bool-enum.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-1.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-10.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-11.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-3.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-4.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-5.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-6.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-7.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-8.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-9.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-1.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-10.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-4.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-5.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-7.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-8.c
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-add-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-int128.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-4.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-negate-1.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-negate-3.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-sub-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/overflow-sub-4.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr59667.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr60613-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr60636.c
trunk/gcc/testsuite/c-c++-com

[Bug fortran/66050] ICE: FORALL with operation on matrix columns

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66050

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Dominique d'Humieres  ---
> I may have made some mistake on the original example.
> This should trigger the ICE (in some conditions, see below)
> ...

It does with 6.0 r222768, Corei7:

pr66050_1.f90:4:0:

   forall(i=1:3)
 1
internal compiler error: in gfc_trans_forall_1, at fortran/trans-stmt.c:4187

backtrace is

frame #9: 0x000100db5b26 f951`fancy_abort(file=,
line=, function=) + 38 at diagnostic.c:1291
frame #10: 0x000100154635
f951`gfc_trans_forall_1(code=0x000143209170,
nested_forall_info=0x7fff5fbfee60) + 3093 at trans-stmt.c:4187
frame #11: 0x0001000d06d8 f951`trans_code(code=0x000143209170,
cond=0x) + 1080 at trans.c:1829
frame #12: 0x00010010088b
f951`gfc_generate_function_code(ns=) + 1275 at trans-decl.c:5896
frame #13: 0x00010008800c f951`gfc_parse_file() + 1836 at parse.c:5341
frame #14: 0x0001000ccff6 f951`gfc_be_parse_file + 38 at f95-lang.c:228

[Bug c++/66042] Implicitly converts lvalue to rvalue when returning reference parameter in function template

[david at doublewise dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66042

David Stone  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from David Stone  ---
It looks like gcc behaves correctly, which can be seen by adding the line

auto x = compiles(0);

I wasn't actually instantiating the template, just looking at its return type.

This can be closed; sorry for the noise.

[Bug fortran/66052] New: Segmentation fault for misplaced protected statement

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052

Bug ID: 66052
   Summary: Segmentation fault for misplaced protected statement
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code fragment with interchanged lines
   module p
   contains
   protected x
   end

produces (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: Segmentation fault

Similar, but basically not legal in program, subroutine, ...
   program p
   contains
   protected x
   end

Or even ...
   program p
   end
   protected x
   end

Kind regards.

[Bug fortran/66050] ICE: FORALL with operation on matrix columns

[wangmianzhi1 at linuxmail dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66050

--- Comment #2 from Mianzhi Wang  ---
I may have made some mistake on the original example.
This should trigger the ICE (in some conditions, see below)

program test
  double precision::a(3,3),b
  b=1d0
  forall(i=1:3)
a(:,i)=b*[1d0,2d0,3d0]
  end forall
end program

-

It MIGHT be hardware-specific.
The ICE is not triggered on Intel i7-3770k with gcc 4.8.2.
But it is triggered on AMD A4-5000 with gcc 4.9.2.
I'm sorry that I can't provide results for other CPU/gcc combination.

-

The ICE is

test.f90: In function ‘test’:
test.f90:4:0: internal compiler error: in gfc_trans_forall_1, at
fortran/trans-stmt.c:4015
   forall(i=1:3)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/66051] New: can't vectorize reductions inside an SLP group

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051

Bug ID: 66051
   Summary: can't vectorize reductions inside an SLP group
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

void foo (int *p, short *q, int n)
{
  int i;
  for (i = 0; i < n; ++i)
{
  p[i*4+0] = q[i*8+0] + q[i*8+4];
  p[i*4+1] = q[i*8+1] + q[i*8+5];
  p[i*4+2] = q[i*8+2] + q[i*8+6];
  p[i*4+3] = q[i*8+3] + q[i*8+7];
}
}

is vectorized by unrolling the loop 4 times instead of using SLP because

t3.c:4:3: note: Build SLP for _15 = *_14;

t3.c:4:3: note: Build SLP failed: grouped loads have gaps _15 = *_14;

which isn't the whole story (I don't think we support this kind of
"reductions").  The SLP build runs into two load children, one loading
[0, 3] and one loading [4, 7] of a single group (and thus producing gaps).
Ideally we vectorize this with a single load of [0, 7], shuffle, add
and only unpack the low part.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug fortran/66050] ICE: FORALL with operation on matrix columns

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66050

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-07
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME for 4.8.4, 4.9.2, 5.1 and trunk (6.0).

Using built-in specs.
COLLECT_GCC=gfortran-fsf-4.9
COLLECT_LTO_WRAPPER=/sw64/lib/gcc4.9/libexec/gcc/x86_64-apple-darwin14.1.0/4.9.2/lto-wrapper
Target: x86_64-apple-darwin14.1.0
Configured with: ../gcc-4.9.2/configure --prefix=/sw64
--prefix=/sw64/lib/gcc4.9 --mandir=/sw64/share/man
--infodir=/sw64/lib/gcc4.9/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw64
--with-libiconv-prefix=/sw64 --with-isl=/sw64 --with-cloog=/sw64
--with-mpc=/sw64 --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9
Thread model: posix
gcc version 4.9.2 (GCC) 

What is the ICE?

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018

--- Comment #4 from Andreas Schwab  ---
What collect2 is looking for is configured during build, see the gcc/collect-ld
script in the build directory.

[Bug fortran/66050] New: ICE: FORALL with operation on matrix columns

[wangmianzhi1 at linuxmail dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66050

Bug ID: 66050
   Summary: ICE: FORALL with operation on matrix columns
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangmianzhi1 at linuxmail dot org
  Target Milestone: ---

The ICE is triggered when compiling the following (simplified) example with
"-O1" to "-Ofast".

program test
  double precision::a(3,3),b,c(3)
  b=1d0
  c=[1d0,2d0,3d0]
  forall(i=1:3)
a(:,i)=b*c(:)
  end forall
end program

---

gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[t at sharklasers dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029

--- Comment #9 from JD  ---
I reconfigured and recompiled binutils 2.25 with the --enable-plugins and
--enable-lto flags.

But I'm afraid I must be missing something: Linking with the newly compiled ld
2.25 works fine without lto but using it with lto produces undefined reference
errors.

[Bug rtl-optimization/66048] [i386] ICE in create_pre_exit when both AVX and MPX are used

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66048

--- Comment #1 from Uroš Bizjak  ---
(In reply to Ilya Enkovich from comment #0)
> Created attachment 35485 [details]
> reproducer
> 
> >gcc mode-switch.cc -march=corei7-avx -mmpx -fcheck-pointer-bounds -O2 -c
> 
> mode-switch.cc: In function 'c1 test.chkp(c2, #'pointer_bounds_type' not
> supported by dump_type#, void, ...)':
> mode-switch.cc:13:1: internal compiler error: in create_pre_exit, at
> mode-switching.c:464

There is a *very* picky assert in mode-switching.c that otherwise allows
various exceptions when expected sequence:

(set (reg X) ...)

(use (reg X))

is NOT found. But... you'll have to explain why certain exception is allowed.
In your case, a multi_reg_return condition triggered, so:

--cut here--
Index: mode-switching.c
===
--- mode-switching.c(revision 222869)
+++ mode-switching.c(working copy)
@@ -461,7 +461,10 @@ create_pre_exit (int n_entities, int *entity_map,
   This doesn't actually cause reload
   failures, so let it pass.  */
|| (GET_MODE_CLASS (GET_MODE (ret_reg)) != MODE_INT
-   && nregs != 1));
+   && nregs != 1)
+   /* Comment here.  */
+   || (multi_reg_return
+   && /* some tight condition */ 1));

if (!NOTE_INSN_BASIC_BLOCK_P (last_insn))
  {
--cut here--

Please note that this part of the code can make a grown man cry...

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #53 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #50)
> Created attachment 35478 [details]
> implement SYNC flag for memory model
> 
> This compiles on all targets, but is only runtime tested on
> x86_64-unknown-linux-gnu with no regressions.

The patch passes check-gcc for aarch64-none-linux-gnu with no new failures.
I'll also run the tests on arm.

> With this you should be able to easily issue whatever different insn
> sequence you need to within an atomic pattern.   Give it a try.  If it works
> as required, then we'll see about executing on all targets for testing...

I modified the Aarch64 backend to use the new is_mm_sync test to generate
stronger barriers when needed and it all works as required.

[Bug sanitizer/64839] libsanitizer shouldn't require

[thierry.reding at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

Thierry Reding  changed:

   What|Removed |Added

 CC||thierry.reding at gmail dot com

--- Comment #9 from Thierry Reding  ---
Is there something I can do to help move this along? I've tried to locally
backport Yury's changeset to the gcc-5-branch and the only conflict I get is in
ChangeLog and that's easy to fix up. I don't have commit access, though, so I
can't commit the result.

[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 66044 has been marked as a duplicate of this bug. ***

[Bug fortran/66044] ICE on misplaced entry statement

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres  ---
It looks like a duplicate of pr50539.

*** This bug has been marked as a duplicate of bug 50539 ***

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018

--- Comment #3 from chrbr at gcc dot gnu.org ---
having ld in the $(prefix)/$(triplet)/bin fixes the issue.

it seems that collect2 doesn't look for $(prefix)/bin/$(triplet)-ld as before

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #25 from Jürgen Reuter  ---
Just do the configuration without the --disable-ocaml flag (the default is 
that OCaml is enabled). The configure should show then something like that
(Ocamlweb is not needed):
configure: --
configure: --- Objective Caml checks ---
configure: 
checking for ocaml... /usr/local/bin/ocaml
checking for ocamlc... /usr/local/bin/ocamlc
OCaml version is 4.02.1
OCaml library path is /usr/local/lib/ocaml
checking for ocamlopt... /usr/local/bin/ocamlopt
checking for ocamlc.opt... /usr/local/bin/ocamlc.opt
checking for ocamlopt.opt... /usr/local/bin/ocamlopt.opt
checking for ocamldep... /usr/local/bin/ocamldep
checking for ocamlmktop... /usr/local/bin/ocamlmktop
checking for ocamlmklib... /usr/local/bin/ocamlmklib
checking for ocamldoc... /usr/local/bin/ocamldoc
checking for ocamlbuild... /usr/local/bin/ocamlbuild
checking for OCaml version 312000... ok
checking for ocamllex... /usr/local/bin/ocamllex
checking for ocamllex.opt... /usr/local/bin/ocamllex.opt
checking for ocamlyacc... /usr/local/bin/ocamlyacc
checking for ocamlcp... /usr/local/bin/ocamlcp
checking for ocamlweb... /usr/local/bin/ocamlweb
This is ocamlweb version 1.38, compiled on Sun Nov 9 16:08:42 CET 2014
Copyright (c) 1999-2000 Jean-Christophe Filli?tre and Claude March?
This is free software with ABSOLUTELY NO WARRANTY (use option -warranty)
This is ocamlweb version 1.38, compiled on Sun Nov 9 16:08:42 CET 2014
Copyright (c) 1999-2000 Jean-Christophe Filli?tre and Claude March?
This is free software with ABSOLUTELY NO WARRANTY (use option -warranty)
OCamlweb version is : ok
checking for OCaml/GTK+ toolkit directory... not found
checking for ocamldot... no
checking for ocamldefun... no

[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[vekumar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049

--- Comment #1 from vekumar at gcc dot gnu.org ---
We need patterns based on shifts to match with combiner generated.

Below patch fixes them.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 1c2c5fb..c5a640d 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1555,6 +1555,23 @@
   [(set_attr "type" "alus_shift_imm")]
 )

+(define_insn "*adds_shift_imm_"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (plus:GPI (ASHIFT:GPI
+(match_operand:GPI 1 "register_operand" "r")
+(match_operand:QI 2 "aarch64_shift_imm_" "n"))
+   (match_operand:GPI 3 "register_operand" "r"))
+ (const_int 0)))
+   (set (match_operand:GPI 0 "register_operand" "=r")
+(plus:GPI (ASHIFT:GPI (match_dup 1) (match_dup 2))
+  (match_dup 3)))]
+  ""
+  "adds\\t%0, %3, %1,  %2"
+  [(set_attr "type" "alus_shift_imm")]
+)
+
+
 (define_insn "*subs_mul_imm_"
   [(set (reg:CC_NZ CC_REGNUM)
(compare:CC_NZ
@@ -1571,6 +1588,23 @@
   [(set_attr "type" "alus_shift_imm")]
 )

+(define_insn "*subs_shift_imm_"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (minus:GPI (match_operand:GPI 1 "register_operand" "r")
+(ASHIFT:GPI
+ (match_operand:GPI 2 "register_operand" "r")
+ (match_operand:QI 3 "aarch64_shift_imm_" "n")))
+ (const_int 0)))
+   (set (match_operand:GPI 0 "register_operand" "=r")
+(minus:GPI (match_dup 1)
+   (ASHIFT:GPI (match_dup 2) (match_dup 3]
+  ""
+  "subs\\t%0, %1, %2,  %3"
+  [(set_attr "type" "alus_shift_imm")]
+)
+
+
 (define_insn "*adds__"
   [(set (reg:CC_NZ CC_REGNUM)
(compare:CC_NZ
@@ -1599,6 +1633,41 @@
   [(set_attr "type" "alus_ext")]
 )

+(define_insn "*adds__shft_"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (plus:GPI (ashift:GPI (ANY_EXTEND:GPI
+(match_operand:ALLX 1 "register_operand" "r"))
+   (match_operand 2 "aarch64_imm3" "Ui3"))
+   (match_operand:GPI 3 "register_operand" "r"))
+(const_int 0)))
+   (set (match_operand:GPI 0 "register_operand" "=rk")
+(plus:GPI (ashift:GPI (ANY_EXTEND:GPI (match_dup 1))
+  (match_dup 2))
+  (match_dup 3)))]
+  ""
+  "adds\\t%0, %3, %1, xt %2"
+  [(set_attr "type" "alus_ext")]
+)
+
+(define_insn "*subs__shft_"
+  [(set (reg:CC_NZ CC_REGNUM)
+(compare:CC_NZ
+ (minus:GPI (match_operand:GPI 1 "register_operand" "r")
+(ashift:GPI (ANY_EXTEND:GPI
+(match_operand:ALLX 2 "register_operand" "r"))
+   (match_operand 3 "aarch64_imm3" "Ui3")))
+(const_int 0)))
+   (set (match_operand:GPI 0 "register_operand" "=rk")
+(minus:GPI (match_dup 1)
+(ashift:GPI (ANY_EXTEND:GPI (match_dup 2))
+  (match_dup 3]
+  ""
+  "subs\\t%0, %1, %2, xt %3"
+  [(set_attr "type" "alus_ext")]
+)
+
+
 (define_insn "*adds__multp2"
   [(set (reg:CC_NZ CC_REGNUM)
(compare:CC_NZ
@@ -1909,6 +1978,22 @@
   [(set_attr "type" "alu_ext")]
 )

+(define_insn "*add_uxt_shift2"
+  [(set (match_operand:GPI 0 "register_operand" "=rk")
+(plus:GPI (and:GPI
+   (ashift:GPI (match_operand:GPI 1 "register_operand" "r")
+ (match_operand 2 "aarch64_imm3" "Ui3"))
+   (match_operand 3 "const_int_operand" "n"))
+  (match_operand:GPI 4 "register_operand" "r")))]
+  "aarch64_uxt_size (INTVAL (operands[2]), INTVAL (operands[3])) != 0"
+  "*
+  operands[3] = GEN_INT (aarch64_uxt_size (INTVAL(operands[2]),
+   INTVAL (operands[3])));
+  return \"add\t%0, %4, %1, uxt%e3 %2\";"
+  [(set_attr "type" "alu_ext")]
+)
+
+
 ;; zero_extend version of above
 (define_insn "*add_uxtsi_multp2_uxtw"
   [(set (match_operand:DI 0 "register_operand" "=rk")
@@ -2165,6 +2250,22 @@
   [(set_attr "type" "alu_ext")]
 )

+(define_insn "*sub_uxt_shift2"
+  [(set (match_operand:GPI 0 "register_operand" "=rk")
+(minus:GPI (match_operand:GPI 4 "register_operand" "rk")
+   (and:GPI
+(ashift:GPI (match_operand:GPI 1 "register_operand" "r")
+  (match_operand 2 "aarch64_imm3" "Ui3"))
+(match_operand 3 "const_int_operand" "n"]
+  "aarch64_uxt_size (INTVAL (operands[2]),INTVAL (operands[3])) != 0"
+  "*
+  operands[3] = GEN_INT (aarch64_uxt_size (INTVAL (operands[2]),
+   INTVAL (operands[3])));
+  return \"sub\t%0, %4, %1, uxt%e3 %2\";"
+  [(set_attr "type" "alu_ext")]
+)
+
+
 ;; zero_extend version of above
 (define_insn "*sub_uxtsi_multp2_uxtw"
   [(set (match_

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #24 from Dominique d'Humieres  ---
> That would be cool. If you have OCaml installed (version 3.12 or newer,
> and as a French you couldn't complain about that^^) you could run a lot more
> from the test suite.

I have

The OCaml toplevel, version 4.02.1

What should I do to use it?

[Bug target/66049] New: Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[vekumar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049

Bug ID: 66049
   Summary: Few AArch64 extend and add with shift tests generates
sub optimal code with trunk gcc 6.0.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vekumar at gcc dot gnu.org
  Target Milestone: ---

After preventing conversion of shift to mults in combiner
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222874

few Aarch64 target tests generates suboptimal code.

Tests that now fail, but worked before:
---
gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl
3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl
3
gcc.target/aarch64/adds3.c scan-assembler-times adds\tx[0-9]+, x[0-9]+,
x[0-9]+,
 sxtw 2
gcc.target/aarch64/extend.c scan-assembler add\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler add\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/extend.c scan-assembler sub\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/subs1.c scan-assembler subs\tw[0-9]+, w[0-9]+, w[0-9]+, lsl
3
gcc.target/aarch64/subs1.c scan-assembler subs\tx[0-9]+, x[0-9]+, x[0-9]+, lsl
3
gcc.target/aarch64/subs3.c scan-assembler-times subs\tx[0-9]+, x[0-9]+,
x[0-9]+,
 sxtw 2

Sample Test case 

unsigned long long
adddi_uxtw (unsigned long long a, unsigned int i)
{
  /* { dg-final { scan-assembler "add\tx\[0-9\]+,.*uxtw #?3" } } */
  return a + ((unsigned long long)i << 3);
}

Before 

 add x0, x0, x1, uxtw 3

Now 

ubfiz   x1, x1, 3, 32
add x0, x1, x0

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #23 from Jürgen Reuter  ---
That would be cool. If you have OCaml installed (version 3.12 or newer, and as
a French you couldn't complain about that^^) you could run a lot more from the
test suite.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #22 from Dominique d'Humieres  ---
> No this is not expected. There seems to be another problem inside
> gfortran 6.0.0 trunk. I cannot test things before tomorrow/weekend.

I will try with a tree with less patches.

[Bug fortran/66041] [6 Regression] Matmul ICE

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041

--- Comment #2 from Thomas Koenig  ---
Workaround: Use -finline-matmul-limit=0.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #21 from Jürgen Reuter  ---
No this is not expected. There seems to be another problem inside gfortran
6.0.0 trunk. I cannot test things before tomorrow/weekend.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #20 from Dominique d'Humieres  ---
> Patch submitted at:
>
> https://gcc.gnu.org/ml/fortran/2015-05/msg00025.html
>
> This patch also fixes the issue in comment #15.

With the submitted patch I have been able to build the whizard package. The
summary for 'make check' is


Testsuite summary for WHIZARD 2.2.6

# TOTAL: 280
# PASS:  60
# SKIP:  167
# XFAIL: 0
# FAIL:  53
# XPASS: 0
# ERROR: 0

Many failures are of the kind

FAIL: models.run


Running script ./models.run
| Writing log to 'models.log'
| 
| Running self-test: models
| 
Running test: models_1 ... success.
Running test: models_2| Reading model file
'/Users/dominiq/Downloads/whizard-2.2.6/share/models/Test.mdl'
whizard(55852,0x7fff72381300) malloc: *** error for object 0x7fff54a0a5e8:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Is this expected?

[Bug target/65326] LRA missing a Thumb optimization.

[renlin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65326

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #1 from renlin at gcc dot gnu.org ---
In this specific case, thumb_legitimize_address will generate ldr r0, [r9, r10]
pattern(after IRA). However, this pattern only allows LO_REGS. During reload, 
r9&r10 will be spilled into LO_REGS, that's where those two mov instructions
come from.

(In reply to Matthew Wahab from comment #0)
> Created attachment 34964 [details]
> Testcase showing change in behaviour.
> 
> The ARM backend no longer supports -mno-lra so only the LRA is available.
> This
> has also removed the Thumb mode optimiziation introduced in
> https://gcc.gnu.org/ml/gcc-patches/2005-08/msg01140.html to fix PR 23436.
> 
> This turns sequences like
>   mov r3, r9
>   mov r2, r10
>   ldr r0, [r3, r2]
> into
>   mov r3, r9
>   add r3, r3, r10
>   ldr r0, [r3]
> which saves a register.
> 
> Attached is a contrived test case. Compiling with gcc-4.9 with -mthumb
> -mno-lra 
> (at -O1 and higher) produces the second (better) sequence. Compiling with
> gcc-4.9 or gcc-trunk with -mthumb (at -O1 and higher) produces the first
> sequence. The sequences appear after the 'nop'
> 
> gcc-4.9 is 
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119
> (release) [ARM/embedded-4_9-branch revision 218278]
> 
> trunk is:
> arm-none-eabi-gcc (unknown) 5.0.0 20150217 (experimental)

[Bug middle-end/192] String literals don't obey -fdata-sections

[gcc at mattwhitlock dot name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192

--- Comment #15 from Matt Whitlock  ---
(In reply to Jakub Jelinek from comment #14)
> This doesn't really look like a good idea to me.  Instead, perhaps ld's
> --gc-sections or new special option should just remove unused string
> literals from mergeable sections.

I believe (I've read, but I haven't verified) that Gold already does this.

> With your patch, I bet you lose e.g. all tail merging.

Tail merging still works fine.

> Consider:
> const char *used1 () { return "foo bar baz blah blah"; }
> in one TU and
> const char *used2 () { return "bar baz blah blah"; }
> in another.

Okay, I'll use your example.

$ echo 'const char *used1 () { return "foo bar baz blah blah"; }' > tu1.c
$ echo 'const char *used2 () { return "bar baz blah blah"; }' > tu2.c
$ cat > main.c <

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #19 from Jürgen Reuter  ---
Of course, we are fine (or even happy) if you take our code examples for your
regression tests.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #18 from vehre at gcc dot gnu.org ---
Yes, it also fixes the ICE in #11. The code example is part of the regression
test added. I hope you don't mind. Most parts of the regression test added base
on your reported issues.

Additionally the whizard code mentioned in #1 is compiling and running again.

[Bug fortran/66041] [6 Regression] Matmul ICE

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #1 from Thomas Koenig  ---
Mine.

[Bug bootstrap/66038] SIGSEGV at stage 2 build/genmatch --gimple ../../gcc-5.1.0/gcc/match.pd

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc-darwin
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-07
 CC||rguenth at gcc dot gnu.org
   Host||powerpc-darwin
 Ever confirmed|0   |1
  Build||powerpc-darwin

--- Comment #2 from Richard Biener  ---
I think you may run into a host compiler issue?  (ISTR a similar bug for
darwin)

What is your host compiler?  I suppose ppc-darwin still uses gcc 4.2.x, right?

[Bug fortran/66041] [6 Regression] Matmul ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[6.0 Regression] Matmul ICE |[6 Regression] Matmul ICE

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

--- Comment #17 from Jürgen Reuter  ---
(In reply to vehre from comment #16)
> Patch submitted at:
> 
> https://gcc.gnu.org/ml/fortran/2015-05/msg00025.html
> 
> This patch also fixes the issue in comment #15.

First of all, thanks for the efforts. Does this also fix the ICE in #11?