[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

--- Comment #2 from werner at beroux dot com ---
It worked on gcc (Debian 4.9.2-2).

Also I tried on two machines with pretty different spec. I'm not excluding the
memory issue, just saying it used to work on those two machines and now it
doesn't.

[Bug middle-end/67490] [6 regression] FAIL: gcc.target/powerpc/pr16458-1.c scan-assembler-not cmpw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/67553] Saturating SSE/AVX instructions do not get optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*

--- Comment #3 from Richard Biener  ---
The backend probably uses unspecs for this (the intrinsics use builtins).  I
wonder if the backend could enable fixed-point types/modes more generally.

[Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
I'll have a look.

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 Ever confirmed|0   |1

--- Comment #6 from H.J. Lu  ---
(In reply to Yulia Koval from comment #5)
> Sorry, I don't understand why we shouldn't preserve the red zone. The
> function "foo", executing before the interrupt was called, used its red
> zone. If the interrupt does not adjust the stack pointer, who control that
> "foo" function's red zone would not be overwritten?

Please take a look at Exception- or Interrupt-Handler Procedures in
Intel64 and IA-32 Architectures Software Developer’s Manual vol 3.
There is no red zone on stack of interrupt handler, which is controlled
by processor, independent of any calling conventions.

[Bug c++/67533] internal compiler error: in build_call_a, at cp/call.c:372

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
Version|4.8.4   |5.2.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
GCC 4.8 is no longer supported.  Confirmed with GCC 5.

[Bug c++/67549] internal compiler error: in fold_binary_loc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.9.0
 Resolution|--- |FIXED
  Known to fail||4.8.5

--- Comment #2 from Richard Biener  ---
With GCC 4.9 I need -fpermissive to even build on x86_64:

> g++-4.9 -S t.C -std=c++11
t.C:6:42: error: ‘constexpr’ needed for in-class initialization of static data
member ‘void (B::* B::ptr_func)(int)’ of non-integral type [-fpermissive]
  static T_PTRFUNC ptr_func = ::elem_func;
  ^

with -fpermissive it works.  I can reproduce the ICE on x86_64 with GCC 4.8.5.
Thus I assume it is fixed with GCC 4.9 and up.

[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
Created attachment 36333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36333=edit
test case

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

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

--- Comment #25 from Ramana Radhakrishnan  ---
Author: ramana
Date: Mon Sep 14 13:16:59 2015
New Revision: 227748

URL: https://gcc.gnu.org/viewcvs?rev=227748=gcc=rev
Log:
[AArch64] Handle literal pools for functions > 1 MiB in size.


This patch fixes the issue in PR63304 where we have
functions that are > 1MiB. The idea is to use adrp / ldr or adrp / add
instructions to address the literal pools under the use of a command line
option. I would like to turn this on by default on trunk but keep this
disabled by default for the release branches in order to get some
serious testing for this feature while it bakes on trunk.

As a follow-up I would like to try and see if estimate_num_insns or
something else can give us a heuristic to turn this on for "large" functions.
After all the number of incidences of this are quite low in real life,
so may be we should look to restrict this use as much as possible on the
grounds that this code generation implies an extra integer register for
addressing for every floating point and vector constant and I don't think
that's great in code that already may have high register pressure.

Tested on aarch64-none-elf with no regressions. A previous
version was bootstrapped and regression tested.

Applied to trunk.

regards
Ramana

2015-09-14  Ramana Radhakrishnan  

PR target/63304
* config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
nopcrelative_literal_loads.
(aarch64_classify_address): Likewise.
(aarch64_constant_pool_reload_icode): Define.
(aarch64_secondary_reload): Handle secondary reloads for
literal pools.
(aarch64_override_options): Handle nopcrelative_literal_loads.
(aarch64_classify_symbol): Handle nopcrelative_literal_loads.
* config/aarch64/aarch64.md
(aarch64_reload_movcp):
Define.
(aarch64_reload_movcp): Likewise.
* config/aarch64/aarch64.opt (mpc-relative-literal-loads): New option.
* config/aarch64/predicates.md (aarch64_constant_pool_symref): New
predicate.
* doc/invoke.texi (mpc-relative-literal-loads): Document.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/aarch64.opt
trunk/gcc/config/aarch64/iterators.md
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/doc/invoke.texi

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-09-14
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Ok, reopening then, sorry.  Maybe some change caused GCC to eat much more
memory than it really should.

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

--- Comment #5 from werner at beroux dot com ---
I'm trying to build with newer GCC and older code to confirm that (build takes
a while).

[Bug target/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

--- Comment #6 from werner at beroux dot com ---
Humm no sorry I'm building from the same git tag (which is of Jan 24). So it
looks like something caused GCC to use more memory than before.

I did notice a GCC5 compilation fix, probably unrelated, just in case it here:
https://github.com/ariya/phantomjs/commit/fe2c6bb5fdf776b718422a104e6babe67dbf2629

[Bug target/67507] Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM thumb1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |4.9.4

--- Comment #1 from Richard Biener  ---
IIRC even though the C standard says the access has to be aligned according to
int when GCC knows better (you access char aligned global_data_unaligned) it
will use the smaller alignment.

This is done to be friendlier to "legacy" code.

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I thought we do nothing in an incremental link but concat the LTO input
sections?
That's why we put that $ID suffix on the section names.  So maybe with plugin
auto-loading (and thus slim objects?) the LTO plugin shouldn't claim any files
with LDPO_REL mode.

[Bug lto/67568] lto-streamer-in.c sanitizer runtime error: load of value 255, which is not a valid value for type 'bool'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/67572] std::atomic, std::mutex and others are trivially copyable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/67572] New: std::atomic, std::mutex and others are trivially copyable

[redi at gcc dot gnu.org]

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

Bug ID: 67572
   Summary: std::atomic, std::mutex and others are trivially
copyable
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 
#include 
#include 

static_assert( !std::is_trivially_copyable::value,
"atomic" );
static_assert( !std::is_trivially_copyable::value, "mutex" );
static_assert( !std::is_trivially_copyable::value,
"timed_mutex" );
static_assert( !std::is_trivially_copyable::value,
"shared_timed_mutex" );

Being non-copyable and non-movable doesn't stop a type being non-trivially
copyable, so to ensure users don't think it's OK to memcpy these types we need
to fix them (e.g. by adding a user-defined destructor).

[Bug target/67573] New: [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

Bug ID: 67573
   Summary: [SH] wrong code generated for
libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
CC: olegendo at gcc dot gnu.org
Blocks: 55212
  Target Milestone: ---
Target: sh*-*-*

Wrong code is generated with sh-linux/sh-elf compilers for
void std::__facet_shims::__moneypunct_fill_cache(std::integral_constant, std::locale::facet const*,
std::__moneypunct_cache*)
at "-m4 -ml -O2 -fPIC -mlra -std=gnu++11".

It uses __copy inline function and __copy calls
std::__cxx11::basic_string::copy(wchar_t*, unsigned int, unsigned int)

with the wrong code

mov r11,r4
mov.l   .L1122,r7
mov r0,r5
mov.l   @r15,r6
mov r10,r4
bsrfr7
.LPCS203:
mov.l   r0,@(4,r15)
...
.L1122:
.long  
_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj@PLT-(.LPCS203+2-.)

where r7 should be 0 as the last argument.  With -mno-lra,
the corresponding code is:

mov.l   .L1050,r1
mov r0,r14
mov #0,r7
mov r13,r6
mov r0,r5
bsrfr1
.LPCS191:
mov r10,r4
...

It seems that dse/dce removes mov #0, r7.

.pro_and_epilogue:

(insn 204 831 830 22 (set (reg:SI 7 r7)
(const_int 0 [0])) fa.cc:484 253 {movsi_ie}
 (nil))

.dse2 marks r7 unused:

(insn 204 831 830 22 (set (reg:SI 7 r7)
(const_int 0 [0])) fa.cc:484 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 7 r7)
(nil)))

