[Bug c++/66067] New: tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574

[jamrial at gmail dot com]

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

Bug ID: 66067
   Summary: tree check ICE: accessed elt 1 of tree_vec with 0 elts
in write_template_args, at cp/mangle.c:2574
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 35494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35494&action=edit
Preprocessed source as generated by -freport-bug

In file included from
/home/jamrial/range-v3/include/range/v3/range_fwd.hpp:19:0,
 from /home/jamrial/range-v3/include/range/v3/begin_end.hpp:21,
 from /home/jamrial/range-v3/include/range/v3/core.hpp:17,
 from /home/jamrial/range-v3/test/container_conversion.cpp:17:
/home/jamrial/range-v3/include/meta/meta.hpp: In instantiation of ‘constexpr
const size_t
meta::v1::detail::reverse_find_index_, ranges::v3::default_sentinel>,
ranges::v3::iter_transform_view > >::adaptor >,
ranges::v3::adaptor_sentinel,
ranges::v3::adaptor_base> >&, const long int&>, 0>,
meta::v1::defer, ranges::v3::default_sentinel>,
ranges::v3::iter_transform_view > >::adaptor >,
ranges::v3::adaptor_sentinel,
ranges::v3::adaptor_base> >&, const long int&> >, std::integral_constant > > >, const long int&>::i’:
/home/jamrial/range-v3/test/container_conversion.cpp:62:1:   required from here
/home/jamrial/range-v3/include/meta/meta.hpp:1645:46: internal compiler error:
tree check: accessed elt 1 of tree_vec with 0 elts in write_template_args, at
cp/mangle.c:2574
 static constexpr std::size_t i = List::size() -
reverse_find::size();
  ^
0xeefa55 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
/home/jamrial/gcc-6-20150506/gcc/tree.c:9517
0x78e1ff tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
/home/jamrial/gcc-6-20150506/gcc/tree.h:3073
0x78e1ff write_template_args
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2574
0x78ee60 write_nested_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:1005
0x78cf71 write_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910
0x78ddf9 write_template_template_arg
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3210
0x78ddf9 write_template_arg
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3171
0x78e0f8 write_template_args
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582
0x78ee4d write_nested_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997
0x78cf71 write_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910
0x78a5d6 write_class_enum_type
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2553
0x78a5d6 write_type
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2010
0x78e0f8 write_template_args
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582
0x78ee4d write_nested_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997
0x78cf71 write_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910
0x78a5d6 write_class_enum_type
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2553
0x78a5d6 write_type
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2010
0x78db44 write_template_arg
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3164
0x78e0f8 write_template_args
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582
0x78ee4d write_nested_name
/home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997

[Bug target/48904] x86_64-knetbsd-gnu fails to build

[aldot at gcc dot gnu.org]

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

--- Comment #4 from Bernhard Reutner-Fischer  ---
Author: aldot
Date: Fri May  8 07:33:42 2015
New Revision: 222903

URL: https://gcc.gnu.org/viewcvs?rev=222903&root=gcc&view=rev
Log:
PR target/48904 x86_64-knetbsd-gnu missing defs

2015-05-08  H.J. Lu  
Bernhard Reutner-Fischer  

PR target/48904
* config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
* config/i386/knetbsd-gnu64.h: New file.


Added:
trunk/gcc/config/i386/knetbsd-gnu64.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Yes, that is expected (in C99!).  See
.  New tests
c90-left-shift-1.c and c99-left-shift-1.c explicitly test such behavior.

[Bug c/66068] New: error: type variant has different TYPE_VFIELD

[dcb314 at hotmail dot com]

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

Bug ID: 66068
   Summary: error: type variant has different TYPE_VFIELD
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35495&action=edit
C source code

The attached code, when compiled by gcc trunk dated 20150506
and with flag -g, says this:

udns_resolver.c: In function ‘dns_new’:
udns_resolver.c:474:1: error: type variant has different TYPE_VFIELD

...

udns_resolver.c:474:1: internal compiler error: verify_type failed
0xe3782b verify_type(tree_node const*)
../../src/trunk/gcc/tree.c:12695
0x7de490 gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20247
0x7cede2 gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20334
0x7cd756 gen_type_die
../../src/trunk/gcc/dwarf2out.c:20431

