[Bug c++/64842] Implicitly defined constructor isn't constexpr

[simendsjo at simendsjo dot me]

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

--- Comment #2 from simendsjo at simendsjo dot me ---
(In reply to Ville Voutilainen from comment #1)
> The constructors for Point are constexpr, but since p2 is not, passing
> it as an argument for scale() means that the invocation of scale() will not
> yield a constant expression. If you change the declaration of p2 to
> be
> constexpr Point p2 {10,10};
> the code will work. Clang agrees with gcc.

Then there are a couple of possibilities:
1. The spec is wrong
2. Bjarne Stroustrup misinterprets the spec
3. gcc and clang has the same bug

You're saying that 2. holds. In that case, send a mail to Stroustrup so he can
correct his book "Programming: Principles and Practice using C++".

[Bug target/65167] ICE: in assign_by_spills, at lra-assigns.c:1383 (unable to find a register to spill) with -O -fschedule-insns -fcheck-pointer-bounds -mmpx

[enkovich.gnu at gmail dot com]

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

--- Comment #6 from Ilya Enkovich  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Ilya Enkovich from comment #4)
> 
> > +  if (TARGET_MPX && BND_REGNO_P (regno))
> 
> No need for TARGET_MPX check, there will be no bnd regs when this flag is
> cleared.

__builtin_apply_args stores all registers that might be used to pass arguments
to a function.  With no target check it will always try to store bounds with no
instructions to do that.

[Bug c++/64842] Implicitly defined constructor isn't constexpr

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Email sent to Bjarne.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener  ---
(In reply to Alexandre Oliva from comment #26)
> I had failed to measure peak memory use.  It went down from more than 4.8G
> to less than 460M (vs 380MB without debug info).  Wheee!

Wheee!

Note that this is exactly what I had in mind (kind of) - we should "DCE"
debug stmts when at the given text address the debugger cannot refer to
the entity the debug stmt is for - for example if the current scope is
simply not nested inside of the scope the debug entity is for.

In theory remove_unused_locals could do that - in the walk over
have_local_clobbers remove all GIMPLE debug stmts that have an
unused BLOCK associated.  Note that we still won't remove the actual BLOCKs
as we keep BLOCKs live with associated user-vars (but no associated
statements),
see remove_unused_scope_block_p.  Still removing debug statements associated
with such block (well, rather debug stmts with a LHS which is associated with
an unused BLOCK... - which is not exactly the same) should be possible.
Of course this should be done on the RTL level close to var-tracking but
it might be what your patch ends up effectively doing as well.

[Bug libfortran/65200] New: Handle EPERM when opening files

[jb at gcc dot gnu.org]

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

Bug ID: 65200
   Summary: Handle EPERM when opening files
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org

In some cases at least Linux can return an EPERM rather than EACCES error in
case opening a file fails, see

https://stackoverflow.com/questions/28696539/fortran-open-call-differs-on-nfsv3-vs-nfsv4

Based on some googling, the distinction between EACCES and EPERM are something
like

- EACCESS: Insufficient privilege. E.g. do the same as root and this should
work.
- EPERM: Operation not permitted. That is, no matter the privilege level, this
isn't allowed. E.g. truncating a file opened with O_APPEND and such.

but as can be seen in the URL above, both seem to be used depending on various
details.

This should be a simple fix in io/unix.c.

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

Leon Winter  changed:

   What|Removed |Added

Version|4.9.1   |5.0

--- Comment #3 from Leon Winter  ---
Like, Manuel mentioned already, this in fact applies to gcc-5.0 as I was
mistaken on the version (executing gcc -v on the wrong machine)

[Bug c++/65201] New: range-for range-init containing variable named like for-range-declaration iterates over uninitialized for-range-declaration

[bloerwald at googlemail dot com]

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

Bug ID: 65201
   Summary: range-for range-init containing variable named like
for-range-declaration iterates over uninitialized
for-range-declaration
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bloerwald at googlemail dot com

#include 
#include 
#include 

template
  std::vector split (T in, typename T::value_type delim);
// … see below

void choke (std::string foo)
{
  for (std::string foo : split (foo, ' '))
  {
std::cout << foo << std::endl;
  }
}

int main (int, char**)
{
  choke ("foo bar baz");
  return 0;
}

The above compiles and runs fine with clang 3.5.1:

$ clang++ -Weverything --std=c++11 gcc_range_for_choke.cpp -o
gcc_range_for_choke
gcc_range_for_choke.cpp:33:20: warning: declaration shadows a local
variable [-Wshadow]
  for (std::string foo : split (foo, ' '))
[… other warnings]
$ ./gcc_range_for_choke
foo
bar
baz

but fails miserably with gcc 4.9.2,

$ c++ --std=c++11 -Wall -Wextra gcc_range_for_choke.cpp -o
gcc_range_for_choke -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations
gcc_range_for_choke.cpp:31:25: warning: unused parameter ‘foo’
[-Wunused-parameter]
 void choke (std::string foo)
 ^
$ ./gcc_range_for_choke
Segmentation fault

(The segfault comes from directly accessing the unitialized `T in`.)

I realize what happens, but according to what I understand in the standard, it
has to be equivalent to

{
  auto && __range = range-init;
  for ( auto __begin = begin-expr, __end = end-expr; __begin != __end;
++__begin )
  {
for-range-declaration = *__begin;
statement
  }
}

The (clang reported) shadowing is real, but `range-init` most certainly can't
refer to `for-range-declaration`, as of what I understand.


Bonus: Badly implemented split for completeness:

template
  std::vector split (T in, typename T::value_type delim)
{
  std::vector ret;
  T key;
  for (auto const& e : in)
  {
if (e == delim)
{
  ret.push_back (key);
  key.clear();
}
else
{
  key.push_back (e);
}
  }
  if (!key.empty())
  {
ret.push_back (key);
  }
  return ret;
}

Note: confirmed to exist on 4.8.2, untested on 4.9.3, 5.0.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
   
COLLECT_LTO_WRAPPER=/p/hpc/soft/gcc/4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/p/hpc/soft/gcc/4.9.2
Thread model: posix
gcc version 4.9.2 (GCC)

[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior

[ams at gcc dot gnu.org]

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

--- Comment #13 from Andrew Stubbs  ---
I thought of that, but my testcase has 2 exits.

I thought of only warning when all the exits were being removed, but the
loop->bounds list does not include all the exits, so that can't happen either.

I thought of only warning when all the loop exits are beyond the UB, but then I
realised that that's exactly what the code already does; it just doesn't help
when the loop has been turned inside out like this.

Fundamentally, the problem is that the head of the first iteration and the
effective head of the last iteration are not necessarily one and the same. I
can't see an obvious way to start the walk from somewhere else though.

In any case, the bounds reduction code does the right thing, it's just the
warning that's broken, so it might just be best to remove it.

I'd still like to have the warning though. Perhaps the best way would be to
warn at the point where the last exit is actually removed?

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

--- Comment #15 from Dmitry G. Dyachenko  ---
(In reply to Jakub Jelinek from comment #14)
> So, can the reporter or anyone else still reproduce a problem in this area
> or can it be considered fixed?

last FAIL for me r219878
first PASS for me r219927
r220888 PASS for me

original issue with unreduced code go away starting r219927

[Bug fortran/48478] Array-constructor with type-spec: reject valid/accept invalid

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #2 from Francois-Xavier Coudert  ---
Confirmed fixed in 4.9 and later.

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux

[clyon at gcc dot gnu.org]

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

--- Comment #53 from clyon at gcc dot gnu.org ---
The new patch I proposed has been accepted and committed upstream as r230324.

Can I cherry-pick it in GCC?

[Bug c++/65201] range-for range-init containing variable named like for-range-declaration iterates over uninitialized for-range-declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Trunk gives:

terminate called after throwing an instance of 'std::logic_error' what():
basic_string::_M_construct null not valid

[Bug tree-optimization/65063] [4.8 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 25 10:28:01 2015
New Revision: 220960

URL: https://gcc.gnu.org/viewcvs?rev=220960&root=gcc&view=rev
Log:
2015-02-25  Richard Biener  

Backport from mainline
2015-02-16  Richard Biener  

PR tree-optimization/63593
* tree-predcom.c (execute_pred_commoning_chain): Delay removing
stmts and releasing SSA names until...
(execute_pred_commoning): ... after processing all chains.

* gcc.dg/pr63593.c: New testcase.

2015-02-18  Richard Biener  

PR tree-optimization/65063
* tree-predcom.c (determine_unroll_factor): Return 1 if we
have replaced looparound PHIs.

* gcc.dg/pr65063.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63593.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr65063.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-predcom.c

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 25 10:28:01 2015
New Revision: 220960

URL: https://gcc.gnu.org/viewcvs?rev=220960&root=gcc&view=rev
Log:
2015-02-25  Richard Biener  

Backport from mainline
2015-02-16  Richard Biener  

PR tree-optimization/63593
* tree-predcom.c (execute_pred_commoning_chain): Delay removing
stmts and releasing SSA names until...
(execute_pred_commoning): ... after processing all chains.

* gcc.dg/pr63593.c: New testcase.

2015-02-18  Richard Biener  

PR tree-optimization/65063
* tree-predcom.c (determine_unroll_factor): Return 1 if we
have replaced looparound PHIs.

* gcc.dg/pr65063.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63593.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr65063.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-predcom.c

[Bug c++/65202] New: [5.0 regression]ICE segfault with constexpr/noexcept

[lucdanton at free dot fr]

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

Bug ID: 65202
   Summary: [5.0 regression]ICE segfault with constexpr/noexcept
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

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

Using:

$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20150223 (experimental)

--

I get the following trace:

$ g++-trunk -std=c++1y main.cpp
main.cpp: In instantiation of 'decltype (adl::adl_swap(l, r)) adl::swap(L&, R&)
[with L = adl::ns::foo; R = adl::ns::foo; decltype
(adl::adl_swap(l, r)) = void]':
main.cpp:22:19:   required from here
main.cpp:12:54:   in constexpr expansion of
'adl::adl_swap, adl::ns::foo, {}>((* &
l), (* & r))'
main.cpp:12:6: internal compiler error: Segmentation fault
 auto swap(L &l, R &r) noexcept(noexcept(adl::adl_swap(l, r)))
  ^
0xa93f2f crash_signal
../../gcc/gcc/toplev.c:383
0x6f0cfa cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:2943
0x6f138a cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3118
0x6f068b cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1392
0x6f0e44 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3022
0x6f3627 is_sub_constant_expr(tree_node*)
../../gcc/gcc/cp/constexpr.c:3604
0x69761d check_noexcept_r
../../gcc/gcc/cp/except.c:1178
0xc8c7c4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
../../gcc/gcc/tree.c:11086
0xc8df58 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set*))
../../gcc/gcc/tree.c:11416
0x69732f expr_noexcept_p(tree_node*, int)
../../gcc/gcc/cp/except.c:1255
0x697492 finish_noexcept_expr(tree_node*, int)
../../gcc/gcc/cp/except.c:1240
0x60c308 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14895
0x625e9d maybe_instantiate_noexcept(tree_node*)
../../gcc/gcc/cp/pt.c:20012
0x64104f mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4941
0x5da459 build_over_call
../../gcc/gcc/cp/call.c:7489
0x5e3261 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4104
0x6ac979 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2407
0x660689 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6368
0x66274a cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7438
0x6632e8 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8173
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

--

Instead, I would expect the compiler to complain due to e.g. the namespaces
left
unclosed. (The testcase has been mechanically reduced so is nonsensical.) This
is what happens with 4.8 and 4.9.

[Bug tree-optimization/65063] [4.8 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Bug 63593 Summary: ICE: verify_gimple failed: incompatible types in PHI 
argument 0 with -O3 -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63593

   What|Removed |Added

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

[Bug tree-optimization/65063] [4.8 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.5
 Resolution|--- |FIXED
  Known to fail||4.8.4

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

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.5
 Resolution|--- |FIXED

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

[Bug libfortran/65203] New: Document fall-back to read-only access

[tkoenig at gcc dot gnu.org]

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

Bug ID: 65203
   Summary: Document fall-back to read-only access
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org

Currently, when encountering EACCES or EROFS upon opening, we fall back towards
opening the file read-only.

This is

a) not documented
b) surprising for some users (an inconsistency has been commented upon)
c) causes inconsistencies with NFS v4, which appears to return EPERM for a
read-only file for no reason that I can see.