.jump2 eliminates insn 204:

DCE: Deleting insn 204
deleting insn with uid = 204.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
[Bug 55212] [SH] Switch to LRA

[Bug other/67520] libmpx should abort() instead of exit(255) on bound violation detection

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
IMHO libraries should have a way to specify a custom handler (and default that
to abort maybe).  Indeed exit (255) isn't very canonical.

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

--- Comment #3 from werner at beroux dot com ---
I should clarify that the code being compiled might have changed as well
between the two:

https://github.com/ariya/phantomjs/commits/master

from 2015-06-25T20:16:02.750261Z (working)
to 2015-09-05T08:36:46.296402Z (started breaking)
and 2015-09-14T07:32:46.758499Z (still breaking)

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
Version|unknown |6.0
   Target Milestone|--- |6.0
Summary|ICE in cselib_record_set,   |[6 Regression] ICE in
   |at cselib.c:2388|cselib_record_set, at
   ||cselib.c:2388

[Bug target/67474] [6 regression] tree-vect-loop.c:2759:1: error: insn does not satisfy its constraints breaks ARM bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/67563] [5/6 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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

[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c/67569] erroneous compiler error message

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #2 from Andrew Pinski  ---
Actually this might be reproducible with -m32 on x86_64. The issue is related
to the fix for exessive precision.

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-14
 CC|rguenther at suse dot de   |
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug target/67510] x86: Faster code is possible for integer absolute value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  x86 doesn't have integer abs patterns it seems and we end up using
expand_abs_nojump()s

  /* If this machine has expensive jumps, we can do integer absolute
 value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
 where W is the width of MODE.  */

[Bug middle-end/67518] [6 Regression] ISL: position out of bounds

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #7 from Markus Trippelsdorf  ---
Can you please attach the preprocessed JSBindingsAllInOne.ii file (by
adding -save-temps to the compiler invocation)?

[Bug libstdc++/67566] std::move is in global scope g++ 5.1 -std=c++14

[forest_software at mail dot ru]

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

--- Comment #2 from Roman Koptev  ---
I've installed gcc 5.1 from repository
http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu on Ubuntu Studio:

lsb_release -a
LSB Version:   
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 14.04.3 LTS
Release:14.04
Codename:   trusty