[Bug c/66066] [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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #1)
> Yes, that is expected (in C99!).  See
> .  New tests
> c90-left-shift-1.c and c99-left-shift-1.c explicitly test such behavior.

Hmm, that looks quite unfortunate from a qoi standpoint.
It will break tons of existing code.

[Bug target/48904] x86_64-knetbsd-gnu fails to build

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

  Known to work||6.0

--- Comment #5 from Bernhard Reutner-Fischer  ---
Fixed on the trunk.

[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 #54 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #53)
> (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.
> 

Also passes check-gcc for arm-none-eabi.

[Bug debug/66069] New: New -fkeep-all-method-instances

[jan.kratochvil at redhat dot com]

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

Bug ID: 66069
   Summary: New -fkeep-all-method-instances
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---
Target: x86_64-linux-gnu

For debugging (-O0 -g) code there could be a way to provide all instantiable
methods for TYPE when anything from template gets used.  The problem:

---
1   #include 
2   class C { public: int i; };
3   int main() {
4 std::unique_ptr cp(new C());
5 return cp->i;
6   }
(gdb) p cp
$1 = std::unique_ptr containing 0x603010
(gdb) p *cp
Could not find operator*.
---
compiled-in:
std::unique_ptr >::get() const
std::unique_ptr >::get_deleter()
std::unique_ptr >::operator->() const
std::unique_ptr >::unique_ptr(C*)
std::unique_ptr >::~unique_ptr()
---

The current workaround:
---
1   #include 
2   class C { public: int i; };
3   int main() {
4 std::unique_ptr cp(new C());
5 __attribute__((unused)) const C &gdbstub(*cp);
  ^^
6 return cp->i;
7   }
(gdb) p *cp
$1 = (C &) @0x603010: {i = 0}
---
added method:
std::unique_ptr >::operator*() const
---

Similar problems are with operator[], operator-> for maps etc.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
The reason is that -1 << 0 is UB in C99, and we should reject the program only
when the invalid shift is happening in a context where a constant expression is
required.

But if it turns out to break too many packages, I guess we'll have to revisit
;(.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8.4 up to trunk (6.0).

[Bug debug/66069] New -fkeep-all-method-instances

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|6.0 |5.1.1
 Resolution|--- |INVALID

--- Comment #1 from Jan Kratochvil  ---
PASS: gcc-5.1.1-1.fc22.x86_64
FAIL: gcc-4.9.2-6.fc21.x86_64

It is in fact already fixed thanks to Python xmethods.

The option would still make some sense for custom non-libstdc++ templates if
one does not write xmethods for them but that has probably only marginal
usefulness.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
You can always make it a -pedantic error only...

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
  Known to work||4.9.0
Version|4.7.1   |4.8.4
 Resolution|--- |FIXED
  Known to fail||4.6.4, 4.7.3

--- Comment #1 from Richard Biener  ---
Confirmed, not a regression though, thus fixed.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #38 from Frédéric Buclin  ---
I can confirm the regression. I reported this issue upstream:

https://bugzilla.mozilla.org/show_bug.cgi?id=1162914

Thanks Markus for catching that! :)

[Bug tree-optimization/66070] New: cc1 gets killed by OOM killer

[steffen at hauihau dot de]

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

Bug ID: 66070
   Summary: cc1 gets killed by OOM killer
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steffen at hauihau dot de
  Target Milestone: ---

Created attachment 35496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35496&action=edit
preprocessed source

Compiling a 32 bit version libaacplus 2.0.2 failed after some time because the
lto1 process for one of the ltrans portions gets killed by the kernel OOM
killer. I've then disabled LTO for the build and detected, that the cc1 process
compiling fram_gen.c gets also killed by the OOM killer. I went on by lastly
disabling graphite and the file compiled fine independent of LTO enabled or
disabled.

Here is the cmdline which leads to the OOM invocation (LTO disabled):
gcc -m32 -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine
-floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize
-ftree-loop-linear -flto=5 -fuse-linker-plugin -fno-lto -c fram_gen.i  -fPIC
-DPIC -o /dev/null

Please let me know if and how I can help you further.

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

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
(In reply to Uroš Bizjak from comment #1)
> There is a *very* picky assert in mode-switching.c that otherwise allows
> various exceptions when expected sequence:
> 
> (set (reg X) ...)
> 
> (use (reg X))

With MPX we have multiple (use (reg X)) and only the last one is examined. It
is always the one created for bounds.  Simple swap makes it work.  With this
patch test passes:

--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5224,8 +5224,8 @@ diddle_return_value_1 (void (*doit) (rtx, void *), void
*arg, rtx outgoing)
 void
 diddle_return_value (void (*doit) (rtx, void *), void *arg)
 {
-  diddle_return_value_1 (doit, arg, crtl->return_rtx);
   diddle_return_value_1 (doit, arg, crtl->return_bnd);
+  diddle_return_value_1 (doit, arg, crtl->return_rtx);
 }

 static void

[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 #3 from Matt Thompson  ---
(In reply to kargl from comment #2)
> (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.

Ahh. Okay, thanks. It might be nice to put a reference to -x in the gfortran
manpage. It always confuses me that some Fortran options are only visible in
the gcc manpage...

[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 #29 from Dominique d'Humieres  ---
> Dominique, comment #27 looks perfect. That would be great for us
> with the upcoming revision of gfortran 6.0.0.

First, obviously Andre's test gfortran.dg/elemental_subroutine_11.f90 does not
cover all the possible issues. How difficult would it be to infer what is
missing from the list of failures?

Second, I have done some tests with the addition of pending patches:

(1) Mikael's patch + combined patch for pr61831&65792 + patches for pr64674 and
pr65548,

(2) Mikael's patch + patches for pr44672, pr58586, pr64674 and pr65548.

While I get the results of comment 27 with (1), I get the following result with
(2)


Testsuite summary for WHIZARD 2.2.6

# TOTAL: 280
# PASS:  70
# SKIP:  28
# XFAIL: 1
# FAIL:  179
# XPASS: 2
# ERROR: 0

[Bug c++/66071] New: Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[tomas.ukkonen at iki dot fi]

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

Bug ID: 66071
   Summary: Calling condition variable's notify_all() causes
SEGFAULT when the binary is statically linked
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas.ukkonen at iki dot fi
  Target Milestone: ---

Created attachment 35497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35497&action=edit
Example code causing segmentation fault

The following code causes segmentation fault on Debian Linux (Sid) WHEN THE
BINARY IS STATICALLY LINKED. Code works correctly when the binary is linked
dynamically:

#include 

int main()
{
  std::condition_variable cv;
  cv.notify_all();
  return 0;
}

Commands:

g++ -v -save-temps -std=c++11 -static test.cpp
./a.out
Segmentation fault

uname -a
Linux moria 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23) x86_64
GNU/Linux

gcc -v
gcc version 4.9.2 (Debian 4.9.2-10)

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[tomas.ukkonen at iki dot fi]

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

--- Comment #1 from Tomas Ukkonen  ---
Created attachment 35498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35498&action=edit
compilation results 1

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[tomas.ukkonen at iki dot fi]

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

--- Comment #2 from Tomas Ukkonen  ---
Created attachment 35499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35499&action=edit
Compilation results 2

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[tomas.ukkonen at iki dot fi]

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

Tomas Ukkonen  changed:

   What|Removed |Added

 CC||tomas.ukkonen at iki dot fi

--- Comment #3 from Tomas Ukkonen  ---
Created attachment 35500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35500&action=edit
Shell script compiling the code and causing segmentation fault

[Bug c++/66072] New: Trying to compile a makefile in c++, error in Description

[rstrankle1 at gmail dot com]

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

Bug ID: 66072
   Summary: Trying to compile a makefile in c++, error in
Description
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rstrankle1 at gmail dot com
  Target Milestone: ---

#0  0x775079bc in free () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00401359 in addPolicy(int, int (*) [5], int&) ()
#2  0x004017c0 in fillUpPolicyRiskTable(int (*) [5], int&) ()
#3  0x00401b29 in main ()

[Bug debug/66069] New -fkeep-all-method-instances

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Jan Kratochvil from comment #1)
> The option would still make some sense for custom non-libstdc++ templates if
> one does not write xmethods for them but that has probably only marginal
> usefulness.

'compile print' in C++ will fix that, no?

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

[lukacs at topgroups dot ca]

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

--- Comment #4 from Gabor Lukacs  ---
The following patch makes the problem go away insofar as bootstrap is
concerned:

http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02510.html

"This patch to libgo, from Peter Collingbourne, changes some of the C
code to make it easier to compile libgo with a compiler other than GCC."

[Bug debug/66069] New -fkeep-all-method-instances

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 CC||pmuldoon at redhat dot com

--- Comment #3 from Jan Kratochvil  ---
I think so but that would require the source files available.

So far 'compile print' (for C) generates all the context only from DWARF - this
case was this PR's goal.

The source files may not match well for *-debuginfo.rpm packaged binaries but
IMO there is no chance for more complex debugging due to the -O2 -g debug info
limitations.

[Bug fortran/66073] New: [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 66073
   Summary: [6 Regression] 465.tonto in SPEC CPU 2006 failed to
build
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x32, r222889 gave

Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x32/spec/benchspec/CPU2006/465.tonto/build/build_base_lnxx32-gcc./make.err'
  Error with make!
*** Error building 465.tonto
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x32/spec/benchspec/CPU2006/465.tonto/build/build_peak_lnxx32-gcc./make.err'
  Error with make!
*** Error building 465.tonto
Build errors: 465.tonto(base; CE), 465.tonto(peak; CE)
Error: 2x465.tonto

[Bug jit/66074] New: gcc_jit_result_get_code returns a void*

[dr...@draconic-bytes.de]

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

Bug ID: 66074
   Summary: gcc_jit_result_get_code returns a void*
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dr...@draconic-bytes.de
  Target Milestone: ---

The problem with this is, that the ISO C and C++ standards do not guarantee,
that object pointers (like void*) and function pointers (like void(*)(void))
can be converted to each other.

Basically a void* might be too small to hold the address of a function on a
specific operating system or processor architecture.

The dlsym function from the POSIX standard has the same defect, which is also
documented:
http://pubs.opengroup.org/onlinepubs/009695399/functions/dlsym.html
See the section "RATIONALE".

This is also a nice explanatory article about that issue:
http://www.trilithium.com/johan/2004/12/problem-with-dlsym/

In the end there would be a need for two functions: one returning a function
pointer and one returning an object pointer.
But that is not a problem for gccjit as gcc_jit_result_get_global already exist
for querying object pointers.
So gcc_jit_result_get_code could easily be changed to return a function
pointer.

[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 #3 from Uroš Bizjak  ---
(In reply to Ilya Enkovich from comment #2)
> (In reply to Uroš Bizjak from comment #1)
> > There is a *very* picky assert in mode-switching.c that otherwise allows
> > various exceptions when expected sequence:
> > 
> > (set (reg X) ...)
> > 
> > (use (reg X))
> 
> With MPX we have multiple (use (reg X)) and only the last one is examined.
> It is always the one created for bounds.  Simple swap makes it work.  With
> this patch test passes:

Yes, this could also work. BND registers do not (and should not) require any
mode switching, while return reg could need mode switch. So, return reg should
be the last one.

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Can you run gdb to see where the crash is? This might be a glibc "issue" by
including only part of pthread library.

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[tomas.ukkonen at iki dot fi]

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

Tomas Ukkonen  changed:

   What|Removed |Added

Version|4.9.2   |5.1.1

--- Comment #5 from Tomas Ukkonen  ---
Tested with 5.1.1 and it creates Segmentation fault.

[Bug libstdc++/61458] std::aligned_storage is bigger than expected

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Paolo Carlini from comment #4)
> Hi Jon. Frankly Are you 100% sure (in terms of middle-end/back-end details)
> that the maximum alignment supported for a type of less than 4 bytes is 4?

It's a good question, I'm definitely not 100% sure.

[Bug c++/66072] Trying to compile a makefile in c++, error in Description

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a useful bug report, please read https://gcc.gnu.org/bugs/ and
please explain what you're doing (you cannot "compile a makefile in c++" that
doesn't mean anything).

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tomas.ukkonen at iki dot fi

--- Comment #2 from Jonathan Wakely  ---
*** Bug 66071 has been marked as a duplicate of this bug. ***

[Bug c++/66071] Calling condition variable's notify_all() causes SEGFAULT when the binary is statically linked

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
This is almost certainly the same issue as PR58909

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

[Bug tree-optimization/66036] strided group loads are not vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 66036 Summary: strided group loads are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036

   What|Removed |Added

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

[Bug tree-optimization/66036] strided group loads are not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri May  8 15:13:55 2015
New Revision: 222914

URL: https://gcc.gnu.org/viewcvs?rev=222914&root=gcc&view=rev
Log:
2015-05-08  Richard Biener  

PR tree-optimization/66036
* tree-vect-data-refs.c (vect_compute_data_ref_alignment):
Handle strided group loads.
(vect_verify_datarefs_alignment): Likewise.
(vect_enhance_data_refs_alignment): Likewise.
(vect_analyze_group_access): Likewise.
(vect_analyze_data_ref_access): Likewise.
(vect_analyze_data_ref_accesses): Likewise.
* tree-vect-stmts.c (vect_model_load_cost): Likewise.
(vectorizable_load): Likewise.

* gcc.dg/vect/slp-41.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/slp-41.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-stmts.c

[Bug fortran/66073] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/66058] Backslash in comment kills compile

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Fri, May 08, 2015 at 12:31:39PM +, matthew.thompson at nasa dot gov
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66058
> 
> --- Comment #3 from Matt Thompson  ---
> (In reply to kargl from comment #2)
> > (In reply to Matt Thompson from comment #1)
> > > 
> > > I've tried various gfortran flags, but for the life of me, none seem to 
> > > get
> > > this to work.
> > 
> > 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.
> 
> Ahh. Okay, thanks. It might be nice to put a reference to -x in the gfortran
> manpage. It always confuses me that some Fortran options are only visible in
> the gcc manpage...
> 

gfortran supports most (all?) of the options that gcc supports.
It was decided to not reproduce the gcc manual within the gfortran
manual.  You'll find in Sec. 2, this statement:

   The 'gfortran' command supports all the options supported by the 'gcc'
   command.  Only options specific to GNU Fortran are documented here.

In looking through Sec. 1.3 that details the .F behaviour, I find

   Many Fortran compilers including GNU Fortran allow passing the source
   code through a C preprocessor (CPP; sometimes also called the Fortran
   preprocessor, FPP) to allow for conditional compilation.  In the case
   of GNU Fortran, this is the GNU C Preprocessor in the traditional mode.
   On systems with case-preserving file names, the preprocessor is
   automatically invoked if the filename extension is '.F', '.FOR', '.FTN',
   '.fpp', '.FPP', '.F90', '.F95', '.F03' or '.F08'.  To manually invoke
   the preprocessor on any file, use '-cpp', to disable preprocessing on
   files where the preprocessor is run automatically, use '-nocpp'.

so the -nocpp option should also work.

[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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00685.html

[Bug rtl-optimization/66075] New: [6.0 regression] FAIL: gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3

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

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

Bug ID: 66075
   Summary: [6.0 regression] FAIL: gcc.target/aarch64/adds1.c
scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: naveenh at gcc dot gnu.org, vekumar at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

FAIL: gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+,
w[0-9]+, lsl 3
FAIL: gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+,
x[0-9]+, lsl 3

--- gcc-20150507/Build/adds1.s  2015-05-08 18:01:52.723445982 +0200
+++ gcc-20150508/Build/adds1.s  2015-05-08 18:01:41.383829842 +0200
@@ -30,8 +30,8 @@
.global adds_si_test3
.type   adds_si_test3, %function
 adds_si_test3:
-   addsw3, w0, w1, lsl 3
-   beq .L13
+   add w3, w0, w1, lsl 3
+   cbz w3, .L13
add w0, w1, w3
 .L13:
add w0, w0, w2
@@ -66,8 +66,8 @@
.global adds_di_test3
.type   adds_di_test3, %function
 adds_di_test3:
-   addsx3, x0, x1, lsl 3
-   beq .L25
+   add x3, x0, x1, lsl 3
+   cbz x3, .L25
add x0, x1, x3
 .L25:
add x0, x0, x2
@@ -209,5 +209,5 @@
 .L28:
bl  abort
.size   main, .-main
-   .ident  "GCC: (GNU) 6.0.0 20150507 (experimental)"
+   .ident  "GCC: (GNU) 6.0.0 20150508 (experimental)"
.section.note.GNU-stack,"",%progbits

fabf26080cb4cc3fecd30d409ec9c63f0ec42eff is the first bad commit
commit fabf26080cb4cc3fecd30d409ec9c63f0ec42eff
Author: vekumar 
Date:   Thu May 7 10:47:54 2015 +

2015-05-07  Venkataramanan Kumar  

* combine.c (make_compound_operation): Remove checks for PLUS/MINUS
rtx type.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222874
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug rtl-optimization/66075] [6.0 regression] FAIL: gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Dup, I think

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

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
*** Bug 66075 has been marked as a duplicate of this bug. ***

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

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #4 from Steve Ellcey  ---
This change caused 66066

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

[Bug fortran/66073] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
It is caused by r222864:

gfortran -c -o cluster.fppized.o -O2 -ffast-math cluster.fppized.f90
cluster.fppized.f90:1199:0:

in_pos =
matmul(self%crystal%unitcell%direct_matrix,self%geometry(:,in_atom))
 1
internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.c:8900
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake: *** [cluster.fppized.o] Error 1
specmake: *** Waiting for unfinished jobs

[Bug fortran/66073] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
It could be a duplicate of pr66041. Could you try the patch in comment #3?

[Bug fortran/66073] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from H.J. Lu  ---
Dup.

[Bug target/66076] New: [5/6 Regression] ICE: in vec_safe_grow, at vec.h:618 with -funroll-loops -mno-prefer-avx128 -march=bdver4

[zsojka at seznam dot cz]

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

Bug ID: 66076
   Summary: [5/6 Regression] ICE: in vec_safe_grow, at vec.h:618
with -funroll-loops -mno-prefer-avx128 -march=bdver4
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Compiler output:
$ gcc -O2 -ftree-loop-vectorize -funroll-loops -mno-prefer-avx128 -march=bdver4
testcase.c
testcase.c: In function 'f0a':
testcase.c:7:1: internal compiler error: in vec_safe_grow, at vec.h:618
 }
 ^
0xafa2c0 void vec_safe_grow(vec*&, unsigned int)
/mnt/svn/gcc-trunk/gcc/vec.h:618
0xafa2c0
generic_subrtx_iterator::add_single_to_queue(generic_subrtx_iterator::array_type&,
rtx_def const**, unsigned long, rtx_def const*)
/mnt/svn/gcc-trunk/gcc/rtlanal.c:107
0xafa499
generic_subrtx_iterator::add_subrtxes_to_queue(generic_subrtx_iterator::array_type&,
rtx_def const**, unsigned long, rtx_def const*)
/mnt/svn/gcc-trunk/gcc/rtlanal.c:174
0xe48b34 generic_subrtx_iterator::next()
/mnt/svn/gcc-trunk/gcc/rtl-iter.h:196
0xe48b34 ix86_loop_unroll_adjust
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:51449
0x9cdcb3 decide_unroll_constant_iterations
/mnt/svn/gcc-trunk/gcc/loop-unroll.c:403
0x9cdcb3 decide_unrolling
/mnt/svn/gcc-trunk/gcc/loop-unroll.c:293
0x9cdcb3 unroll_loops(int)
/mnt/svn/gcc-trunk/gcc/loop-unroll.c:311
0x9baa5f execute
/mnt/svn/gcc-trunk/gcc/loop-init.c:611
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Tested revisions:
r222902 - ICE
5 r222437 - ICE
4_9 r222436 - OK

[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #5 from Vladimir Makarov  ---
Created attachment 35502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35502&action=edit
ira-hook.patch

Here is the patch introducing the hook.  Could you try it and give me your
opinion.  Thanks.

[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #5)
> Created attachment 35502 [details]
> ira-hook.patch
> 
> Here is the patch introducing the hook.  Could you try it and give me your
> opinion.  Thanks.

Sorry, wrong place.  Please ignore the patch.

[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 #9 from Vladimir Makarov  ---
Created attachment 35503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35503&action=edit
ira-hook.patch

Here is the patch.  Could you try it and give me your opinion about it. 
Thanks.

[Bug c/66077] New: Right shift calculation error

[mike.jost at hp dot com]

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

Bug ID: 66077
   Summary: Right shift calculation error
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike.jost at hp dot com
  Target Milestone: ---

Curious right shift calculation error. I have used this sequence many times in
de Bruijn sequence calc to count trailing zeros. simplified to basic steps. Not
sure if this is a linux VM issue or compiler issue.

This same code works
using Quincy 2205 v1.3 05-Feb-2008
MinGW GCC version 4.2.1 on windows platform

fails with.
version:
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enax
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) 


Linux VM
$ uname -a
Linux hpnsw019.rose.hp.com 2.6.32-504.12.2.el6.centos.plus.x86_64 #1 SMP Thu
Mar 12 18:39:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


#include 

int main(int argc, char **argv)
{
   unsigned long w  = 64UL;
   unsigned long x  = 0xF12B3740UL;
   unsigned long y  = 0UL;
   unsigned long z  = 0UL;
   unsigned long a  = 0UL;


   y = (w * 0x07C4ACDDUL); /* = 0xF12B3740UL */
   z = y >> 27UL;
   a = x >> 27UL;

   printf("w = %lu\n",w);
   printf("x = 0x%X\n", x);
   printf("y = 0x%X\n", y);
   printf("z = %lu\n", z);
   printf("a = %lu\n", a);
}

output:
w = 64
x = 0xF12B3740
y = 0xF12B3740
z = 62
a = 30


z and a should be the same (30).

[Bug c/66077] Right shift calculation error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Your X and Y are not correctly displaying.

The correct values are:
x = 0xF12B3740
y = 0x1F12B3740


You should be using %lX rather than %X to display unsigned long.

Like:
   printf("x = 0x%lX\n", x);
   printf("y = 0x%lX\n", y);

As you can see there is another bit set in the upper 32bits which causes the
difference.

[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 #30 from Dominique d'Humieres  ---
While the Mikael's patch allows the test suite to run as expected, adding the
patch for pr58586 breaks it again.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #39 from Frédéric Buclin  ---
Bug fixed upstream, and here. :)

[Bug c/66077] Right shift calculation error

[mike.jost at hp dot com]

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

--- Comment #2 from Mike Jost  ---
Thanks for the explanation! Bit by the 64 bit. That will teach me to use
uint32_t instead of assuming 32 for unsigned long. I've been running on 32 bit
embedded targets for too long!


Regards,
Michael Jost
mike.j...@hp.com
Software Engineer
Object Technology Solutions, Inc. (OTSI) contractor
HP Roseville - R3U Q8
(916) 785-2815



-Original Message-
From: pinskia at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Friday, May 08, 2015 11:40 AM
To: Jost, Mike (OTSI Contractor)
Subject: [Bug c/66077] Right shift calculation error

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  --- Your X and Y
are not correctly displaying.

The correct values are:
x = 0xF12B3740
y = 0x1F12B3740


You should be using %lX rather than %X to display unsigned long.

Like:
   printf("x = 0x%lX\n", x);
   printf("y = 0x%lX\n", y);

As you can see there is another bit set in the upper 32bits which causes the
difference.

--
You are receiving this mail because:
You reported the bug.

[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 #31 from Jürgen Reuter  ---
Shall I do any checks now? It seems that Mikael's patch is doing the right
thing, and you found the one that breaks it again.

[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 #40 from Markus Trippelsdorf  ---
Thanks for the quick fix.

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00742.html

[Bug libstdc++/66078] New: 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11

[jason at gcc dot gnu.org]

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

Bug ID: 66078
   Summary: 20_util/specialized_algorithms/uninitialized_copy/8085
90.cc fails with -std=c++11
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
  Target Milestone: ---

When compiled with -std=c++11, vector::_M_default_append ends up calling the
template constructor for moving from the old array to the new one.  This seems
wrong as well as inconsistent with C++98; I would expect that the construction
should be from T&& or const T&, not T&.

This failed as far back as 4.7; I have not tested with earlier libraries.

[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
We've discussed this on the libstdc++ list and I have a fix ready.

[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 #5 from Jason Merrill  ---
Author: jason
Date: Fri May  8 21:15:21 2015
New Revision: 222927

URL: https://gcc.gnu.org/viewcvs?rev=222927&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:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alignas4.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c
branches/gcc-5-branch/gcc/cp/parser.c
branches/gcc-5-branch/gcc/cp/pt.c

[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

  Attachment #35491|0   |1
is obsolete||

--- Comment #4 from Thomas Koenig  ---
Created attachment 35504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35504&action=edit
Better patch

[Bug c/66077] Right shift calculation error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Mike Jost from comment #2)
> Thanks for the explanation! Bit by the 64 bit. That will teach me to use
> uint32_t instead of assuming 32 for unsigned long. I've been running on 32
> bit embedded targets for too long!

Or compile your code with -Wformat or simply -Wall, like the bug reporting
instructions say. How can we make this even clearer? Perhaps some big, red,
blinking text would help? ;-)

test.c:18:5: warning: format ‘%X’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘long unsigned int’ [-Wformat=]
 printf("x = 0x%X\n", x);
 ^
test.c:19:5: warning: format ‘%X’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘long unsigned int’ [-Wformat=]
 printf("y = 0x%X\n", y);
 ^

[Bug fortran/66079] New: [6.0 Regression] memory leak with source allocation in internal subprogram

[damian at sourceryinstitute dot org]

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

Bug ID: 66079
   Summary: [6.0 Regression] memory leak with source allocation in
internal subprogram
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

This leak is superficially similar to Bug 65925, which was reported against GCC
5.0 20150216.  The code below, however, exhibits no leak when compiled with the
aforementioned version and therefore appears to expose a regression in GCC 6.0
20150503.

Also, the code below is much simpler. Unlike the code in 65925, the code below
uses no  polymorphism, no type extension, no function (only a subroutine with
no arguments), only one explicit "allocate", and only one derived type.  Also,
the procedure that invokes "allocate" is called inside a block construct and no
variables are declared in the main program scope.  

FYI, wrapping the "call newRealVec" in a loop increases the reported leak by 4
bytes for every loop iteration.

Damian

$ cat source-allocation.f90 
  type subdata
integer, allocatable :: b
  endtype
  block 
call newRealVec
  end block
contains
  subroutine newRealVec 
type(subdata), allocatable :: d
allocate(d,source=subdata()) ! definitely lost 
  end subroutine
end 
$ gfortran source-allocation.f90 
$ valgrind ./a.out
==6209== Memcheck, a memory error detector
==6209== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==6209== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6209== Command: ./a.out
==6209== 
==6209== 
==6209== HEAP SUMMARY:
==6209== in use at exit: 4 bytes in 1 blocks
==6209==   total heap usage: 27 allocs, 26 frees, 12,718 bytes allocated
==6209== 
==6209== LEAK SUMMARY:
==6209==definitely lost: 4 bytes in 1 blocks
==6209==indirectly lost: 0 bytes in 0 blocks
==6209==  possibly lost: 0 bytes in 0 blocks
==6209==still reachable: 0 bytes in 0 blocks
==6209== suppressed: 0 bytes in 0 blocks
==6209== Rerun with --leak-check=full to see details of leaked memory
==6209== 
==6209== For counts of detected and suppressed errors, rerun with: -v
==6209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$ gfortran --version
GNU Fortran (GCC) 6.0.0 20150503 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.

[Bug c++/66080] New: incorrect debug info for CTOR

[chihin.ko at oracle dot com]

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

Bug ID: 66080
   Summary: incorrect debug info for CTOR
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com
  Target Milestone: ---

Created attachment 35505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35505&action=edit
test case

for attach delegating_constructors.cc test case,
due to incorrect debug info, gdb behave strange:
can't stop at line bpt:

(gdb) b 15
Breakpoint 1 at 0x4009d2: file delegating_constructors.cc, line 15.
(gdb) b 16
Breakpoint 2 at 0x400a07: file delegating_constructors.cc, line 16.
(gdb) b 20
Breakpoint 3 at 0x400a3a: file delegating_constructors.cc, line 20.
(gdb) run
Starting program:
/workspace/chko/ws/dinstall/intel_S11_gcc482/delegating_constructors.dbx,gcc/intel-Linux/a.out
Error in re-setting breakpoint 1: Function
"/workspace/chko/ws/dinstall/intel_S11_gcc482/delegating_constructors.dbx" not
defined.
Error in re-setting breakpoint 2: Function
"/workspace/chko/ws/dinstall/intel_S11_gcc482/delegating_constructors.dbx" not
defined.
Error in re-setting breakpoint 3: Function
"/workspace/chko/ws/dinstall/intel_S11_gcc482/delegating_constructors.dbx" not
defined.
a:
x=1
y=2.00
z=3
st=4
arr:
x=1
y=2.00
z=3
st=4
x=1
y=2.00
z=3
st=4
a2:
x=11
y=22.00
z=33
st=77
[Inferior 1 (process 7687) exited normally]
(gdb) quit

here is one example in dwarf dump:

< 2><0x0052>  DW_TAG_subprogram
DW_AT_external  yes(1)
DW_AT_name  "St"
DW_AT_decl_file 0x0001
delegating_constructors.cc
DW_AT_decl_line 0x0006
DW_AT_declaration   yes(1)
...
...
< 1><0x01c5>DW_TAG_subprogram
  DW_AT_specification <0x0052> <== shouldn't
point to "St"
  DW_AT_inlineDW_INL_declared_not_inlined
  DW_AT_object_pointer<0x01d3>
  DW_AT_sibling   <0x01e6>
...
...
< 1><0x01eb>DW_TAG_subprogram
  DW_AT_abstract_origin   <0x01c5>
  DW_AT_linkage_name  "_ZN2StC2Ei"
  DW_AT_low_pc0x004009a6
  DW_AT_high_pc   22

[Bug go/61303] gccgo: segfault, regression since 4.8.2

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
>From looking at the code it seems that mmap may be returning MAP_FAILED.  That
could lead to this crash.  I don't know why mmap would fail, though.  It's a
shame that the program works when run under truss.

If you feel like experimenting, look at the call to runtime_SysAlloc near the
start of runtime_netpoll in libgo/runtime/netpoll_select.c.  Add something like
if(prfds == nil)
runtime_throw("runtime_SysAlloc returned nil");
and see if you see that error instead of the crash.

[Bug fortran/65925] Memory leak with source allocation nested inside the source of another source allocation

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

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

--- Comment #1 from Damian Rouson  ---
This was a false alarm.  Wrapping the following lines inside a bloc construct
eliminates the erroneous valgrind report.

class(base),allocatable :: d
allocate(d,source = newData())

Damian

[Bug target/66081] New: Invalid ARM ldrb instruction offset

[SimmonsCal at gmail dot com]

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

Bug ID: 66081
   Summary: Invalid ARM ldrb instruction offset
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SimmonsCal at gmail dot com
  Target Milestone: ---

Created attachment 35506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35506&action=edit
MQX web server supplement

4.8 2013q4
GCC arm cross compile code generation problem.
if (session->response.hdrsent == 0)
Generates
f550:   ldr r3, [r7, #8]
f552:   ldrb.w r3, [r3, #93]; 0x5d
Maximum offset of ldrb instruction is 31 vs. 93 in generated instruction.

[Bug fortran/66082] New: [4.9.2/5.1.0/6.0.0] memory leak: automatic array with derived type array constructor actual argument

[damian at sourceryinstitute dot org]

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

Bug ID: 66082
   Summary: [4.9.2/5.1.0/6.0.0] memory leak: automatic array with
derived type array constructor actual argument
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

The code below demonstrates a memory leak generated by an automatic array dummy
argument with a corresponding actual argument that is a derived type array
constructor with an allocatable component.  Changing the dummy argument
declaration "foo(n)" to an assumed shape array "foo(:)" eliminates the leak.

Damian

$ cat reduced.f90 
  type foo_t
 real, allocatable :: bigarr
  end type 
  block
type(foo_t) :: foo 
allocate(foo%bigarr) 
call foo_1d(1,[foo]) ! definitely lost
  end block
contains
  subroutine foo_1d(n,foo)
integer n
type(foo_t) :: foo(n)
  end subroutine 
end 
$ gfortran reduced.f90 
$ valgrind ./a.out
==7891== Memcheck, a memory error detector
==7891== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==7891== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7891== Command: ./a.out
==7891== 
==7891== 
==7891== HEAP SUMMARY:
==7891== in use at exit: 4 bytes in 1 blocks
==7891==   total heap usage: 26 allocs, 25 frees, 12,662 bytes allocated
==7891== 
==7891== LEAK SUMMARY:
==7891==definitely lost: 4 bytes in 1 blocks
==7891==indirectly lost: 0 bytes in 0 blocks
==7891==  possibly lost: 0 bytes in 0 blocks
==7891==still reachable: 0 bytes in 0 blocks
==7891== suppressed: 0 bytes in 0 blocks
==7891== Rerun with --leak-check=full to see details of leaked memory
==7891== 
==7891== For counts of detected and suppressed errors, rerun with: -v
==7891== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$ gfortran --version
GNU Fortran (GCC) 6.0.0 20150503 (experimental)

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

[dougmencken at gmail dot com]

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

--- Comment #3 from Douglas Mencken  ---
(In reply to Richard Biener from comment #2)
> 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?

My stage0 compiler is 4.9.2 (not Apple-patched 4.2.1). I also mentioned its "-v
output" in above comment. But I doubt it is related to host compiler...

This is happening on stage2, and
$ prev-gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
works well.

It is
$ gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
that fails.

Backtrace.

$ gdb --args gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
(gdb) run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x419e04bc
0xdcb0 in operand::gen_transform ()
(gdb) bt
#0  0xdcb0 in operand::gen_transform ()
#1  0x7fd8 in get_operator ()
#2  0x99a0 in parser::parse_operator_list ()
#3  0xcc38 in parser::parse_pattern ()
#4  0xdc44 in parser::parser ()
#5  0x0006357c in main () at
../../../../gcc-5.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:121

[Bug c/66083] New: Linux kernel fails to boot with O3 optimization

[bobby.prani at gmail dot com]

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

Bug ID: 66083
   Summary: Linux kernel fails to boot with O3 optimization
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobby.prani at gmail dot com
  Target Milestone: ---

Created attachment 35507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35507&action=edit
Enable O3 optimization

Linux kernel 4.1-rc1 fails to boot with O3 optimization. Patch to enable O3 and
config file attached.

[Bug c/66083] Linux kernel fails to boot with O3 optimization

[bobby.prani at gmail dot com]

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

--- Comment #1 from Pranith Kumar  ---
Created attachment 35508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35508&action=edit
config file

[Bug c/66083] Linux kernel fails to boot with O3 optimization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-09
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
There is not enough information in your bug report to be useful.
Which specific file gets miscompiled? Which function in that file?
What is the exact compiler invocation? 
See: http://gcc.gnu.org/bugs/

[Bug c/66083] Linux kernel fails to boot with O3 optimization

[bobby.prani at gmail dot com]

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

--- Comment #3 from Pranith Kumar  ---
The kernel fails to boot. It works using 4.7/4.8 but 4.9 does not work. Not
sure what you mean which file. How do I pin point that?

[Bug c/66083] Linux kernel fails to boot with O3 optimization

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Pranith Kumar from comment #3)
> The kernel fails to boot. It works using 4.7/4.8 but 4.9 does not work. Not
> sure what you mean which file. How do I pin point that?

You could start with the failing kernel and replace object files with 
good ones until it boots (or vice versa). 
Once you have pinpoint the file in question you can use 
__attribute__((optimize(O2)) to narrow the issue down to a single function.

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

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

--- Comment #10 from Yury Gribov  ---
Did libsanitizer build for you both with and without xdr.h? If yes, I'll just
go ahead and submit this.