The original report can be found at
http://stackoverflow.com/questions/28696539/fortran-open-call-differs-on-nfsv3-vs-nfsv4
.

My suggestion would be to a) document and c) extend the behavior to EPERM.

[Bug c++/65199] Linker failure with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Try marking your memcpy with __attribute__((used)).

[Bug c++/65198] [5 Regression] User-defined literal template inside generic lambda segfaults GCC 5.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[4.9 regression]|[5 Regression] User-defined
   |User-defined literal|literal template inside
   |template inside generic |generic lambda segfaults
   |lambda segfaults GCC 5.0|GCC 5.0

[Bug c++/65198] [4.9 regression] User-defined literal template inside generic lambda segfaults GCC 5.0

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Works for me with 20150220 (r220835).

[Bug lto/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will have a look (sounds like a know issue with a not backported patch).

[Bug tree-optimization/65204] New: Aligned address optimization not detected

[ktietz at gcc dot gnu.org]

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

Bug ID: 65204
   Summary: Aligned address optimization not detected
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktietz at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org

By testing on c++-delayed-folding branch I noticed that gcc doesn't optimize
issues as tested in 'c-c++-common/fold-bitand4.c' anymore.
By looking deeper into it it shows that CCP doesn't simplify this because it
doesn't track about copy-of.

The testcase demonstrates this:

typedef char char4[4] __attribute__ ((aligned (4)));
char4 c4[4] __attribute__ ((aligned (16)));

int f (int i)
{
  __SIZE_TYPE__ h = (__SIZE_TYPE__)&c4[i];
  /* 0 */
  return 3 & h;
}

[Bug tree-optimization/65204] Aligned address optimization not detected

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I have a very simple patch.

[Bug ipa/64641] ICE in get_polymorphic_call_info with C-cast to (polymorphic) object-reference

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Kai Tietz  ---
Confirmed.

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Kai Tietz  ---
Yes, issue got fixed beginning with 4.8.2 (and higher) as verified by testing
through versions.
So close this bug.

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  ---
Just as note:  This issue got partial addressed for 4.8 gcc for cross-compiler
version. We place bitness-version into specific lib folder for bitness.
Just for native mode - for being compatible with existing build-scenarios of
native compiler - we still place target's libgcc's DLL into host's bin-folder. 
This issue is just present for native multilib-version.

[Bug c++/65199] Linker failure with -flto

[goswin-v-b at web dot de]

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

--- Comment #2 from Goswin von Brederlow  ---
That fixes it. Isn't it a gcc bug though not to detect that itself?

[Bug target/65196] avr_adjust_insn_length uses recog_memoized on invalid insn

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Feb 25 12:18:51 2015
New Revision: 220963

URL: https://gcc.gnu.org/viewcvs?rev=220963&root=gcc&view=rev
Log:
PR target/65196
* config/avr/avr.c (avr_adjust_insn_length): Call recog_memoized
only with NONDEBUG_INSN_P.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/avr/avr.c

[Bug target/65196] avr_adjust_insn_length uses recog_memoized on invalid insn

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Feb 25 12:26:41 2015
New Revision: 220964

URL: https://gcc.gnu.org/viewcvs?rev=220964&root=gcc&view=rev
Log:
PR target/65196
* config/avr/avr.c (avr_adjust_insn_length): Call recog_memoized
only with NONDEBUG_INSN_P.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug target/65196] avr_adjust_insn_length uses recog_memoized on invalid insn

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Feb 25 12:34:21 2015
New Revision: 220965