g++ --version
g++ (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
Это свободно распространяемое программное обеспечение. Условия копирования
приведены в исходных текстах. Без гарантии каких-либо качеств, включая 
коммерческую ценность и применимость для каких-либо целей.

For the program above (main.cpp):

#include 
#include 

using boost::move;

main()
{
  std::string a = "fff";
  std::string b = move(a);
}

Compile as:
g++ main.cpp -std=c++14

I have the output (ambiguous call of overloaded function, Sorry for russian
localization):

main.cpp: В функции «int main()»:
main.cpp:9:25: ошибка: вызов перегруженной функции «move(std::string&)»
неоднозначен
   std::string b = move(a);
 ^
In file included from /usr/include/boost/move/utility.hpp:28:0,
 from /usr/include/boost/move/move.hpp:29,
 from main.cpp:2:
/usr/include/boost/move/utility_core.hpp:211:77: замечание: candidate: typename
boost::move_detail::remove_reference::type&& boost::move(T&&) [with T =
std::basic_string&; typename
boost::move_detail::remove_reference::type = std::basic_string]
  inline typename ::boost::move_detail::remove_reference::type &&
move(T&& t) BOOST_NOEXCEPT
 ^
In file included from /usr/include/c++/5/bits/stl_pair.h:59:0,
 from /usr/include/c++/5/bits/stl_algobase.h:64,
 from /usr/include/c++/5/bits/char_traits.h:39,
 from /usr/include/c++/5/string:40,
 from main.cpp:1:
/usr/include/c++/5/bits/move.h:101:5: замечание: candidate: constexpr typename
std::remove_reference<  >::type&& std::move(_Tp&&)
[with _Tp = std::basic_string&; typename std::remove_reference<
 >::type = std::basic_string]
 move(_Tp&& __t) noexcept
 ^

Now for simple program (main.cpp):

#include 

main()
{
  std::string a = "fff";
  std::string b = move(a);
}

Compile with:
g++ main.cpp

I have the correct error message (no declaration move in this scope):

main.cpp: В функции «int main()»:
main.cpp:6:25: ошибка: нет декларации «move» в этой области видимости
   std::string b = move(a);
 ^

But if I compile as:
g++ main.cpp -std=c++14

It compile successfully and has no any output on stdout or stderr

That'is if I compile any program with the option -std=c++14, after including
 (may be and other headers) std::move surely and always is in global
namespace, available without std:: or using std or using std::move and this is
surely abnormal.

[Bug middle-end/67401] Incorrect expand of __atomic_compare_exchange_8 using __sync_val_compare_and_swap_8

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Mon Sep 14 12:05:58 2015
New Revision: 227746

URL: https://gcc.gnu.org/viewcvs?rev=227746=gcc=rev
Log:
PR middle-end/67401
* optabs.c (expand_atomic_compare_and_swap): Move result of emitting
sync_compare_and_swap_optab libcall to target_oval.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c

[Bug libstdc++/67566] std::move is in global scope g++ 5.1 -std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Roman Koptev from comment #2)
> That'is if I compile any program with the option -std=c++14, after including
>  (may be and other headers) std::move surely and always is in global
> namespace, available without std:: or using std or using std::move and this
> is surely abnormal.

No it isn't in the global namespace, it's in namespace std as required by the
C++ standard. What's happening is called Argument Dependent Lookup and is
perfectly normal.

http://en.cppreference.com/w/cpp/language/adl
https://en.wikipedia.org/wiki/Argument-dependent_name_lookup
http://stackoverflow.com/questions/8111677/what-is-argument-dependent-lookup-aka-adl-or-koenig-lookup

[Bug c/67569] wrong type in error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #2)
> Actually this might be reproducible with -m32 on x86_64. The issue is
> related to the fix for exessive precision.

Yes, it is. With 6.0, cc1 -m32 -std=c99 on x86_64-linux-gnu.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #111 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #110)

It seems that those failures are the latent wrong code problem
triggered with -mlra accidentally.  I've filed it as PR67573.

[Bug target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
The tree level should indeed do a better job here but it gets "confused" by
narrowing the return expressions to int before it gets a chance to do
that optimization.  It's

 s64 d = a - b;

  if (d == 0)
return (unsigned)a + (unsigned)c;
  else
return (unsigned)b + (unsigned)d + (unsigned)c;

to them and 'd' is not handled the same way because the shortening happens
in the frontend.

You might want to file a separate PR about this missed optimization.

[Bug fortran/67509] [6 regression] FAIL: gfortran.dg/ieee/ieee_7.f90 -O0 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Mon Sep 14 13:46:14 2015
New Revision: 227750

URL: https://gcc.gnu.org/viewcvs?rev=227750=gcc=rev
Log:
gcc/
PR target/67061
* config/sh/sh-protos.h (sh_find_set_of_reg): Simplfiy for-loop.
Handle call insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h

[Bug tree-optimization/67530] Failure to eliminate dead code produced by vector lowering

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The relevant pass is lower_vector_ssa which runs way before the last cd_cde. 
The issue is that

  _6 = {_11, _14, _17, _20, _23, _26, _29, _32};
  _7 = BIT_FIELD_REF <_6, 32, 64>;
  _8 = (long int) _7;
  return _8;

is only resolved very late in the forwprop pass _after_ the last DCE.  I
suppose
vector lowering could be changed to fold all stmts that have vector operands
(it doesn't touch _7 = BIT_FIELD_REF <_6, 32, 64> otherwise).

[Bug c/67569] wrong type in error message

[ka_bena at yahoo dot fr]

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

--- Comment #4 from BENAÏSSA  ---
Thank you for your replty. A.Benaïssa



 Le Lundi 14 septembre 2015 11h22, mpolacek at gcc dot gnu.org
 a écrit :


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

Marek Polacek  changed:

          What    |Removed                    |Added

            Status|UNCONFIRMED                |RESOLVED
                CC|                            |mpolacek at gcc dot gnu.org
        Resolution|---                        |WORKSFORME

--- Comment #1 from Marek Polacek  ---
Can't reproduce:

h1.c: In function ‘main’:
h1.c:5:6: error: invalid operands to binary - (have ‘int *’ and ‘float’)

Also, gcc 4.8 is not supported anymore.

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #4 from Florian Weimer  ---
This has been assigned CVE-2015-5276.

[Bug c++/67574] New: Misleading error message for method explicitly defaulted two times

[arvo at me dot com]

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

Bug ID: 67574
   Summary: Misleading error message for method explicitly
defaulted two times
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arvo at me dot com
  Target Milestone: ---

Created attachment 36334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36334=edit
Minimal test program (no headers/macros)

g++ (Ubuntu 5.1.1-4ubuntu12) 5.1.1 20150504
x86_64 GNU/Linux
Ubuntu 15.04
Command line: g++ -c -std=c++11 redefaulted.cxx

Compiling the attached test program results in the following diagnostic:
redefaulted.cxx:7:1: error: definition of explicitly-defaulted ‘X::X()’
 X::X() = default;
 ^
redefaulted.cxx:1:8: error: ‘X::X()’ explicitly defaulted here
 struct X
^

This is misleading as X::X() was first defined (and explicitly defaulted) in
line 6, not line 1, and not even in the struct definition.

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Yes, I plan to come back to this during stage3.

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Unfortunately I do not master gdb and gcc internals enough for that.
The check costs two instructions on my x86-64.

[Bug sanitizer/67575] New: tsan: double instrumentation of x++

[dvyukov at google dot com]

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

Bug ID: 67575
   Summary: tsan: double instrumentation of x++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

This come up during work on KernelThreadSanitizer for functions like:

static __always_inline void pagefault_disabled_inc(void)
{
current->pagefault_disabled++;
}

The memory access is instrumented twice in such functions.
Here is a standalone reproducer:

long x;

void foo(long *p) {
(*p)++;
}

void bar(void) {
x++;
}

int main() {
return 0;
}

$ gcc test.c -fsanitize=thread -O2
$ objdump -d a.out | less

00400760 :
  400760:   55  push   %rbp
  400761:   53  push   %rbx
  400762:   48 89 fbmov%rdi,%rbx
  400765:   48 83 ec 08 sub$0x8,%rsp
  400769:   48 8b 7c 24 18  mov0x18(%rsp),%rdi
  40076e:   e8 8d fe ff ff  callq  400600 <__tsan_func_entry@plt>
  400773:   48 89 dfmov%rbx,%rdi
  400776:   e8 95 fe ff ff  callq  400610 <__tsan_read8@plt>
  40077b:   48 8b 03mov(%rbx),%rax
  40077e:   48 89 dfmov%rbx,%rdi
  400781:   48 8d 68 01 lea0x1(%rax),%rbp
  400785:   e8 96 fe ff ff  callq  400620 <__tsan_write8@plt>
  40078a:   48 89 2bmov%rbp,(%rbx)
  40078d:   48 83 c4 08 add$0x8,%rsp
  400791:   5b  pop%rbx
  400792:   5d  pop%rbp
  400793:   e9 98 fe ff ff  jmpq   400630 <__tsan_func_exit@plt>
  400798:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
  40079f:   00 

004007a0 :
  4007a0:   53  push   %rbx
  4007a1:   48 8b 7c 24 08  mov0x8(%rsp),%rdi
  4007a6:   e8 55 fe ff ff  callq  400600 <__tsan_func_entry@plt>
  4007ab:   bf 40 0c 60 00  mov$0x600c40,%edi
  4007b0:   e8 5b fe ff ff  callq  400610 <__tsan_read8@plt>
  4007b5:   48 8b 05 84 04 20 00mov0x200484(%rip),%rax#
600c40 
  4007bc:   bf 40 0c 60 00  mov$0x600c40,%edi
  4007c1:   48 8d 58 01 lea0x1(%rax),%rbx
  4007c5:   e8 56 fe ff ff  callq  400620 <__tsan_write8@plt>
  4007ca:   48 89 1d 6f 04 20 00mov%rbx,0x20046f(%rip)#
600c40 
  4007d1:   5b  pop%rbx
  4007d2:   e9 59 fe ff ff  jmpq   400630 <__tsan_func_exit@plt>
  4007d7:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
  4007de:   00 00 

$ gcc -v
gcc version 6.0.0 20150831 (experimental) (GCC) 

For both functions there is both __tsan_read8 and __tsan_write8 callbacks.
Only __tsan_write8 should be emitted for performance reasons.

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[fweimer at redhat dot com]

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

--- Comment #5 from Florian Weimer  ---
The fix is incomplete because short reads can happen in practice for
/dev/random at least.

The usual retry loop is needed.  It is not clear what to do on EINTR.

[Bug c/67569] wrong type in error message

[ka_bena at yahoo dot fr]

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

--- Comment #5 from BENAÏSSA  ---
Thank you.          A.Benaïssa



 Le Lundi 14 septembre 2015 13h27, pinskia at gcc dot gnu.org
 a écrit :


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

Andrew Pinski  changed:

          What    |Removed                    |Added

            Status|RESOLVED                    |UNCONFIRMED
        Resolution|WORKSFORME                  |---

--- Comment #2 from Andrew Pinski  ---
Actually this might be reproducible with -m32 on x86_64. The issue is related
to the fix for exessive precision.

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
And the check is wrong in the fread() case as it will only ever return 0 or 1.

[Bug c++/67557] Calling copy constructor of base class in constructor of derived class produces crashing code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #11 from Jonathan Wakely  ---
Jason, this is the copy elision bug I mentioned.

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Vittorio Zecca from comment #2)
> Unfortunately I do not master gdb and gcc internals enough for that.
> The check costs two instructions on my x86-64.

Two instructions that we do not need to execute! :)

In this case, the worst part is that it will hide a bug in error reporting. It
will print something like:

Error: X between the MODULE PROCEDURE declaration in module  and the
declaration at (1) in SUBMODULE Y

which is wrong.

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Updated patch series:
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00938.html
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00940.html

[Bug c++/51911] [C++11] G++ accepts new auto { list }

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini  ---
Diagnostic improved for 6.0.

[Bug c++/51911] [C++11] G++ accepts new auto { list }

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Sep 14 15:25:00 2015
New Revision: 227753

URL: https://gcc.gnu.org/viewcvs?rev=227753=gcc=rev
Log:
/cp
2015-09-14  Paolo Carlini  

PR c++/51911
* parser.c (cp_parser_new_expression): Enforce 5.3.4/2 (as amended
per the spirit of DR 1467).

/testsuite
2015-09-14  Paolo Carlini  

PR c++/51911
* g++.dg/cpp0x/new-auto1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/new-auto1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67576] New: expression of typeid( expression ) is evaluated twice

[cctsai57 at gmail dot com]

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

Bug ID: 67576
   Summary: expression of typeid( expression ) is evaluated twice
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cctsai57 at gmail dot com
  Target Milestone: ---

#include 

struct Base { virtual void foo() {} }; // polymorphic

int main()
{
  Base b;
  Base *ary[] = { , , };

  int iter = 0;
  typeid(*ary[iter++]);
  if (iter != 1)// should be 1
__builtin_abort();  // but 2

  return iter;
}


Compiler version:4.9.x, 5.x, 6.0

Description:
The above simplified code would get a wrong `iter' value after typeid
statement.
It seems to evaluate `iter++' twice.

I found that the code has not worked since the following fix:

commit cdb704aa83247f82d7b9aae934639a6be2e6681b
Author: jason 
Date:   Tue Apr 9 18:11:38 2013 +

PR c++/25466
* rtti.c (build_typeid): Check the address of the argument
rather than looking for an INDIRECT_REF.

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

[Bug rtl-optimization/67577] New: Trivial float-vectorization foiled by a loop

[bisqwit at iki dot fi]

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

Bug ID: 67577
   Summary: Trivial float-vectorization foiled by a loop
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

This code is written as if tailored to be SIMD-optimized by GCC...
But GCC somehow blows it.

template
struct vec
{
T d[N];

vec operator* (const T& b)
{
vec result;
for(unsigned n=0u; n operator+ (const vec& b)
{
vec result;
for(unsigned n=0u; n operator- (const vec& b)
{
vec result;
for(unsigned n=0u; n a, b, c;

void x()
{
for(int n=0; n<1; ++n)
{
vec result = b + (a - b) * scale;
c = result;
}
}

Generated code (inner loop):

movss   b+4(%rip), %xmm6
movss   a+4(%rip), %xmm7
subss   %xmm6, %xmm7
movss   scale(%rip), %xmm0
movss   b+8(%rip), %xmm5
movss   b+12(%rip), %xmm4
movss   b+16(%rip), %xmm3
mulss   %xmm0, %xmm7
movss   b+20(%rip), %xmm1
movss   b+24(%rip), %xmm2
movss   b+28(%rip), %xmm9
movss   b(%rip), %xmm8
addss   %xmm6, %xmm7
movss   a+8(%rip), %xmm6
subss   %xmm5, %xmm6
movss   %xmm7, c+4(%rip)
mulss   %xmm0, %xmm6
addss   %xmm5, %xmm6
movss   a+12(%rip), %xmm5
subss   %xmm4, %xmm5
movss   %xmm6, c+8(%rip)
mulss   %xmm0, %xmm5
addss   %xmm4, %xmm5
movss   a+16(%rip), %xmm4
subss   %xmm3, %xmm4
movss   %xmm5, c+12(%rip)
mulss   %xmm0, %xmm4
addss   %xmm3, %xmm4
movss   a+20(%rip), %xmm3
subss   %xmm1, %xmm3
movss   %xmm4, c+16(%rip)
mulss   %xmm0, %xmm3
addss   %xmm1, %xmm3
movss   a+24(%rip), %xmm1
subss   %xmm2, %xmm1
movss   %xmm3, c+20(%rip)
mulss   %xmm0, %xmm1
addss   %xmm2, %xmm1
movss   a+28(%rip), %xmm2
subss   %xmm9, %xmm2
movss   %xmm1, c+24(%rip)
mulss   %xmm0, %xmm2
addss   %xmm9, %xmm2
movss   a(%rip), %xmm9
subss   %xmm8, %xmm9
movss   %xmm2, c+28(%rip)
mulss   %xmm9, %xmm0
addss   %xmm8, %xmm0
movss   %xmm0, c(%rip)

Platform: amd64; GCC version 5.2.1.

If I comment away the dummy for-loop, or I change the float "scale" variable
into a function parameter, the inner loop changes into a much simpler code that
vectorizes like I meant to:

movaps  b(%rip), %xmm3
movaps  b+16(%rip), %xmm1
movaps  a+16(%rip), %xmm0
movaps  a(%rip), %xmm2
subps   %xmm1, %xmm0
movss   scale(%rip), %xmm4
subps   %xmm3, %xmm2
shufps  $0, %xmm4, %xmm4
mulps   %xmm4, %xmm0
mulps   %xmm4, %xmm2
addps   %xmm1, %xmm0
addps   %xmm3, %xmm2
movaps  %xmm0, -24(%rsp)
movq-16(%rsp), %rax
movaps  %xmm2, -40(%rsp)
movq%xmm2, c(%rip)
movq%xmm0, c+16(%rip)
movq-32(%rsp), %rdx
movq%rax, c+24(%rip)
movq%rdx, c+8(%rip)

Although there's still some glitch in the generated code causing dummy memory
transfers, at least it now did the calculations using packed registers.

If I change the global "scale" variable into a function parameter, the
following shorter code is generated instead (essentially the same what Clang
successfully produces for all three cases).

movaps  b+16(%rip), %xmm2
shufps  $0, %xmm0, %xmm0
movaps  a+16(%rip), %xmm1
subps   %xmm2, %xmm1
movaps  b(%rip), %xmm3
mulps   %xmm0, %xmm1
addps   %xmm2, %xmm1
movaps  a(%rip), %xmm2
subps   %xmm3, %xmm2
movaps  %xmm1, c+16(%rip)
mulps   %xmm2, %xmm0
addps   %xmm3, %xmm0
movaps  %xmm0, c(%rip)

Something causes GCC's tree-vectorization to be really rickety and easily
foiled by trivial changes in code, and I'd like to see it fixed at least in
these particular cases.

[Bug libstdc++/67578] New: std::random_device::entropy() always returns 0

[redi at gcc dot gnu.org]

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

Bug ID: 67578
   Summary: std::random_device::entropy() always returns 0
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

When using /dev/random or /dev/urandom on GNU/Linux we can get the bits of
available entropy using the RNDGETENTCNT ioctl.

[Bug sanitizer/67575] tsan: double instrumentation of x++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Actually I was wrong, it was discussed but the discussion about having it:
> TSAN will badly need similar optimization pass to what ASAN needs (after
> deferring expansion of the shadow memory checks), e.g. var++ right now
> results in __tsan_read4 (); followed soon by __tsan_write4 ();.
> With no intervening calls (we could ignore many string/memory builtins
> I guess) and no intervening atomics it should be fine to just use
> __tsan_write4 (); for that, right?

Right.

https://gcc.gnu.org/ml/gcc-patches/2012-11/msg02430.html

[Bug sanitizer/67575] tsan: double instrumentation of x++

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is needed to be done for thread.  There was a thread (so no pun intended)
about this on the mailing list IIRC.

[Bug c++/67576] [4.9/5/6 Regression] expression of typeid( expression ) is evaluated twice

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
  Known to work||4.8.4
Summary|expression of typeid(   |[4.9/5/6 Regression]
   |expression ) is evaluated   |expression of typeid(
   |twice   |expression ) is evaluated
   ||twice
 Ever confirmed|0   |1

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #23 from Jeffrey A. Law  ---
Author: law
Date: Mon Sep 14 20:10:30 2015
New Revision: 227762

URL: https://gcc.gnu.org/viewcvs?rev=227762=gcc=rev
Log:
[PATCH] Minor DOM cleanup

PR tree-optimization/47679
* tree-ssa-dom.c (avail_expr_hash): Pass a pointer to a real
type rather than void *.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug c/67580] Improve error message on missing "struct" tag

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Perhaps after failing to find type 'S' and before giving the error, it could
try to find 'struct S' and 'union S' (perhaps even enum S) using lookup_tag()
in c-decl.c.

[Bug c/67580] New: Improve error message on missing "struct" tag

[chengniansun at gmail dot com]

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

Bug ID: 67580
   Summary: Improve error message on missing "struct" tag
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

I wonder whether the error message on missing the 'struct' tag can be improved.
IMHO, clang gives a clearer message on how to fix the error. This also applies
to union types.  

$: cat t.c
struct S {int s;};

void f(int a) {
  S s = {a};
}
$: gcc-trunk -c t.c
t.c: In function ‘f’:
t.c:4:3: error: unknown type name ‘S’
   S s = {a};
   ^
$: clang-trunk -c t.c
t.c:4:3: error: must use 'struct' tag to refer to type 'S'
  S s = {a};
  ^
  struct 
1 error generated.
$:

[Bug c++/67581] New: ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed)

[su at cs dot ucdavis.edu]

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

Bug ID: 67581
   Summary: ICE on transparent union with -g enabled on
x86_64-linux-gnu (verify_type failed)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu when -g is enabled. 

This is a regression from 5.2.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150914 (experimental) [trunk revision 227747] (GCC) 
$ 
$ g++-trunk -c t.cc
$ g++-5.2 -c -g t.cc
$
$ g++-trunk -c -g t.cc
t.cc:1:7: error: type variant differs by TYPE_TRANSPARENT_AGGR.
 union U 
   ^
  constant 32>
unit size  constant 4>
align 32 symtab -1432334256 alias set -1 canonical type 0x7fefaab41348
fields  unit size 
align 32 symtab -1432334096 alias set -1 canonical type
0x7fefaa9df7e0 precision 32 min  max

pointer_to_this >
nonlocal decl_3 SI file t.cc line 3 col 7 size  unit size 
align 32 offset_align 128
offset 
bit offset  context 
chain 
nonlocal decl_3 SF file t.cc line 4 col 9 size  unit size 
align 32 offset_align 128 offset  bit
offset  context 
chain >> context 
full-name "union U"
X() X(constX&) this=(X&)
chain >
  constant 32>
unit size  constant 4>
align 32 symtab 0 alias set -1 canonical type 0x7fefaab41348
fields  unit size 
align 32 symtab -1432334096 alias set -1 canonical type
0x7fefaa9df7e0 precision 32 min  max

pointer_to_this >
nonlocal decl_3 SI file t.cc line 3 col 7 size  unit size 
align 32 offset_align 128
offset 
bit offset  context 
chain 
nonlocal decl_3 SF file t.cc line 4 col 9 size  unit size 
align 32 offset_align 128 offset  bit
offset  context 
chain >> context 
full-name "union U"
X() X(constX&) this=(X&)
chain >
t.cc:1:7: internal compiler error: verify_type failed
0xf1ebf9 verify_type(tree_node const*)
../../gcc-trunk/gcc/tree.c:13583
0x97fb04 gen_type_die_with_usage
../../gcc-trunk/gcc/dwarf2out.c:20707
0x981186 gen_type_die
../../gcc-trunk/gcc/dwarf2out.c:20901
0x98d7c1 gen_decl_die
../../gcc-trunk/gcc/dwarf2out.c:21487
0x97ef9d gen_member_die
../../gcc-trunk/gcc/dwarf2out.c:20378
0x97ef9d gen_struct_or_union_type_die
../../gcc-trunk/gcc/dwarf2out.c:20483
0x97ef9d gen_tagged_type_die
../../gcc-trunk/gcc/dwarf2out.c:20684
0x9805ed gen_type_die_with_usage
../../gcc-trunk/gcc/dwarf2out.c:20846
0x981186 gen_type_die
../../gcc-trunk/gcc/dwarf2out.c:20901
0x98d7c1 gen_decl_die
../../gcc-trunk/gcc/dwarf2out.c:21487
0x98e27c dwarf2out_decl
../../gcc-trunk/gcc/dwarf2out.c:21937
0x98e5ab dwarf2out_type_decl
../../gcc-trunk/gcc/dwarf2out.c:21647
0xbbcbff rest_of_type_compilation(tree_node*, int)
../../gcc-trunk/gcc/passes.c:339
0x6a47ac finish_struct_1(tree_node*)
../../gcc-trunk/gcc/cp/class.c:6747
0x6a61e4 finish_struct(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/class.c:6913
0x6df81b cp_parser_class_specifier_1
../../gcc-trunk/gcc/cp/parser.c:20443
0x6df81b cp_parser_class_specifier
../../gcc-trunk/gcc/cp/parser.c:20671
0x6df81b cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15076
0x6ef4ab cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12042
0x703d10 cp_parser_simple_declaration
../../gcc-trunk/gcc/cp/parser.c:11608
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


union U 
{
  int x; 
  float y;
} __attribute__ ((__transparent_union__));

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

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

--- Comment #28 from urbanjost at comcast dot net ---
This is still a problem with Cygwin 2.2.1 and gfortran 4.9.3 

  $ cygcheck --version
cygcheck (cygwin) 2.2.1
System Checker for Cygwie
$ gfortran --version
GNU Fortran (GCC) 4.9.3

$ bash bug1.sh
ar: creating libex.a
COMPILER gfortran
 BAD LOAD ix2(4)=


-Original Message-
From: fxcoudert at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Saturday, September 12, 2015 7:20 AM
To: urbanj...@comcast.net
Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not
loading from library

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |6.0

--- Comment #1 from Vittorio Zecca  ---
Same bug on the trunk.
The following is the sanitizer output:

~/1tb/vitti/local/gcc-trunk-sanitized/bin/g++ -S gccerr26.C
=
==25114==ERROR: AddressSanitizer: heap-use-after-free on address 0x60205850
at pc 0x2b7d193c94a5 bp 0x7ffe44d41860 sp 0x7ffe44d41010
READ of size 1 at 0x60205850 thread T0
#0 0x2b7d193c94a4 in __interceptor_strcmp
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:178
#1 0x170f87f in cl_target_option_eq(cl_target_option const*,
cl_target_option const*) /home/vitti/test/gcc-sanitized/gcc/options-save.c:3491
#2 0x202ee44 in cl_option_hasher::equal(tree_node*, tree_node*)
../../gcc/gcc/tree.c:11866
#3 0x204559b in hash_table::find_slot_with_hash(tree_node* const&, unsigned int,
insert_option) ../../gcc/gcc/hash-table.h:838
#4 0x2042095 in hash_table::find_slot(tree_node* const&, insert_option)
../../gcc/gcc/hash-table.h:408
#5 0x202efc4 in build_target_option_node(gcc_options*)
../../gcc/gcc/tree.c:11914
#6 0x21218b0 in ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*) ../../gcc/gcc/config/i386/i386.c:5110
#7 0x21af79c in get_builtin_code_for_version
../../gcc/gcc/config/i386/i386.c:34678
#8 0x21b00b2 in ix86_compare_version_priority
../../gcc/gcc/config/i386/i386.c:34846
#9 0x780078 in joust ../../gcc/gcc/cp/call.c:9234
#10 0x781a8e in tourney ../../gcc/gcc/cp/call.c:9361
#11 0x7544bf in perform_overload_resolution ../../gcc/gcc/cp/call.c:4016
#12 0x754942 in build_new_function_call(tree_node*, vec**, bool, int) ../../gcc/gcc/cp/call.c:4089
#13 0xb66c40 in finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2391
#14 0xa0b32a in cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6422
#15 0xa0fec8 in cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7486
#16 0xa11a49 in cp_parser_cast_expression ../../gcc/gcc/cp/parser.c:8122
#17 0xa11bb4 in cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8223
#18 0xa13696 in cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8481
#19 0xa14197 in cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8727
#20 0xa42158 in cp_parser_initializer_clause
../../gcc/gcc/cp/parser.c:19925
#21 0xa41e9b in cp_parser_initializer ../../gcc/gcc/cp/parser.c:19866
#22 0xa3813e in cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:17793
#23 0xa215bc in cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11681
#24 0xa210aa in cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11555
#25 0xa208bb in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11452
#26 0xa1fe63 in cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11334
#27 0xa0181d in cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4154
#28 0xa843f8 in c_parse_file() ../../gcc/gcc/cp/parser.c:34273
#29 0xdb2e46 in c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1058
#30 0x19b8f12 in compile_file ../../gcc/gcc/toplev.c:544
#31 0x19bf8f0 in do_compile ../../gcc/gcc/toplev.c:2034
#32 0x19bff60 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2141
#33 0x2d332c0 in main ../../gcc/gcc/main.c:39
#34 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf)
#35 0x737768 
(/home/vitti/1tb/vitti/local/gcc-trunk-sanitized/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1plus+0x737768)

0x60205850 is located 0 bytes inside of 6-byte region
[0x60205850,0x60205856)
freed by thread T0 here:
#0 0x2b7d194171dd in __interceptor_free
../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:28
#1 0x21219df in ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*) ../../gcc/gcc/config/i386/i386.c:5118
#2 0x2121e77 in ix86_valid_target_attribute_p
../../gcc/gcc/config/i386/i386.c:5166
#3 0xd5e237 in handle_target_attribute
../../gcc/gcc/c-family/c-common.c:9777
#4 0xce2e48 in decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/attribs.c:557
#5 0x9a5e3a in cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1493
#6 0x7d65a7 in grokfndecl ../../gcc/gcc/cp/decl.c:8100
#7 0x7ea399 in grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**) ../../gcc/gcc/cp/decl.c:11265
#8 0x7bcb26 in start_decl(cp_declarator const*, cp_decl_specifier_seq*,
int, tree_node*, tree_node*, tree_node**) ../../gcc/gcc/cp/decl.c:4740
#9 0xa37c1f in 

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Posted updated patch series:
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00794.html
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00795.html

FTR, bootstrap and reg-test of this patch series on x86_64 succeeded.

[Bug lto/67568] New: lto-streamer-in.c sanitizer runtime error: load of value 255, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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

Bug ID: 67568
   Summary: lto-streamer-in.c sanitizer runtime error: load of
value 255, which is not a valid value for type 'bool'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Running make check in many test cases the sanitizer complains

../../gcc/gcc/lto-streamer-in.c:289:39: runtime error: load of value 255, which
is not a valid value for type 'bool'

The offending line is

 && current_col == stream_col && current_sysp == stream_sysp)

It seems that current_sysp has a value incompatible with its type bool

[Bug fortran/67567] New: pretty-print.h sanitizer detects NULL pointer passed to obstack_grow

[zeccav at gmail dot com]

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

Bug ID: 67567
   Summary: pretty-print.h sanitizer detects NULL pointer passed
to obstack_grow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While running make check-fortran on submodule_4.f08 the sanitizer complains
that in pretty-print.h:142

obstack_grow (buff->obstack, start, length);

the pointer start == NULL

Most probably length == 0

but I believe it best to fix it by prefixing the statement with "if(length)"

[Bug c/67570] comparison rules fails

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
If I understand what you are doing correctly, this is an unnormal 
representation (exponent not zero or maximal, explicit MSB of mantissa 
zero).  Such representations, which cannot be produced by floating-point 
operations, are considered trap representations in C terms (undefined 
behavior if used, no consistency expected or required).  Valid 
representations must have that MSB set for nonzero exponents and clear for 
zero exponents.

[Bug rtl-optimization/67577] Trivial float-vectorization foiled by a loop

[bisqwit at iki dot fi]

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

--- Comment #1 from Joel Yliluoma  ---
It may be also worth mentioning that adding an explicit '#pragma omp simd'
before each of those loops, inside the operator functions, will make sure that
GCC at least does the mathematics using packed registers. The memory store
cannot apparently be forced to occur without redundant temporaries though.

[Bug c++/44282] fastcall is not mangled at all

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Mon Sep 14 19:54:27 2015
New Revision: 227761

URL: https://gcc.gnu.org/viewcvs?rev=227761=gcc=rev
Log:
PR c++/44282

* mangle.c (write_CV_qualifiers_for_type): Also warn about regparm
mangling with lower -fabi-version.

Added:
trunk/gcc/testsuite/g++.dg/abi/mangle-regparm1a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c

[Bug fortran/67460] [5 Regression] Spurious: f951: all warnings being treated as errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

  Known to work||6.0
   Target Milestone|--- |5.2
Summary|[5/6 Regression] Spurious:  |[5 Regression] Spurious:
   |f951: all warnings being|f951: all warnings being
   |treated as errors   |treated as errors
  Known to fail|6.0 |

--- Comment #6 from Manuel López-Ibáñez  ---
Fixed in GCC 6.

[Bug c++/67579] New: [concepts] Memoization for constraint expressions

[Casey at Carter dot net]

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

Bug ID: 67579
   Summary: [concepts] Memoization for constraint expressions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

While implementing the Ranges TS I've found that the implementation of concepts
in GCC scales very poorly to larger and more complex systems. I've been able to
achieve 1-2 order of magnitude improvements in compile time and memory usage by
hand coding memoization for some concepts with constexpr variable templates.
E.g., replacing

  template 
  concept bool Foo = // requirements

with

  template 
  constexpr bool Foo_ = false;
  template 
requires // requirements
  constexpr bool Foo_ = true;

  template 
  concept bool Foo = Foo_;

which is fine when Foo need not participate in subsumption relationships. If
Foo *does* need to participate in subsumption relationships then performing
this transformation by hand is not possible since it hides the relationship
between Foo and "requirements" from the compiler's view.

If concepts & constraint expressions are to be generally applicable the
implementation must provide some means of reducing the cost of repeated
evaluation.

[Bug fortran/67460] [5/6 Regression] Spurious: f951: all warnings being treated as errors

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
Author: manu
Date: Mon Sep 14 19:27:50 2015
New Revision: 227760

URL: https://gcc.gnu.org/viewcvs?rev=227760=gcc=rev
Log:
The flag diagnostic_context::some_warnings_are_errors controls whether
to give the message "all warnings being treated as errors". However, when
warnings are buffered and then discarded, this flag is not reset. It turns
out we do not need this flag at all, since we already count explicitly how
many warnings were converted into errors, and this number is kept up to
date for the buffered diagnostics used by Fortran.

gcc/ChangeLog:

2015-09-14  Manuel López-Ibáñez  

PR fortran/67460
* diagnostic.c (diagnostic_initialize): Do not set
some_warnings_are_errors.
(diagnostic_finish): Use DK_WERROR count instead.
(diagnostic_report_diagnostic): Do not set
some_warnings_are_errors.
* diagnostic.h (struct diagnostic_context): Remove
some_warnings_are_errors.

gcc/testsuite/ChangeLog:

2015-09-14  Manuel López-Ibáñez  

PR fortran/67460
* gfortran.dg/pr67460.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/pr67460.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/67534] libgfortran.h sanitizer complains on left shift of ~0 runtime error: left shift of negative value -1

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to Vittorio Zecca from comment #3)
> I tested on trunk. The sanitizer message disappeared.

I'll close the bug, then. A latent bug on an older branch is probably not
enough incentive to backport a fix…

[Bug other/67552] [meta] x86 interrupt attribute

[julia.koval at intel dot com]

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

--- Comment #5 from Yulia Koval  ---
Sorry, I don't understand why we shouldn't preserve the red zone. The function
"foo", executing before the interrupt was called, used its red zone. If the
interrupt does not adjust the stack pointer, who control that "foo" function's
red zone would not be overwritten?

[Bug c/67569] New: erroneous compiler error message

[ka_bena at yahoo dot fr]

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

Bug ID: 67569
   Summary: erroneous compiler error message
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ka_bena at yahoo dot fr
  Target Milestone: ---

/* Erroneous compiler error message */

 int main(void)
{
   int   *A = (int *)533 ;
   float  F = 1.F;
   A - F ;   
   return 0 ;
}

/*
   Results:
   In function 'main':
   main_comp_err_msg.c:6:5: 
   erreur: invalid operands to binary - (have 'int *' and 'long double')
   A-F;
 ^
   Note:
   The variable F is not of type long double.

   Microsoft Windows XP Profesional version2002 Service Pack 3.
   Gcc 4.8.0 win32 mingw32 -std=C99 

*/

[Bug c/67570] New: comparison rules fails

[ka_bena at yahoo dot fr]

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

Bug ID: 67570
   Summary: comparison rules fails
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ka_bena at yahoo dot fr
  Target Milestone: ---

#include 

 int main(void)
{ 
   int pos;
   int pos1   ;
   int pos2   ;
   long double A= 0.L ;

   union { 
   long double X ; 
   char unsigned mask[sizeof(A)] ; 
 } alfa ;

   alfa.X = A;
   pos= 32   ;
   pos1   = 11 - ( pos - 1 ) / 8 ;
   pos2   = 8;

   alfa.mask[pos1] =((char unsigned )1 << (sizeof(char unsigned) * 8 - pos2)) ^
alfa.mask[pos1] ;

   printf ( "   [alfa.X]= %LE \n" , alfa.X) ; 
   printf ( "   [alfa.X == 0.L] = %i  \n" , alfa.X == 0.L ) ; 
   printf ( "   [alfa.X != 0.L] = %i  \n" , alfa.X != 0.L ) ; 
   printf ( "   [alfa.X <= 0.L] = %i  \n" , alfa.X <= 0.L ) ;   
   printf ( "   [alfa.X >= 0.L] = %i  \n" , alfa.X >= 0.L ) ;   
   printf ( "   [alfa.X <  0.L] = %i  \n" , alfa.X <  0.L ) ;   
   printf ( "   [alfa.X >  0.L] = %i  \n" , alfa.X >  0.L ) ;   

   return 0 ;

}

/*

   Results:
   [alfa.X]= 0.00E+000  
   [alfa.X == 0.L] = 0  
   [alfa.X != 0.L] = 1  
   [alfa.X <= 0.L] = 0  
   [alfa.X >= 0.L] = 0  
   [alfa.X <  0.L] = 0  
   [alfa.X >  0.L] = 0 

   Note:
   Binary representation IEEE 754 of alfa.X is:
    0 001

   It seems that comparison rules fails in this case.

   Microsoft Windows XP Profesional version2002 Service Pack 3.
   Gcc 4.8.0 win32 mingw32 -std=C99 

*/

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #9 from Mark Wielaard  ---
Author: mark
Date: Mon Sep 14 09:49:47 2015
New Revision: 227742

URL: https://gcc.gnu.org/viewcvs?rev=227742=gcc=rev
Log:
PR28901 -Wunused-variable ignores unused const initialised variables in C

12 years ago it was decided that -Wunused-variable shouldn't warn about
static const variables because some code used const static char rcsid[]
strings which were never used but wanted in the code anyway. But as the
bug points out this hides some real bugs. These days the usage of rcsids
is not very popular anymore. So this patch changes the default to warn
about unused static const variables in C with -Wunused-variable. And it
adds a new option -Wno-unused-const-variable to turn this warning off.
For C++ this new warning is off by default, since const variables can be
used as #defines in C++. New testcases for the new defaults in C and C++
are included testing the new warning and suppressing it with an unused
attribute or using -Wno-unused-const-variable.

gcc/ChangeLog

   PR c/28901
   * toplev.c (check_global_declaration): Check and use
   warn_unused_const_variable.
   * doc/invoke.texi (Warning Options): Add -Wunused-const-variable.
   (-Wunused-variable): Remove non-constant. For C implies
   -Wunused-const-variable.
   (-Wunused-const-variable): New.

gcc/c-family/ChangeLog

   PR c/28901
   * c.opt (Wunused-variable): Option from common.opt.
   (Wunused-const-variable): New option.

gcc/cp/ChangeLog

   PR c/28901
   * cp-objcp-common.c (cxx_warn_unused_global_decl): Remove hard-coded
   VAR_P TREE_READONLY override.

gcc/testsuite/ChangeLog

   PR c/28901
   * g++.dg/warn/unused-variable-1.C: New test.
   * g++.dg/warn/unused-variable-2.C: Likewise.
   * gcc.dg/unused-4.c: Adjust warning for static const.
   * gcc.dg/unused-variable-1.c: New test.
   * gcc.dg/unused-variable-2.c: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/warn/unused-variable-1.C
trunk/gcc/testsuite/g++.dg/warn/unused-variable-2.C
trunk/gcc/testsuite/gcc.dg/unused-variable-1.c
trunk/gcc/testsuite/gcc.dg/unused-variable-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/unused-4.c
trunk/gcc/toplev.c

[Bug c++/67571] New: Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

Bug ID: 67571
   Summary: Error: open CFI at the end of file; missing
.cfi_endproc directive
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: werner at beroux dot com
  Target Milestone: ---

gcc (Debian 4.9.2-10) 4.9.2

Steps:

1. Install Docker
2. Retrieve `Dockerfile`: `$ wget
https://raw.githubusercontent.com/wernight/docker-phantomjs/master/Dockerfile`
3. Get latest Debian: `$ docker pull debian:jessie`
3. Run `$ docker build -t phantomjs .`


Log end:

```
g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wchar-subscripts
-Wformat-security -Wreturn-type -Wno-unused-parameter -Wno-sign-compare
-Wno-switch -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -pipe
-ffunction-sections -fdata-sections -O2 -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -std=c++0x -fno-exceptions -D_REENTRANT
-DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_GRAPHICSVIEW
-DQT_NO_GRAPHICSEFFECT -DQT_NO_STYLESHEET -DQT_NO_STYLE_CDE
-DQT_NO_STYLE_CLEANLOOKS -DQT_NO_STYLE_MOTIF -DQT_NO_STYLE_PLASTIQUE
-DSQLITE_CORE -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_COMPLETE
-DBUILDING_QT__=1 -DNDEBUG -DENABLE_3D_RENDERING=1 -DENABLE_BLOB=1
-DENABLE_CANVAS_PATH=1 -DENABLE_CHANNEL_MESSAGING=1
-DENABLE_CSS_BOX_DECORATION_BREAK=1 -DENABLE_CSS_COMPOSITING=1
-DENABLE_CSS_EXCLUSIONS=1 -DENABLE_CSS_FILTERS=1 -DENABLE_CSS_IMAGE_SET=1
-DENABLE_CSS_REGIONS=1 -DENABLE_CSS_SHAPES=1 -DENABLE_CSS_STICKY_POSITION=1
-DENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED=1 -DENABLE_DATALIST_ELEMENT=1
-DENABLE_DETAILS_ELEMENT=1 -DENABLE_DOWNLOAD_ATTRIBUTE=1
-DENABLE_FAST_MOBILE_SCROLLING=1 -DENABLE_FILTERS=1 -DENABLE_FTPDIR=1
-DENABLE_FULLSCREEN_API=1 -DENABLE_GESTURE_EVENTS=1 -DENABLE_ICONDATABASE=1
-DENABLE_IFRAME_SEAMLESS=1 -DENABLE_INDEXED_DATABASE=1
-DENABLE_INPUT_TYPE_COLOR=1 -DENABLE_INSPECTOR=1 -DENABLE_INSPECTOR_SERVER=1
-DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_LEGACY_NOTIFICATIONS=1
-DENABLE_LEGACY_VIEWPORT_ADAPTION=1 -DENABLE_LEGACY_VENDOR_PREFIXES=1
-DENABLE_LINK_PREFETCH=1 -DENABLE_METER_ELEMENT=1 -DENABLE_MHTML=1
-DENABLE_NOTIFICATIONS=1 -DENABLE_PAGE_VISIBILITY_API=1
-DENABLE_PROGRESS_ELEMENT=1 -DENABLE_RESOLUTION_MEDIA_QUERY=1
-DENABLE_REQUEST_ANIMATION_FRAME=1 -DENABLE_SHARED_WORKERS=1
-DENABLE_SMOOTH_SCROLLING=1 -DENABLE_SQL_DATABASE=1 -DENABLE_SUBPIXEL_LAYOUT=1
-DENABLE_SVG=1 -DENABLE_SVG_FONTS=1 -DENABLE_TOUCH_ADJUSTMENT=1
-DENABLE_TOUCH_EVENTS=1 -DENABLE_VIEW_MODE_CSS_MEDIA=1 -DENABLE_WEB_SOCKETS=1
-DENABLE_WEB_TIMING=1 -DENABLE_WORKERS=1 -DENABLE_XHR_TIMEOUT=1
-DWTF_USE_TILED_BACKING_STORE=1 -DWTF_USE_CROSS_PLATFORM_CONTEXT_MENUS=1
-DHAVE_QTPRINTSUPPORT=1 -DHAVE_QSTYLE=1 -DWTF_USE_LIBJPEG=1 -DWTF_USE_LIBPNG=1
-DPLUGIN_ARCHITECTURE_UNSUPPORTED=1 -DENABLE_TOUCH_SLIDER=1 -DWTF_USE_LEVELDB=1
-DHAVE_QTTESTSUPPORT=1 -DENABLE_ACCELERATED_2D_CANVAS=0
-DENABLE_BATTERY_STATUS=0 -DENABLE_CANVAS_PROXY=0 -DENABLE_CSP_NEXT=0
-DENABLE_CSS_GRID_LAYOUT=0 -DENABLE_CSS_HIERARCHIES=0
-DENABLE_CSS_IMAGE_ORIENTATION=0 -DENABLE_CSS_IMAGE_RESOLUTION=0
-DENABLE_CSS_SHADERS=0 -DENABLE_CSS_VARIABLES=0
-DENABLE_CSS3_CONDITIONAL_RULES=0 -DENABLE_CSS3_TEXT=0
-DENABLE_CSS3_TEXT_LINE_BREAK=0 -DENABLE_DASHBOARD_SUPPORT=0
-DENABLE_DATAGRID=0 -DENABLE_DATA_TRANSFER_ITEMS=0
-DENABLE_DEVICE_ORIENTATION=0 -DENABLE_DIRECTORY_UPLOAD=0
-DENABLE_FILE_SYSTEM=0 -DENABLE_FONT_LOAD_EVENTS=0 -DENABLE_GAMEPAD=0
-DENABLE_GEOLOCATION=0 -DENABLE_HIGH_DPI_CANVAS=0 -DENABLE_INPUT_SPEECH=0
-DENABLE_INPUT_TYPE_DATE=0 -DENABLE_INPUT_TYPE_DATETIME_INCOMPLETE=0
-DENABLE_INPUT_TYPE_DATETIMELOCAL=0 -DENABLE_INPUT_TYPE_MONTH=0
-DENABLE_INPUT_TYPE_TIME=0 -DENABLE_INPUT_TYPE_WEEK=0
-DENABLE_LEGACY_CSS_VENDOR_PREFIXES=0 -DENABLE_LEGACY_WEB_AUDIO=0
-DENABLE_MATHML=0 -DENABLE_MEDIA_SOURCE=0 -DENABLE_MEDIA_STATISTICS=0
-DENABLE_MEDIA_STREAM=0 -DENABLE_MICRODATA=0 -DENABLE_MOUSE_CURSOR_SCALE=0
-DENABLE_NAVIGATOR_CONTENT_UTILS=0 -DENABLE_NETSCAPE_PLUGIN_API=0
-DENABLE_NETWORK_INFO=0 -DENABLE_NOSNIFF=0 -DENABLE_ORIENTATION_EVENTS=0
-DENABLE_PROXIMITY_EVENTS=0 -DENABLE_QUOTA=0 -DENABLE_RESOURCE_TIMING=0
-DENABLE_SCRIPTED_SPEECH=0 -DENABLE_SECCOMP_FILTERS=0 -DENABLE_SHADOW_DOM=0
-DENABLE_STYLE_SCOPED=0 -DENABLE_TEMPLATE_ELEMENT=0 -DENABLE_TEXT_AUTOSIZING=0
-DENABLE_THREADED_HTML_PARSER=0 -DENABLE_TOUCH_ICON_LOADING=0
-DENABLE_USER_TIMING=0 -DENABLE_VIBRATION=0 -DENABLE_VIDEO=0
-DENABLE_VIDEO_TRACK=0 -DENABLE_WEBGL=0 -DENABLE_WEB_AUDIO=0 -DENABLE_XSLT=0
-DSTATICALLY_LINKED_WITH_leveldb -DSTATICALLY_LINKED_WITH_JavaScriptCore
-DSTATICALLY_LINKED_WITH_WTF -DBUILDING_WebCore -DBUILDING_WEBKIT
-DQT_ASCII_CAST_WARNINGS -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_GUI_LIB
-DQT_CORE_LIB -I/tmp/phantomjs/src/qt/qtbase/mkspecs/linux-g++ -I. -I.
-IModules/filesystem 

[Bug middle-end/67563] [5/6 Regression] verify_flow_info failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |middle-end
   Target Milestone|--- |5.3
Summary|verify_flow_info failed |[5/6 Regression]
   ||verify_flow_info failed

--- Comment #2 from Marek Polacek  ---
Started with r218317.

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I bet this isn't a gcc fault; just OOM kills the compiler:

g++: internal compiler error: Killed (program cc1plus)

Please try with more memory.

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-14
 CC||manu at gcc dot gnu.org
Summary|pretty-print.h sanitizer|resolve.c: gfc_error called
   |detects NULL pointer passed |with iface->module == NULL
   |to obstack_grow |
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Vittorio Zecca from comment #0)
> but I believe it best to fix it by prefixing the statement with "if(length)"

That would hide the real bug, which is that:

  gfc_error ("%s between the MODULE PROCEDURE declaration "
 "in module %s and the declaration at %L in "
 "SUBMODULE %s", errmsg, iface->module,
 >declared_at, sym->ns->proc_name->name);

is called with iface->module == NULL.

(I think you are doing a nice job at finding and reporting all these sanitizer
issues, but it would be better to figure out the real causes in order to
implement the best solution, and for that you need to master GDB. Otherwise,
developers eager to close as many issues as fast as possible may end up slowing
down the compiler with unnecessary checks while hiding real bugs).

[Bug c/67569] erroneous compiler error message

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Marek Polacek  ---
Can't reproduce:

h1.c: In function ‘main’:
h1.c:5:6: error: invalid operands to binary - (have ‘int *’ and ‘float’)

Also, gcc 4.8 is not supported anymore.