URL: https://gcc.gnu.org/viewcvs?rev=220965&root=gcc&view=rev
Log:
PR target/65196
* config/avr/avr.c (avr_adjust_insn_length): Call recog_memoized
only with NONDEBUG_INSN_P.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/avr/avr.c

[Bug testsuite/65205] New: Wrong dh-shouldfail usage in OpenACC libgomp tests

[tschwinge at gcc dot gnu.org]

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

Bug ID: 65205
   Summary: Wrong dh-shouldfail usage in OpenACC libgomp tests
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: major
  Priority: P3
 Component: testsuite
  Assignee: jnorris at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org

A bunch of the OpenACC libgomp tests that we added are expected to terminate
with an error exit status, and printing specific error message.  For a lot of
them, we wrongly just used dg-shouldfail directives to codify this, providing
the expected error message as the comment argument to dg-shouldfail.  Separate
dg-output directives should be used instead, so that we can detect if the test
case actually does fail, but not for the expected reason (that is, with the
specific error message).  (See
libgomp/testsuite/libgomp.oacc-fortran/data-already-1.f, for example.)

[Bug target/65196] avr_adjust_insn_length uses recog_memoized on invalid insn

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.5, 4.9.3
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.3
  Known to fail||4.8.4, 4.9.2

--- Comment #4 from Georg-Johann Lay  ---
Fixed.

[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz  ---
Issue is fixed on 5.0 gcc.  But confirm that issue still exists on 4.9 branch.

[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #6 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 13:36:00 2015
New Revision: 220966

URL: https://gcc.gnu.org/viewcvs?rev=220966&root=gcc&view=rev
Log:
2015-02-25  Richard Biener  
Kai Tietz  

PR tree-optimization/61917
* tree-vect-loop.c (vectorizable_reduction): Allow
vect_internal_def without reduction to exit graceful.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 13:42:12 2015
New Revision: 220967

URL: https://gcc.gnu.org/viewcvs?rev=220967&root=gcc&view=rev
Log:
PR tree-optimization/61917
* gcc.dg/vect/vect-pr61917.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-pr61917.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[4.9/5 Regression] ICE on   |[4.9 Regression] ICE on
   |valid code at -O3 on|valid code at -O3 on
   |x86_64-linux-gnu in |x86_64-linux-gnu in
   |vectorizable_reduction, at  |vectorizable_reduction, at
   |tree-vect-loop.c:4913   |tree-vect-loop.c:4913

--- Comment #8 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/51017] [4.8/4.9/5 Regression] GCC performance regression (vs. 4.4/4.5), PRE increases register pressure too much

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug testsuite/64145] [5 Regression] gcc.dg/graphite/isl-codegen-loop-dumping.c UNRESOLVED after r217315.

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on trunk back in in December, forgot to close last night.

[Bug tree-optimization/65206] New: Vectorized version of loop is removed.

[ysrumyan at gmail dot com]

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

Bug ID: 65206
   Summary: Vectorized version of loop is removed.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

I noticed that vectorized version of loop is deleted although compiler reports
that it was successfully vectorized:
t1.c:7:3: note: LOOP VECTORIZED

but after we can see in vect-dump:

Removing basic block 4
basic block 4, loop depth 1
 pred:   45
# i_16 = PHI 
# ivtmp_15 = PHI 
# vectp_a1.11_116 = PHI 
# vectp_a2.19_125 = PHI 
# vectp_a3.22_130 = PHI 
# vectp_a1.25_136 = PHI 
# vectp_a3.34_147 = PHI 
# ivtmp_38 = PHI <0(45)>
vect__5.13_118 = MEM[(float *)vectp_a1.11_116];
_5 = a1[i_16];
_31 = &a2[i_16];
vect__ifc__32.14_122 = VEC_COND_EXPR = vect_cst_.15_119,
vect_cst_.16_120, vect_cst_.17_121>;
_ifc__32 = _5 >= x_6(D) ? 4294967295 : 0;
vect__7.18_127 = MASK_LOAD (vectp_a2.19_125, 0B, vect__ifc__32.14_122);
_7 = 0.0;
_33 = &a3[i_16];
vect__8.21_132 = MASK_LOAD (vectp_a3.22_130, 0B, vect__ifc__32.14_122);
_8 = 0.0;
vect__9.24_133 = vect__7.18_127 + vect__8.21_132;
_9 = _7 + _8;
_34 = &a1[i_16];
MASK_STORE (vectp_a1.25_136, 0B, vect__ifc__32.14_122, vect__9.24_133);
vect__11.27_140 = vect_cst_.28_37 + vect_cst_.29_139;
_11 = x_6(D) + 1.0e+0;
_35 = &a3[i_16];
vect__ifc__36.30_144 = VEC_COND_EXPR = vect_cst_.31_141,
vect_cst_.32_142, vect_cst_.33_143>;
_ifc__36 = _5 >= x_6(D) ? 0 : 4294967295;
...

Test and compile options will be attached.

[Bug tree-optimization/65206] Vectorized version of loop is removed.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 34867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34867&action=edit
test-case to reproduce

Test needs to be compiled with -Ofast -m64 -mcore-avx2 options.

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 14:12:46 2015
New Revision: 220968

URL: https://gcc.gnu.org/viewcvs?rev=220968&root=gcc&view=rev
Log:

2015-02-25  Richard Biener  
Kai Tietz  

Backport from mainline
PR tree-optimization/61917
* tree-vect-loop.c (vectorizable_reduction): Allow
vect_internal_def without reduction to exit graceful.

ChangeLog testsuite/

2015-02-25  Kai Tietz  

Backport from mainline
PR tree-optimization/61917
* gcc.dg/vect/vect-pr61917.c: New file.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/vect-pr61917.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-loop.c

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #10 from Kai Tietz  ---
Fixed on trunk and 4.9

[Bug target/64997] [AArch64] Illegal EON on SIMD registers

[alalaw01 at gcc dot gnu.org]

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

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Wed Feb 25 14:20:13 2015
New Revision: 220969

URL: https://gcc.gnu.org/viewcvs?rev=220969&root=gcc&view=rev
Log:
[AArch64] Fix illegal assembly 'eon v1, v2, v3'

PR target/64997
* config/aarch64/aarch64.md (*xor_one_cmpl3): Use FP_REGNUM_P
as split condition; force split via '#' in output pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md

[Bug debug/53927] wrong value for DW_AT_static_link

[derodat at adacore dot com]

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

--- Comment #14 from Pierre-Marie de Rodat  ---
Created attachment 34868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34868&action=edit
patch to generate DWARF-compliant DW_AT_static_link attributes

gcc/
* tree-nested.c (finalize_nesting_tree_1): Append a field to
hold the frame base address.
* dwarf2out.c (gen_subprogram_die): Generate for
DW_AT_static_link a location description that computes the value
of this field.

[Bug debug/53927] wrong value for DW_AT_static_link

[derodat at adacore dot com]

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

Pierre-Marie de Rodat  changed:

   What|Removed |Added

 CC||derodat at adacore dot com

--- Comment #13 from Pierre-Marie de Rodat  ---
(In reply to Tom Tromey from comment #8)
> > Yes, but you can do something useful even with this value of
> > DW_AT_static_link, albeit not exactly what DWARF means.
> 
> Regardless, I think GCC should emit correct DWARF.

I gave it a try: see the attached patch.

Jason suggested to change DW_AT_frame_base in order to make it equal to the
address of the FRAME object. I was not sure:

 1) how to do it: location descriptions for all local variables would need to
be updated;
 2) whether it's safe to do this: what if optimizers move/duplicate this FRAME
object in the stack frame or do similar "disturbing" things? I'm not familiar
enough with optimization passes to estimate if it's likely: feedback welcome.
:-)

I thought: why not make DW_AT_static_link compute the parent frame base address
from the current static link argument? Well, when generating DW_AT_static_link
for a nested subprogram, we do not know yet the offset between the FRAME object
and the frame base address. This is because nested subprograms reach the
back-end before their parent. Besides, see point 2: are we only sure that such
a constant offset exists?

So instead, I patched tree-nested.c in order to append a field at the end of
the FRAME object to hold the frame base address (computed with the DWARF_CFA
builtin). Then, dwarf2out.c just has to emit a location description for nested
subprograms' DW_AT_static_link that fetches this using the static link
argument. It's consuming a little stack space, I'm not sure if it's a problem.
Once again: feedback welcome!

Besides, this does not work yet with Fortran since for this front-end, the
DWARF_CFA builtin is not registered. None of builtins.def are registered by the
way: how could I register only this one without duplicating code? Is it a good
idea anyway?

For the record, I bootstrapped and reg-tested this patch on x86_64-linux and
preliminary manual testing with a patched GDB[1] and Ada reproducers shows that
this approach is working.

Thoughts?

[1] This patch teaches GDB how to use DW_AT_static_link in order to find the
frame corresponding to the lexically enclosing scope. I think I will try to
submit it to GDB soon.

[Bug tree-optimization/65207] New: [5 regression] performance: tree level loop optimization does not peel SpecCPU href loop

[krebbel at gcc dot gnu.org]

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

Bug ID: 65207
   Summary: [5 regression] performance: tree level loop
optimization does not peel SpecCPU href loop
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

mv-search.c
SetupFastFullPelSearch

   for (blky = 0; blky < 4; blky++)
{
  LineSadBlk0 = LineSadBlk1 = LineSadBlk2 = LineSadBlk3 = 0;
  for (y = 0; y < 4; y++)
  {
refptr = PelYline_11 (ref_pic, abs_y++, abs_x, img_height, img_width);
...

After the loop peeling has been removed from RTL level this loop does not get
peeled completely as before on S/390 which results in a performance regression
(-5%).

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01211.html

The tree level loop peeling refuses to peel the loop because it contains a
function call.

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #6 from Kai Tietz  ---
(In reply to Jan Hubicka from comment #5)
> Well, can someone overwrite dllimport symbol by different definition?
> If not, it is a bug of decl_binds_to_current_def_p to return false here.
> If it can be inteprposed, I think the function
> symtab_node::noninterposable_alias should remove dllimport attribute on the
> alias created and so should symtab_node::make_decl_local

Thanks Honza,

well, dllimport symbol can be interposed ... well their function-stub can.  So
variant two seems to be the right thing to do.
I am about to prepare a patch for this ...

[Bug tree-optimization/65206] Vectorized version of loop is removed.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
 CC||jakub at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  CCing Jakub who implemented this stuff.

[Bug tree-optimization/65206] Vectorized version of loop is removed.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
We apply versioning for aliasing but compute it as always aliasing in some way,
thus the runtime check gets immediately folded and thus the vectorized loop
removed:

t.c:7:3: note: create runtime check for data references a1[i_16] and *_34
t.c:7:3: note: created 1 versioning for alias checks.
t.c:7:3: note: loop versioned for vectorization because of possible aliasing
...

but I see the alias runtime check nowhere.

The DRs are

(gdb) p debug_data_reference (dr_a.dr)
#(Data Ref: 
#  bb: 4 
#  stmt: _5 = a1[i_16];
#  ref: a1[i_16];
#  base_object: a1;
#  Access function 0: {0, +, 1}_1
#)
$17 = void
(gdb) p debug_data_reference (dr_b.dr)
#(Data Ref: 
#  bb: 4 
#  stmt: MASK_STORE (_34, 0B, _ifc__32, _9);
#  ref: *_34;
#  base_object: MEM[(float *)&a1];
#  Access function 0: {0B, +, 4}_1
#)

so maybe the code doing masked loads/stores updates the DRs in a way that
will later confuse runtime alias checking.  Or for some reason it doesn't
update it enough to make data-dependence analysis handle it.

Clearly this is a must-dependence (but with known distance), so sth
that data dependence analysis should handle and sth that the runtime
alias checking isn't handling.

[Bug tree-optimization/65206] Vectorized version of loop is removed.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I'm talking about

(compute_affine_dependence
  stmt_a: _5 = a1[i_16];
  stmt_b: MASK_STORE (_34, 0B, _ifc__32, _9);
) -> dependence analysis failed

somehow it works for

(compute_affine_dependence
  stmt_a: _8 = MASK_LOAD (_33, 0B, _ifc__32);
  stmt_b: MASK_STORE (_35, 0B, _ifc__36, _11);
(analyze_overlapping_iterations
  (chrec_a = {0B, +, 4}_1)
  (chrec_b = {0B, +, 4}_1)
  (overlap_iterations_a = [0])
  (overlap_iterations_b = [0]))
)

[Bug c++/65209] New: [5.0 regression] Broken code with global static variables, invalid pointer when freeing global variables

[manisandro at gmail dot com]

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

Bug ID: 65209
   Summary: [5.0 regression] Broken code with global static
variables, invalid pointer when freeing global
variables
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manisandro at gmail dot com

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

Using gcc-5.0.0-0.15.fc23.x86_64

Test case attached. Build with

$ g++ -g -Wall -o main foo.cpp main.cpp

The test case crashes when freeing global variables:

./main
*** Error in `/home/sandro/Desktop/a/main': free(): invalid pointer:
0x00610001 ***


#0  0x771a6ae8 in raise () from /lib64/libc.so.6
#1  0x771a877a in abort () from /lib64/libc.so.6
#2  0x771eb092 in __libc_message () from /lib64/libc.so.6
#3  0x771f2994 in _int_free () from /lib64/libc.so.6
#4  0x771f748c in free () from /lib64/libc.so.6
#5  0x0040099b in FooData::~FooData (this=0x602118
<_ZGVZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>,
__in_chrg=)
at foo.cpp:5
#6  0x004009da in Foo::~Foo (this=0x602100
<_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>,
__in_chrg=) at foo.cpp:8
#7  0x00400a12 in FooSingleton::~FooSingleton (this=0x602100
<_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>, 
__in_chrg=) at foo.cpp:15
#8  0x00400a69 in (anonymous
namespace)::Q_QGS_s_self::innerFunction()::Holder::~Holder() (
this=0x602100 <_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvE6holder>,
__in_chrg=) at foo.cpp:33
#9  0x771ab628 in __run_exit_handlers () from /lib64/libc.so.6
#10 0x771ab675 in exit () from /lib64/libc.so.6
#11 0x77191847 in __libc_start_main () from /lib64/libc.so.6
#12 0x004007e9 in _start ()


Observations:
- Depends on the Q_QGS_s_self namespace being called such (more precisely,
exactly such, not even any other name with equal length)
- Depends on the innerFunction method being called such
- Depends on innerFunction being inline
- Depends on the size of the global variables

[Bug tree-optimization/65206] Vectorized version of loop is removed.

[rguenth at gcc dot gnu.org]

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

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  ---
(In reply to Richard Biener from comment #4)
> I'm talking about
> 
> (compute_affine_dependence
>   stmt_a: _5 = a1[i_16];
>   stmt_b: MASK_STORE (_34, 0B, _ifc__32, _9);
> ) -> dependence analysis failed

Ah - this is pointer vs. array access, thus different "base".  A generic issue
that can for example be "solved" by trying to force a pointer base for
a non-pointer base DR when analysis fails and one is based on a pointer.

Hmm.

Mine.

> somehow it works for
> 
> (compute_affine_dependence
>   stmt_a: _8 = MASK_LOAD (_33, 0B, _ifc__32);
>   stmt_b: MASK_STORE (_35, 0B, _ifc__36, _11);
> (analyze_overlapping_iterations
>   (chrec_a = {0B, +, 4}_1)
>   (chrec_b = {0B, +, 4}_1)
>   (overlap_iterations_a = [0])
>   (overlap_iterations_b = [0]))
> )

[Bug sanitizer/64337] ThreadSanitizer: std::thread + lambda false positive

[guillaume.sabouret at starqube dot com]

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

guillaume.sabouret at starqube dot com changed:

   What|Removed |Added

 CC||guillaume.sabouret@starqube
   ||.com

--- Comment #3 from guillaume.sabouret at starqube dot com ---
At least in my case, the bug only happens when flag -g is set.

[Bug target/65167] ICE: in assign_by_spills, at lra-assigns.c:1383 (unable to find a register to spill) with -O -fschedule-insns -fcheck-pointer-bounds -mmpx

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Wed Feb 25 15:05:48 2015
New Revision: 220970

URL: https://gcc.gnu.org/viewcvs?rev=220970&root=gcc&view=rev
Log:
gcc/

PR target/65167
* gcc/config/i386/i386.c (ix86_function_arg_regno_p): Support
bounds registers.
(avoid_func_arg_motion): Add dependencies for BNDSTX insns.

gcc/testsuite/

PR target/65167
* gcc.target/i386/pr65167.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65167.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
  Known to work||4.9.2
   Target Milestone|--- |5.0
Summary|[5.0 regression] Broken |[5 Regression] Broken code
   |code with global static |with global static
   |variables, invalid pointer  |variables, invalid pointer
   |when freeing global |when freeing global
   |variables   |variables
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Valgrind says

==23580== Invalid free() / delete / delete[] / realloc()
==23580==at 0x4C28FAC: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23580==by 0x4009D4: FooData::~FooData() (foo.cpp:5)
==23580==by 0x400A13: Foo::~Foo() (foo.cpp:8)
==23580==by 0x400A4B: FooSingleton::~FooSingleton() (foo.cpp:15)
==23580==by 0x400AA2: (anonymous
namespace)::Q_QGS_s_self::innerFunction()::Holder::~Holder() (foo.cpp:33)
==23580==by 0x5704058: __run_exit_handlers (exit.c:82)
==23580==by 0x57040A4: exit (exit.c:104)
==23580==by 0x56EDBEB: (below main) (libc-start.c:303)
==23580==  Address 0x5a80001 is 24,513 bytes inside a block of size 72,704
alloc'd
==23580==at 0x4C277AB: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23580==by 0x4EC31AF: ??? (in /usr/lib64/libstdc++.so.6.0.21)
==23580==by 0x400E859: call_init.part.0 (dl-init.c:84)
==23580==by 0x400E942: _dl_init (dl-init.c:36)
==23580==by 0x40011C9: ??? (in /lib64/ld-2.18.so)

[Bug tree-optimization/65207] [5 regression] performance: tree level loop optimization does not peel SpecCPU href loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I believe there is a duplicate bug complaining about the same heuristic.  I can
confirm the heuristic is new.

Why doesn't the call overhead cancel all gains of the peeling?

[Bug c/65208] New: Floats sometimes rounded up instead of being truncated on mips

[wgh at beyondunreal dot com]

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

Bug ID: 65208
   Summary: Floats sometimes rounded up instead of being truncated
on mips
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wgh at beyondunreal dot com

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

It seems like typical cast from double to unsigned sometimes rounds the result
up.

On my router, the attached code, compiled with the following commandline

  mipsel-linux-uclibc-gcc -Wall -Wextra -O2 -static -std=c11 test.c

prints 

  0.7
  i=1
  i=0

The compiler generates no errors or warnings.

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/mipsel-linux-uclibc/gcc-bin/4.9.2/mipsel-linux-uclibc-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mipsel-linux-uclibc/4.9.2/lto-wrapper
Target: mipsel-linux-uclibc
Configured with:
/var/tmp/portage/cross-mipsel-linux-uclibc/gcc-4.9.2/work/gcc-4.9.2/configure
--host=x86_64-pc-linux-gnu --target=mipsel-linux-uclibc
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/mipsel-linux-uclibc/gcc-bin/4.9.2
--includedir=/usr/lib/gcc/mipsel-linux-uclibc/4.9.2/include
--datadir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2
--mandir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2/man
--infodir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2/info
--with-gxx-include-dir=/usr/lib/gcc/mipsel-linux-uclibc/4.9.2/include/g++-v4
--with-python-dir=/share/gcc-data/mipsel-linux-uclibc/4.9.2/python
--enable-languages=c --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.9.2 p1.1, pie-0.6.2'
--enable-poison-system-directories --disable-shared --disable-shared
--disable-libatomic --with-sysroot=/usr/mipsel-linux-uclibc --disable-bootstrap
--disable-__cxa_atexit --enable-tls --disable-multilib --disable-altivec
--disable-fixed-point --with-abi= --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto
--without-cloog --enable-libsanitizer
Thread model: posix
gcc version 4.9.2 (Gentoo 4.9.2 p1.1, pie-0.6.2)

[Bug sanitizer/65148] ICE: in get_biv_step, at loop-iv.c:823

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
It might be interesting which particular -fsanitize= options causes this. 
Maybe it reproduces only with -O -fsanitize=signed-integer-overflow?

[Bug target/65210] New: [avr] ICE: when using attributs 'address' and 'io_low'

[gjl at gcc dot gnu.org]

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

Bug ID: 65210
   Summary: [avr] ICE: when using attributs 'address' and 'io_low'
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
Target: avr

Compiled with

$ avr-gcc prog.c -S -Os -mmcu=atmega8

the following program ICEs:

volatile char q __attribute__((io_low,address(0x81)));


Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-5.0 --disable-shared --disable-nls
--with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld
--enable-languages=c,c++,lto --enable-checking=all
Thread model: single
gcc version 5.0.0 20150220 (experimental) (GCC) 
GNU C11 (GCC) version 5.0.0 20150220 (experimental) (avr)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2

ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/include"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/include-fixed"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/../../../../avr/include"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/include"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/include-fixed"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/local/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /mnt/nfs/home/georg/gnu/build/gcc-trunk-avr/gcc/include
 /mnt/nfs/home/georg/gnu/build/gcc-trunk-avr/gcc/include-fixed
End of search list.
GNU C11 (GCC) version 5.0.0 20150220 (experimental) (avr)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0
Compiler executable checksum: 63d1ce1dc9d02ab6b837fe423af8fe37
atiny.c:1:1: internal compiler error: in avr_eval_addr_attrib, at
config/avr/avr.c:9008
 volatile char q __attribute__((io_low,address(0x81)));
 ^
0x8ac4d2b avr_eval_addr_attrib(rtx_def*)
../../../gcc.gnu.org/trunk/gcc/config/avr/avr.c:9008
0x8ac627b avr_asm_output_aligned_decl_common(_IO_FILE*, tree_node*, char
const*, unsigned long long, unsigned int, bool)
../../../gcc.gnu.org/trunk/gcc/config/avr/avr.c:9302
0x8a8cc4e emit_common
../../../gcc.gnu.org/trunk/gcc/varasm.c:1979
0x8a9f86b assemble_noswitch_variable
../../../gcc.gnu.org/trunk/gcc/varasm.c:2034
0x8a9f86b assemble_variable(tree_node*, int, int, int)
../../../gcc.gnu.org/trunk/gcc/varasm.c:2233
0x8aa2564 varpool_node::assemble_decl()
../../../gcc.gnu.org/trunk/gcc/varpool.c:597
0x8aa333b symbol_table::output_variables()
../../../gcc.gnu.org/trunk/gcc/varpool.c:750
0x830dcdd symbol_table::compile()
../../../gcc.gnu.org/trunk/gcc/cgraphunit.c:2360
0x830f9fc symbol_table::finalize_compilation_unit()
../../../gcc.gnu.org/trunk/gcc/cgraphunit.c:2436
0x817d533 c_write_global_declarations()
../../../gcc.gnu.org/trunk/gcc/c/c-decl.c:10803

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  ---
Tested patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01502.html

[Bug sanitizer/65148] ICE: in get_biv_step, at loop-iv.c:823

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #3)
> It might be interesting which particular -fsanitize= options causes this. 
> Maybe it reproduces only with -O -fsanitize=signed-integer-overflow?

Yes, it does.
trippels@gcc2-power8 ~ % g++ -O -fsanitize=signed-integer-overflow -c foo.ii
foo.ii: In function ‘void fn1()’:
foo.ii:7:1: internal compiler error: in get_biv_step, at loop-iv.c:823

[Bug target/65210] [avr] ICE: when using attributs 'address' and 'io_low'

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-25
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug c++/65198] [5 Regression] User-defined literal template inside generic lambda segfaults GCC 5.0

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed by r220656.

This crashes for me with 4.9 though:
0xb7e61f crash_signal
/home/marek/src/gcc/gcc/toplev.c:337
0xdbb3e4 contains_struct_check
/home/marek/src/gcc/gcc/tree.h:3047
0xdbb3e4 int_cst_value(tree_node const*)
/home/marek/src/gcc/gcc/tree.c:10526
0x652434 get_non_default_template_args_count
/home/marek/src/gcc/gcc/cp/error.c:186
0x65b4d1 dump_template_argument_list
/home/marek/src/gcc/gcc/cp/error.c:195
0x654905 dump_decl
/home/marek/src/gcc/gcc/cp/error.c:1181
0x65b497 expr_to_string
/home/marek/src/gcc/gcc/cp/error.c:2847
0x6600f4 cp_printer
/home/marek/src/gcc/gcc/cp/error.c:3443
0x10d95e3 pp_format(pretty_printer*, text_info*)
/home/marek/src/gcc/gcc/pretty-print.c:616
0x10d701c diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marek/src/gcc/gcc/diagnostic.c:797
0x10d7d8f internal_error(char const*, ...)
/home/marek/src/gcc/gcc/diagnostic.c:1136
0x70aa6b cxx_eval_constant_expression
/home/marek/src/gcc/gcc/cp/semantics.c:9833
0x70dc25 cxx_eval_outermost_constant_expr
/home/marek/src/gcc/gcc/cp/semantics.c:9853
0x71091b maybe_constant_value(tree_node*)
/home/marek/src/gcc/gcc/cp/semantics.c:9963
0x5d11c1 build_non_dependent_expr(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:21564
0x6f9d22 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/marek/src/gcc/gcc/cp/semantics.c:2250
0x67a61d cp_parser_userdef_numeric_literal
/home/marek/src/gcc/gcc/cp/parser.c:3926
0x67a61d cp_parser_primary_expression
/home/marek/src/gcc/gcc/cp/parser.c:4163
0x67b766 cp_parser_postfix_expression
/home/marek/src/gcc/gcc/cp/parser.c:5971
0x67e057 cp_parser_unary_expression
/home/marek/src/gcc/gcc/cp/parser.c:7172
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jason at gcc dot gnu.org]

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

--- Comment #28 from Jason Merrill  ---
Author: jason
Date: Wed Feb 25 15:49:34 2015
New Revision: 220974

URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
Log:
PR debug/58315
* decl.c (start_preparsed_function): Use create_artificial_label
for cdtor_label.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/deleted-label1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/65211] New: Type alignment lost inside templated function

[linux at carewolf dot com]

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

Bug ID: 65211
   Summary: Type alignment lost inside templated function
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com

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

A specific combination of local typedef inside a templated function causes gcc
to lose or ignore the aligment of a vector.

[Bug c++/65211] Type alignment lost inside templated function

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 34872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34872&action=edit
Assembler intermediate

It is the "movdqa(%rdx), %xmm1" instruction on line 19 that is wrong.

[Bug c++/65211] Type alignment lost inside templated function

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
Created attachment 34873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34873&action=edit
Intermediate

[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables

[manisandro at gmail dot com]

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

--- Comment #2 from Sandro Mani  ---
Created attachment 34874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34874&action=edit
Slightly reduced test case

==30483== Invalid free() / delete / delete[] / realloc()
==30483==at 0x4C2D143: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30483==by 0x400983: Foo::~Foo() (foo.cpp:4)
==30483==by 0x40099F: (anonymous
namespace)::Q_QGS_s_self::innerFunction()::Holder::~Holder() (foo.cpp:21)
==30483==by 0x570F627: __run_exit_handlers (in /usr/lib64/libc-2.21.90.so)
==30483==by 0x570F674: exit (in /usr/lib64/libc-2.21.90.so)
==30483==by 0x56F5846: (below main) (in /usr/lib64/libc-2.21.90.so)
==30483==  Address 0x1 is not stack'd, malloc'd or (recently) free'd

[Bug c++/65211] Type alignment lost inside templated function

[linux at carewolf dot com]

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

Allan Jensen  changed:

   What|Removed |Added

  Attachment #34873|0   |1
is obsolete||

--- Comment #3 from Allan Jensen  ---
Created attachment 34875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34875&action=edit
Correct intermediate

[Bug tree-optimization/65204] Aligned address optimization not detected

[ktietz at gcc dot gnu.org]

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

--- Comment #2 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 16:28:28 2015
New Revision: 220981

URL: https://gcc.gnu.org/viewcvs?rev=220981&root=gcc&view=rev
Log:
Precommit code-change of patch by Richard Biener for gcc 6.0

2015-02-25  Richard Biener  

PR tree-optimization/65204
* tree-ssa-ccp.c (evaluate_stmt): Always evaluate address
takens for bit-CCP.


Modified:
branches/c++-delayed-folding/gcc/tree-ssa-ccp.c

[Bug c++/65211] Type alignment lost inside templated function

[linux at carewolf dot com]

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

--- Comment #4 from Allan Jensen  ---
Note either removing the template argument or moving the typedef out of the
function both solve the issue, and makes gcc use an unaligned load.

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #8 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 16:44:26 2015
New Revision: 220982

URL: https://gcc.gnu.org/viewcvs?rev=220982&root=gcc&view=rev
Log:
PR target/64212
* symtab.c (symtab::make_decl_local): Set DECL_IMPORT_P explicit to 0.
(symtab::noninterposable_alias): Likewise.


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

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 16:46:34 2015
New Revision: 220983

URL: https://gcc.gnu.org/viewcvs?rev=220983&root=gcc&view=rev
Log:
Merged from mainline
PR target/64212
* symtab.c (symtab::make_decl_local): Set DECL_IMPORT_P explicit to 0.
(symtab::noninterposable_alias): Likewise.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/symtab.c

[Bug target/65212] New: --with-arch=nocona and -msse3

[dilyan.palauzov at aegee dot org]

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

Bug ID: 65212
   Summary: --with-arch=nocona and -msse3
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org

At
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
is written:

‘nocona’
Improved version of Intel Pentium 4 CPU with 64-bit extensions, MMX, SSE,
SSE2 and SSE3 instruction set support. 

I ./configure gcc with --with-arch=nocona, and running afterwards

`gcc -Q --help=target` I get (among other things):
  -march=   nocona
  -mmmx [disabled]
  -msse [disabled]
  -msse2[disabled]
  -msse2avx [disabled]
  -msse3[disabled]

Provided that gcc is instructed to generate code for Intel Nocona, which has
SSE3, why is the -msse3 directive not enabled automatically?

I expect here to have SSE2 enabled automatically, as under this circumstances
(code for Nocona) I do not see a point to disable it.

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #10 from Kai Tietz  ---
Fixed.

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from H.J. Lu  ---
(In reply to Kai Tietz from comment #10)
> Fixed on trunk and 4.9

The fix caused:

FAIL: gcc.dg/pr56350.c (internal compiler error)
FAIL: gcc.dg/pr56350.c (test for excess errors)

[hjl@gnu-6 gcc]$ ./xgcc -B./ -O -ftree-vectorize
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/pr56350.c
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/pr56350.c: In
function ‘f’:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/pr56350.c:8:1:
internal compiler error: Segmentation fault
 f (void)
 ^
0xd1f836 crash_signal
/export/gnu/import/git/sources/gcc/gcc/toplev.c:383
0xfaf59a gimple_code
/export/gnu/import/git/sources/gcc/gcc/gimple.h:1553
0xfbd855 vectorizable_reduction(gimple_statement_base*,
gimple_stmt_iterator*, gimple_statement_base**, _slp_tree*)
/export/gnu/import/git/sources/gcc/gcc/tree-vect-loop.c:4987
0xfabc86 vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
/export/gnu/import/git/sources/gcc/gcc/tree-vect-stmts.c:7170
0xfb50c9 vect_analyze_loop_operations
/export/gnu/import/git/sources/gcc/gcc/tree-vect-loop.c:1539
0xfb58cc vect_analyze_loop_2
/export/gnu/import/git/sources/gcc/gcc/tree-vect-loop.c:1800
0xfb5c70 vect_analyze_loop(loop*)
/export/gnu/import/git/sources/gcc/gcc/tree-vect-loop.c:1898
0xfd558f vectorize_loops()
/export/gnu/import/git/sources/gcc/gcc/tree-vectorizer.c:451
0xed3699 execute
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-loop.c:295
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

on trunk.

[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r213307

[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #4 from Jakub Jelinek  ---
Exported symbols like
_ZZN12_GLOBAL__N_112Q_QGS_s_self13innerFunctionEvEN6HolderC1Ev
look very much wrong to me, anonymous namespace shouldn't be visible to other
TUs.  Similarly, sections containing such symbols shouldn't be linkonce.

[Bug c++/65198] [4.9 Regression] User-defined literal template inside generic lambda segfaults

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Known to work||5.0
   Target Milestone|5.0 |4.9.3
Summary|[5 Regression] User-defined |[4.9 Regression]
   |literal template inside |User-defined literal
   |generic lambda segfaults|template inside generic
   |GCC 5.0 |lambda segfaults
  Known to fail||4.9.2

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #12 from Kai Tietz  ---
Hmm, just retested it for gcc's trunk.  Can't reproduce it.  I will retest with
current trunk, I might have a different patch in tree, which makes the
difference here.
Additionally, what target you are using?

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Kai Tietz from comment #12)
> Hmm, just retested it for gcc's trunk.  Can't reproduce it.  I will retest
> with current trunk, I might have a different patch in tree, which makes the
> difference here.
> Additionally, what target you are using?

Also happened on 4.9 branch:

[hjl@gnu-6 gcc]$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/sources/gcc/configure
--enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-5.0.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse
Thread model: posix
gcc version 5.0.0 20150225 (experimental) (GCC) 
[hjl@gnu-6 gcc]$

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #14 from Kai Tietz  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Kai Tietz from comment #12)
> > Hmm, just retested it for gcc's trunk.  Can't reproduce it.  I will retest
> > with current trunk, I might have a different patch in tree, which makes the
> > difference here.
> > Additionally, what target you are using?
> 
> Also happened on 4.9 branch:

So for me it doesn't happen on trunk, so the "Also" seems to me something
special for you.  I will recheck 4.9, as here we might have a regression I
didn't caught ...

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Kai Tietz from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Kai Tietz from comment #12)
> > > Hmm, just retested it for gcc's trunk.  Can't reproduce it.  I will retest
> > > with current trunk, I might have a different patch in tree, which makes 
> > > the
> > > difference here.
> > > Additionally, what target you are using?
> > 
> > Also happened on 4.9 branch:
> 
> So for me it doesn't happen on trunk, so the "Also" seems to me something
> special for you.  I will recheck 4.9, as here we might have a regression I
> didn't caught ...

I don't know why you didn't see it:

Starting program: /export/build/gnu/gcc-4.9/build-x86_64-linux/gcc/cc1
-fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64
-auxbase x -O -version -ftree-vectorize -o x.i
GNU C (GCC) version 4.9.3 20150225 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.3 20150225 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e64a271cb64a39ff067a5fd30c57a8d9

Program received signal SIGSEGV, Segmentation fault.
0x00c1efa1 in gimple_code (g=0x0)
at /export/gnu/import/git/gcc-release/gcc/gimple.h:1406
1406  return g->code;
(gdb) bt
#0  0x00c1efa1 in gimple_code (g=0x0)
at /export/gnu/import/git/gcc-release/gcc/gimple.h:1406
#1  0x00c2bc5d in vectorizable_reduction (
stmt=, gsi=0x0, vec_stmt=0x0, slp_node=0x0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-loop.c:4915
#2  0x00c1bcca in vect_analyze_stmt (
stmt=, need_to_vectorize=0x7fffd6af, 
node=0x0) at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7107
#3  0x00c1b723 in vect_analyze_stmt (
stmt=, need_to_vectorize=0x7fffd6af, 
node=0x0) at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7023
#4  0x00c24048 in vect_analyze_loop_operations (loop_vinfo=0x1a75950, 
slp=false) at /export/gnu/import/git/gcc-release/gcc/tree-vect-loop.c:1505
#5  0x00c247ee in vect_analyze_loop_2 (loop_vinfo=0x1a75950)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-loop.c:1766
#6  0x00c24b73 in vect_analyze_loop (loop=0x719d50a0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-loop.c:1864
#7  0x00c41516 in vectorize_loops ()
at /export/gnu/import/git/gcc-release/gcc/tree-vectorizer.c:430
#8  0x00b713d3 in tree_loop_vectorize ()
at /export/gnu/import/git/gcc-release/gcc/tree-ssa-loop.c:154
#9  0x00b7145d in (anonymous namespace)::pass_vectorize::execute (
this=0x1a20150)
---Type  to continue, or q  to quit---
at /export/gnu/import/git/gcc-release/gcc/tree-ssa-loop.c:189
#10 0x0095dde6 in execute_one_pass (
pass=)
at /export/gnu/import/git/gcc-release/gcc/passes.c:2233
#11 0x0095dfff in execute_pass_list (
pass=)
at /export/gnu/import/git/gcc-release/gcc/passes.c:2286
#12 0x0095e030 in execute_pass_list (
pass=)
at /export/gnu/import/git/gcc-release/gcc/passes.c:2287
#13 0x0095e030 in execute_pass_list (
pass=)
at /export/gnu/import/git/gcc-release/gcc/passes.c:2287
#14 0x006bb569 in expand_function (
node=)
at /export/gnu/import/git/gcc-release/gcc/cgraphunit.c:1774
#15 0x006bb9ca in expand_all_functions ()
at /export/gnu/import/git/gcc-release/gcc/cgraphunit.c:1908
#16 0x006bc2ed in compile ()
at /export/gnu/import/git/gcc-release/gcc/cgraphunit.c:2252
#17 0x006bc3c8 in finalize_compilation_unit ()
at /export/gnu/import/git/gcc-release/gcc/cgraphunit.c:2329
#18 0x005817c7 in c_write_global_declarations ()
---Type  to continue, or q  to quit---q
 at /export/gnu/import/gQuit
(gdb) f 2
#2  0x00c1bcca in vect_analyze_stmt (
stmt=, need_to_vectorize=0x7fffd6af, 
node=0x0) at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7107
7107|| vectorizable_reduction (stmt, NULL, NULL, NULL)
(gdb) call debug_gimple_stmt (stmt)
patt_25 = a_lsm.8_11 < 0 ? 7 : 0;
(gdb) f 1
#1  0x00c2bc5d in vectorizable_reduction (
stmt=, gsi=0x0, vec_stmt=0x0, slp_node=0x0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-loop.c:4915
4915  if (gimple_code (reduc_def_stmt) != GIMPLE_PHI)
(gdb) p reduc_def_stmt
$2 = 
(gdb)

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
I certainly can reproduce it, the problem is that reduc_def_stmt is NULL.
dt is vect_constant_def.

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #17 from Kai Tietz  ---
Just posted a fix.  For the 4.9 branch I could finally reproduce this error. 
It is caused by the PHI-check for a vector-constant, which obviously has no
valid statment ...

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #19 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 18:21:37 2015
New Revision: 220987

URL: https://gcc.gnu.org/viewcvs?rev=220987&root=gcc&view=rev
Log:
PR tree-optimization/61917
* tree-vect-loop.c (vectorizable_reduction): Handle obvious case
that reduc_def_stmt is null.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #18 from Kai Tietz  ---
Author: ktietz
Date: Wed Feb 25 18:20:34 2015
New Revision: 220986

URL: https://gcc.gnu.org/viewcvs?rev=220986&root=gcc&view=rev
Log:
2015-02-25  Kai Tietz  

PR tree-optimization/61917
* tree-vect-loop.c (vectorizable_reduction): Handle obvious case
that reduc_def_stmt is null.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-loop.c

[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913

[ktietz at gcc dot gnu.org]

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

--- Comment #20 from Kai Tietz  ---
HJ: Does recent patch fixes issue for you too?

[Bug sanitizer/65148] ICE: in get_biv_step, at loop-iv.c:823

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Fixed on trunk by r217758.

[Bug c/65213] New: Extend -Wmissing-declarations to variables

[eugene.zelenko at gmail dot com]

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

Bug ID: 65213
   Summary: Extend -Wmissing-declarations to variables
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com

Will be good idea to -Wmissing-declarations to variables. Global variable
should have extern declaration in header file, otherwise variable should be
static.

Clang detect such situations with -Wmissing-variable-declarations.

Same should be done for C++.

[Bug target/65171] [5 Regression] r214254 causes thousands of std::length_errors running boost testsuite on ppc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Problem is an invalid swap removal in:

bool boost::test_tools::tt_detail::report_assertion(const
boost::test_tools::as\
sertion_result&, const boost::unit_test::lazy_ostream&,
boost::unit_test::const\
_string, std::size_t, boost::test_tools::tt_detail::tool_level,
boost::test_too\
ls::tt_detail::check_type, std::size_t, ...)

Something going on with subreg handling.

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Ping.  Precompiled source to reproduce the problem is still missing here.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
The regression was introduced in this commit:

commit 9eec20bfd5806dd0380e07dbc0f03409ce3d4efb
Author: rguenth 
Date:   Tue Mar 26 09:14:59 2013 +

2013-03-26  Richard Biener  

* emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
alignment computations and rely on get_object_alignment_1
for the !TYPE_P case.
Commonize DECL/COMPONENT_REF handling in the ARRAY_REF path.


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

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #4)
> Ping.  Precompiled source to reproduce the problem is still missing here.

I will try to provide it in the following days. For both imagemagick and
graphicsmagick, there was no intermediate source file dumped into /tmp so I
have to start a manual build.

Thanks for the heads up, I will get the required files.

Adrian

[Bug target/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[uros at gcc dot gnu.org]

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

--- Comment #25 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 25 19:59:31 2015
New Revision: 220990

URL: https://gcc.gnu.org/viewcvs?rev=220990&root=gcc&view=rev
Log:
Revert:
2014-07-26  Uros Bizjak  

PR target/47230
* configure.ac (alpha*-*-linux*): Use mh-alpha-linux.
* configure: Regenerate.

/config

Revert:
2014-07-26  Uros Bizjak  

PR target/47230
* mh-alpha-linux: New file.

/gcc

PR target/47230
* doc/install.texi (Specific, alpha*-*-*): Document that binutils 2.25
or newer are required.


Removed:
trunk/config/mh-alpha-linux
Modified:
trunk/ChangeLog
trunk/config/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug target/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[ubizjak at gmail dot com]

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

--- Comment #26 from Uroš Bizjak  ---
(In reply to uros from comment #25)

The linker bug [1] was fixed in binutils 2.25 and GCC workaround was removed
for gcc 5.0.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=5276

[Bug libfortran/65203] Document fall-back to read-only access

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
This is the same issue as in PR65200.  One suggests documentation and some code
changes.  Making this as duplicate and will add documentation to the other.

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

[Bug libfortran/65200] Handle EPERM when opening files

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
>From PR65203 Thomas comment:

Currently, when encountering EACCES or EROFS upon opening, we fall back towards
opening the file read-only.

This is

a) not documented
b) surprising for some users (an inconsistency has been commented upon)
c) causes inconsistencies with NFS v4, which appears to return EPERM for a
read-only file for no reason that I can see.

The original report can be found at
http://stackoverflow.com/questions/28696539/fortran-open-call-differs-on-nfsv3-vs-nfsv4
.

My suggestion would be to a) document and c) extend the behavior to EPERM.