[Bug tree-optimization/68523] CFG Expansion Computes Incorrect Block Frequencies for Nested Loops

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 CC||segher at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  The loops start out just fine, but tree-ssa-loop-ch
messes it up.

[Bug tree-optimization/68526] New: [6 Regression] gcc.target/powerpc/recip-4.c fails starting with r230492

[pthaugen at gcc dot gnu.org]

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

Bug ID: 68526
   Summary: [6 Regression] gcc.target/powerpc/recip-4.c fails
starting with r230492
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

Subject testcase starts failing with stated revision, is now generating
separate sqrt/recip instructions instead of combined insn (along with ancillary
insns which also fail to match).

Before:
xvrsqrtedp 0,12


After:
xvsqrtdp 12,0
xvredp 0,12

[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2012-12-09 00:00:00 |2015-11-24
 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
A similar test case not involving arrays:

$ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-Wextra -o/dev/null -xc++ z.c
typedef struct A {
int i;
struct { int a, b; } s;
} A;

A a = { 1, .s = { 2, 3 } };
A b = { .i = 1, .s = { 2, 3 } };
A c = { .s = { 2, 3 }, .i = 1 };
z.c:8:31: sorry, unimplemented: non-trivial designated initializers not
supported
 A c = { .s = { 2, 3 }, .i = 1 };
   ^

z.c:8:31: sorry, unimplemented: non-trivial designated initializers not
supported

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[tromey at gcc dot gnu.org]

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

--- Comment #10 from Tom Tromey  ---
(In reply to Josh Triplett from comment #9)

> > It might help to see exactly where __context__ is used in real code.
> 
> A few patterns:

Sorry, I wasn't very clear.
It seems to me that __context__ must be used as a kind of annotation
alongside some effect-ful statement.  I'm curious what those statements
are; and whether we could somehow annotate them directly.
(I presume not since sparse didn't go that route, but I figured I'd ask.)

> Sparse requires exactly the same, but even that level of difficulty means a
> tiny fraction of people building kernels actually use it.  Integrating it
> with GCC means it could work automatically for everyone.

Yeah, makes sense.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Nenad Vukicevic from comment #9)
> On 11/24/15 12:07 PM, iains at gcc dot gnu.org wrote:
> 
> > So I agree, the root problem is that we are creating something that the 
> > newer
> > version of dsymutil doesn't understand - it could be we're making a mistake 
> > or
> > new dsymutil could be still green.
> 
> I tried to run Clang's llvm-dsymutil form the locally built clang tools.
>  Fails the same way.  And the error is coming from this routine:
> 
> 124 /// Interpret the STAB entries to fill the DebugMap.
> 125 void MachODebugMapParser::handleStabSymbolTableEntry(uint32_t
> 
> 
> > What happens if you do a clang link and then do "dsymutil result"?
> 
> Linking with clang and "dsymutil result" produces similar results -
> 'failed to insert symbol' messages.  But then it complains on lots of
> object files as it cannot find them.
> 
> I checked the clang code (and some logs) and clang does NOT call
> dsymutil for our case.
> 
> Note that we are compiling through a fairly complex UPC driver, part of
> Berkeley UPC toolset, and we get this warnings only if our back-end
> compiler is GCC from our GNU UPC branch (which is in sync with the
> trunk).  Using Clang as back-end compiler does not produce warning as
> they do not run the tool at the and - linking phase.

OK so it appears that we do have two issues;

1. that we're (incorrectly) calling dsymutil for "link only" cases where
there's no LTO involved (and that seems to be a typo in the argument to
post_ld_pass() on line 820).  We located the PR that gave rise to the change
(61352) and will just double-check that we do not regress that with the change.
 Could you make the change locally and see if it makes the problem "go away"?
(I note that it doesn't in any way fix #2).

2. Some as yet unexplained issue with new dsymutil
it's probable that if you can do something like:

clang a.o b.o  z.o -g -o t 
dsymutil t
and get errors - then the right thing is to file a radar (since that's really
only using ld64 and dsymutil - which are both outside the GCC source base).

It's possible that there's some fault  with symbols in the object files that
doesn't somehow affect linking and doesn't trip up nm .. but adversely affects
dsymutil - not sure I can exactly envision that right now.

[Bug c++/68525] New: bogus use of deleted function error on a template with a flexible array member

[msebor at gcc dot gnu.org]

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

Bug ID: 68525
   Summary: bogus use of deleted function error on a template with
a flexible array member
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Recent trunk gets confused by the program below into issuing a rather
mysterious error.  Both Clang and Gcc 5.1 compile the code without an error.

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -O2  -S -o/dev/tty -xc++ z.cpp
template 
struct A {
int n;
T a[];
};

struct B { B (int); };

A ab;
.file   "z.cpp"
z.cpp:4:9: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 T a[];
 ^

z.cpp:9:6: error: use of deleted function ‘A::A()’
 A ab;
  ^~

z.cpp:2:8: note: ‘A::A()’ is implicitly deleted because the default
definition would be ill-formed:
 struct A {
^

z.cpp:2:8: error: no matching function for call to ‘B::B()’
z.cpp:7:12: note: candidate: B::B(int)
 struct B { B (int); };
^

z.cpp:7:12: note:   candidate expects 1 argument, 0 provided
z.cpp:7:8: note: candidate: constexpr B::B(const B&)
 struct B { B (int); };
^

z.cpp:7:8: note:   candidate expects 1 argument, 0 provided
z.cpp:7:8: note: candidate: constexpr B::B(B&&)
z.cpp:7:8: note:   candidate expects 1 argument, 0 provided

[Bug c++/68449] ICE in cxx_eval_constant_expression on atomic_load in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Martin Sebor  ---
GCC 5.1 also crashes so this is not a regression.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #30 from Jerry DeLisle  ---
(In reply to Joost VandeVondele from comment #29)

> These slides show how to reach 90% of peak:
> http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/
> the code actually is not too ugly, and I think there is no need for the
> explicit vector intrinsics with gcc.

The 90% of peak is achieved using SSE registers.  I went ahead and built the
example and on my laptop (the slow machine) I get about 4.8 gflops with a
single core.  So we could use this example and back-off from the SSE
optimizations to get an internal MATMUL that is not architecture dependent and
perhaps leave the rest to external optimized BLAS.

[Bug target/68456] UINT32_TYPE has different type for i586-elf and for i586-unknown-linux

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
On Tue, 24 Nov 2015, vaalfreja at gmail dot com wrote:

> And why newlib-stdint header is used in this case? I haven't used any
> newlib-related options in configure. These targets still have different types
> for UINT32_TYPE.

Bare-metal targets such as i586-elf are presumed to use newlib.  If you 
require something incompatible with newlib's choice of types, you'll need 
a separate GCC configuration using a different choice of these types (or 
replace GCC's  wrapper, though that won't affect built-in uses 
of the types).

[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.

[jvg1981 at aim dot com]

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

--- Comment #11 from Joshua Green  ---
(In reply to Segher Boessenkool from comment #10)
> GCC thinks bar2 will be executed more often that bar1; the code
> it generates is perfectly fine for that.
> 
> If you think GCC's heuristics for branch prediction are no good,
> could use some improvement, you'll have to come up with more
> evidence than just a single artificial testcase.  Sorry.  These
> things were tuned on real code.

If gcc's heuristic is indeed optimal when tested over a reasonable sample of
real code, then I withdraw my objection.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[pageexec at gmail dot com]

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

--- Comment #12 from PaX Team  ---
1. there's a (linux) kernel-hardening effort of late that among others will try
to upstream the PaX gcc plugin infrastructure along with some plugins, so the
checker one could be added to that list (but it wasn't part of the initial
plan). you should probably continue this thread on that list instead as i doubt
many kernel devs follow the gcc bugzilla ;).

2. as for my idea, it's simple: track the context via an artificially injected
local integer variable (one per context if you want context sensitivity) and
initialize it to the 'in' attr parameter or 0 otherwise then adjust its value
on function calls that affect it based on the callee's context attribute. at
the end compare the variable against the 'out' attr parameter (or 0) and
complain on a mismatch (in my proof-of-concept i just called builtin_trap on a
mismatch). now where gcc comes in is that it'll do constant propagation, DCE,
etc for free so the final check either gets removed by dead code elimination
(the locking is correct) or we detected a locking problem and can even
determine the bad path(s). using this simple method on Josh's test file
there're no false positives or false negatives. i'll work it into something
usable (actual reports instead of having to check for leftover builtin_traps)
and release it in PaX then linux can pick it up when the time comes.

[Bug tree-optimization/68528] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 68528
   Summary: Wrong constant folding
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC-6.0 for x86_64 miscompiles the following code.

$ cat test.c
#define INT_MIN ( -2147483647 - 1 )

int main (void)
{
int  x0 = INT_MIN;
long x1 = 0L;
int  x2 = 0;
int  t  = ( 0 || ( INT_MIN - (int) ( x0 - x1 ) ) );

if ( t != 0 ) { x2 = t; __builtin_abort(); }

return 0;
}

$ gcc-6.0 test.c -O2

$ ./a.out
zsh: abort  ./a.out

$ gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=/home/ishiuraken/opt/gcc-6.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/ishiuraken/opt/gcc-6.0
--program-suffix=-6.0 --enable-laungages=c --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20151112 (experimental) (GCC)

[Bug tree-optimization/68529] New: scev failed for while(i--)

[majun4950646 at 163 dot com]

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

Bug ID: 68529
   Summary: scev failed for while(i--)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: majun4950646 at 163 dot com
  Target Milestone: ---

loop distribution failed to generate memset library call for the following
example:

#include 
#include 

int main(){
char c[1]={};

unsigned int nchar=;

while(nchar--!=0)
  {   
   c[nchar]='A';
  }   

printf("%s\n",c);
return 0;
}


Compiled with 
gcc -O3 -march=core2  -fdump-tree-ldist-details  t.c -o t

From the ldist dump:

...
Creating dr for c[nchar_24]
analyze_innermost: failed: evolution of offset is not affine.
base_address: 
offset from base address: 
constant offset from base address: 
step: 
aligned to: 
base_object: c
Access function 0: {9998, +, 4294967295}_1
...

and it failed to transform the while loop to memset

=
However, it successed by change while(nchar--!=0) to  for(;nchar !=0;nchar--):

#include 
#include 

int main(){
char c[1]={};

unsigned int nchar=;

for(;nchar!=0;nchar--)
  {   
   c[nchar]='A';
  }   

printf("%s\n",c);
return 0;
}

...

Creating dr for c[nchar_21]
analyze_innermost: success.
base_address: 
offset from base address: 0
constant offset from base address: 
step: -1
aligned to: 128 
base_object: c
Access function 0: {, +, 4294967295}_1
...
and generate memset library call stmt:
 __builtin_memset ([(void *) + 1B], 65, );

I also testd in gcc4.8.4 and trunk, both failed.

--Jun

[Bug debug/67106] [6 Regression] ICE: verify_type failed: type variant differs by TYPE_PACKED. with -g -fpack-struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (version 6.0.0 20151125).

[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed with today's trunk (6.0.0 20151125).

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-25
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I can't reproduce this error with today's trunk (6.0.0 20151125) on x86_64.  I
see a similar stack trace in bug 60598 but that was fixed over a year ago.  Can
you confirm that trunk compiles the test case as expected in your environment?

[Bug tree-optimization/66131] [6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
I also cannot reproduce the failure with today's trunk (6.0.0 20151125).
Resolving as fixed.

[Bug c++/68387] [c++1z] gcc hangs forever on this code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed with today's trunk.

[Bug libstdc++/68450] regex matching different from ECMAScript?

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-25
 Ever confirmed|0   |1

--- Comment #1 from Tim Shen  ---
I think I unintentionally fixed this problem in my refactoring branch:
https://github.com/innocentim/gcc/commits/master

I ran this branch and get the result:
"Field": "Value"  
"Field": "Value"  

Each line has two trailing spaces, which is the same as my boost output.

I'm not sure when this branch may get reviewed checked in (it involves a lot of
changes), but I personally hope it's before the next big release.

Alternatively I can find the commit that fixes this issue, cherry pick it to
the trunk, and rebase my branch; but I know that rebasing is gonna be super
painful, so I'd rather wait for a while.

[Bug target/68454] internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

--- Comment #9 from M Joshua Ryan  ---
Investigated the offending source line a little deeper. It now looks to me like
it has to do with mixed floating/integer arithmetic, especially with bizarre
types like `time_t`. Changing the source to use all integer arithmetic allows
the compiler to complete.

gettimeofday(, NULL);
_xpost_start_time = (((long)tv.tv_sec) * 1000) + ((long)tv.tv_usec / 1000);

[Bug target/68454] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
This sounds related to GMP/MPFR, can you recompile those?

[Bug c++/68530] New: [C++14] sorry, unimplemented: unexpected AST of kind loop_expr

[lucdanton at free dot fr]

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

Bug ID: 68530
   Summary: [C++14] sorry, unimplemented: unexpected AST of kind
loop_expr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

Possibly related to PR c++/68206, which could also be exhibiting both this and
a potentially unrelated ICE.

$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151125 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.cpp  
struct thing {
void foo() {}
};

template
constexpr int count()
{
auto item = thing {};
for(; (item.foo(), false););
return 0;
}

int main()
{
static_assert( count() == 0, "" );
}
$ g++-trunk -std=c++14 main.cpp
main.cpp: In function 'int main()':
main.cpp:15:5: error: non-constant condition for static assertion
 static_assert( count() == 0, "" );
 ^

main.cpp:15:30: error: 'constexpr int count() [with  =
int]' called in a constant expression
 static_assert( count() == 0, "" );
  ^

main.cpp:6:15: note: 'constexpr int count() [with  =
int]' is not usable as a constexpr function because:
 constexpr int count()
   ^

main.cpp:6:15: sorry, unimplemented: unexpected AST of kind loop_expr
main.cpp:6: confused by earlier errors, bailing out

[Bug tree-optimization/67755] [5 Regression] Bad edge probability/block freqency for tree jump threading

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
It is caused by r215739, "Redesign jump threading profile updates
to avoid introducing insanities".

[Bug libstdc++/68450] regex matching different from ECMAScript?

[lcoquelle at gmail dot com]

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

--- Comment #2 from Ludo  ---
(In reply to Tim Shen from comment #1)
> I think I unintentionally fixed this problem in my refactoring branch:
> https://github.com/innocentim/gcc/commits/master
> 
> I ran this branch and get the result:
> "Field": "Value"  
> "Field": "Value"  
> 
> Each line has two trailing spaces, which is the same as my boost output.
> 
> I'm not sure when this branch may get reviewed checked in (it involves a lot
> of changes), but I personally hope it's before the next big release.
> 
> Alternatively I can find the commit that fixes this issue, cherry pick it to
> the trunk, and rebase my branch; but I know that rebasing is gonna be super
> painful, so I'd rather wait for a while.

Nice! thanks for looking at it!

[Bug c++/68531] New: incorrect code for VLA in C++

[msebor at gcc dot gnu.org]

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

Bug ID: 68531
   Summary: incorrect code for VLA in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ accepts variable length arrays as an extension but generates the wrong code
for some basic uses cases of such arrays: it allows changes in the value of a
variable that determines the number of elements in a VLA type to affect the
bound of the VLA after it has been defined.

When compiled with gcc (in C mode), or by Clang in either C or C++ modes, the
following program compiles and runs successfully to completion.  However, when
compiled with g++, either today's trunk or as far back as 4.5.3 (the oldest I
tested), it aborts.

$ cat x.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -xc++ x.c && ./a.out
int main ()
{
int nelems = 7;

typedef char A [nelems];

nelems = 2;

A a;

if (sizeof (A) != 7 || sizeof a != 7) __builtin_abort ();
}

x.c: In function ‘int main()’:
x.c:5:27: warning: ISO C++ forbids variable length array ‘A’ [-Wvla]
 typedef char A [nelems];
   ^

Aborted (core dumped)

[Bug target/68454] internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

--- Comment #11 from M Joshua Ryan  ---
Created attachment 36831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36831=edit
additional source triggering same error

Having successfully compiled the other file, I have received the same error on
a different file. Again it appears to involve mixing floating-point types. 

  CC   src/lib/src_lib_libxpost_la-xpost_op_math.lo
src/lib/xpost_op_math.c: In function ‘Ratan’:
src/lib/xpost_op_math.c:341:5: internal compiler error: Segmentation fault
 real ang = atan2((num.real_.val * RAD_PER_DEG),
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

`real` is a typedef for float.

[Bug fortran/66465] Procedure pointer component & non-component interpreted as different type or kind

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Wed Nov 25 05:28:10 2015
New Revision: 230852

URL: https://gcc.gnu.org/viewcvs?rev=230852=gcc=rev
Log:
2015-11-25  Paul Thomas  

Backport from trunk.
PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-25  Paul Thomas  

Backport from trunk.
PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

Backport from trunk.
PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr66465.f90
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/check.c
branches/gcc-4_9-branch/gcc/fortran/class.c
branches/gcc-4_9-branch/gcc/fortran/trans-types.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Wed Nov 25 05:28:10 2015
New Revision: 230852

URL: https://gcc.gnu.org/viewcvs?rev=230852=gcc=rev
Log:
2015-11-25  Paul Thomas  

Backport from trunk.
PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-25  Paul Thomas  

Backport from trunk.
PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

Backport from trunk.
PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr66465.f90
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/check.c
branches/gcc-4_9-branch/gcc/fortran/class.c
branches/gcc-4_9-branch/gcc/fortran/trans-types.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/66465] Procedure pointer component & non-component interpreted as different type or kind

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on 4.9, 5 and 6 branches.

Thanks for the report

Paul

[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on 4.9, 5 and 6 branches.

Thanks for the report

Paul

[Bug target/68494] [ARM] Use vector multiply by lane

[michael.collison at linaro dot org]

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

--- Comment #2 from Michael Collison  ---
Sorry here is the updated test case.

#define NTAPS 4

short taps[NTAPS];

void fir_t5(int len, short * __restrict p, short *__restrict x, short
*__restrict taps)
{
  len = len & ~31;
  for (int i = 0; i < len; i++)
{
  int tmp = 0;
  for (int j = 0; j < NTAPS; j++)
{
  tmp += x[i - j] * taps[j];
}

  p[i] = tmp;
}
}



We currently generate a vdup of the scalar taps[j] in the inner loop. Ideally
we do not use the vdup and insted use a vmul using a lane.

[Bug inline-asm/61692] ICE in extract_insn in recog.c for asm with many parameters

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #3 from mrs at gcc dot gnu.org  ---
This test case isn't portable.  If upped to 40 then it would be more portable.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #8 from Josh Triplett  ---
(In reply to PaX Team from comment #5)
> (In reply to Josh Triplett from comment #4)
> > Could you represent __context__ as a new GCC builtin?  Would that make this
> > any easier?
> 
> it can be a builtin or just a regular function declaration, the latter is
> easy to create from a plugin too.

Except as Tom noted, GCC will throw away a regular function declaration early
on, whereas it can handle a builtin differently.

> > So, I suspect the unfortunate answer is that Linux would probably want to
> > ship the plugin as C/C++ and build it at build time if enabled.  (Or we 
> > could
> > integrate this functionality into GCC itself.)
> 
> since PaX already has a checker plugin i subscribed to this bug a while ago
> but completely forgot about it until now ;P. in any case, i've begun to work
> on this along a somewhat different angle: instead of adding completely new
> machinery to detect context imbalances i'd like to reuse existing gcc passes
> to compute this property, we'll see how it goes.

Interesting idea.  What'd you have in mind?

[Bug rtl-optimization/68520] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in quick_push, at vec.h:845

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed.  Thanks for the report!

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> Ok, I'll dig up the details later today.  It may well be related to a
> command line tools upgraded corresponding to Xcode 7.x.

Here's what I found: in stage2, linking gcj fails with

ld: in ../libiberty/libiberty.a(make-temp-file.o), in section __TEXT,__text
reloc 17: unsupported r_length=0 for scattered vanilla reloc for architecture
i386
collect2: error: ld returned 1 exit status
make[3]: *** [gcj] Error 1

ld is

@(#)PROGRAM:ld  PROJECT:ld64-253.6
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7k armv7m armv7em (tvOS)
LTO support using: Apple LLVM 7.0.0 (clang-700.1.76)

on

Darwin llaima.fritz.box 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13
19:43:59 PST 2015; root:xnu-3248.20.55~1/RELEASE_X86_64 x86_64

otool -r shows

build/libiberty/make-temp-file.o:
Relocation information (__TEXT,__text) 54 entries
address  pcrel length extern typescattered symbolnum/value
[...]
0257 0 0  n/a0   1 0x03c0

which is (with -rv)

0257 False byte   n/aVANILLA True  0x03c0

No idea what ld is complaining about here, though.

Rainer

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Nenad Vukicevic from comment #6)
> On 11/24/15 9:27 AM, dominiq at lps dot ens.fr wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358

I suspect we have two issues here:

> Maybe line 820 should pass 'false' as this is the case similar to LTO
> not being enabled?

That seems reasonable a first blush, we should _not_ call dsymutil for

gcc foo.o bar.o -g -o t

And we plainly do..

The purpose of dsymutil on the link line is to preserve debug info from
temporary files.

so for:

gcc foo.c -g -o t

/tmp/blah-foo.o is created and used to link "t" 
... but t doesn't contain the debug info (only references to the .o files) and
the (/tmp) .o files will be deleted at the end of the link.  Step in dsymutil
which links the debug info into a t.dSYM .. and we're all happy.

Normally for
gcc foo.o bar.o -g -o t
there is no need for dsymutil because foo.o and bar.o (which contain the debug
data) will be available after the link.

In the case of an lto link:

gcc foo.o bar.o -flto -g -o t

now we have a situation where, if foo.o, bar.o (or both) contain lto data this
will be linked - and then the compiler will run generating a /tmp/lto-blah.o
based on the lto'd input.  This temp file will be deleted one the final link is
done - and we'd be back to losing debug info.

So we have it run dsymutil if we're doing lto, and a temporary file is created.

We seem to have the logic wrong / insufficient so that it is getting run when
there is no (apparent) need.




I's not immediately obvious that clang is DTRT if it doesn't run dsymutil for
the same scenario (but let's leave that to one side for now).



> I think the problem is in the symbols we generate, or the tool itself,
> and this issue shows up only if you have LTO enabled.  I can provide the
> object file that has problems and this might be enough if someone builds
> LLVM on Apple and tries llvm-dsymutil tool on it.  This should be the
> same tool as Apple's dsymutil, if we can duplicate the problem then we
> can debug it.

So I agree, the root problem is that we are creating something that the newer
version of dsymutil doesn't understand - it could be we're making a mistake or
new dsymutil could be still green.

I've got a TOT clang build and will investigate a bit.

What happens if you do a clang link and then do "dsymutil result"?

[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Tue Nov 24 20:40:10 2015
New Revision: 230839

URL: https://gcc.gnu.org/viewcvs?rev=230839=gcc=rev
Log:
2015-11-24  Paul Thomas  

Backport from trunk.
PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-24  Paul Thomas  

Backport from trunk.
PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

Backport from trunk.
PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr66465.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/check.c
branches/gcc-5-branch/gcc/fortran/class.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Not sure how the gcc/testsuite got on the end.  Oh well, the
> testcase won't hurt anything.

[Book15] f90/bug% gfca /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr68227.f90
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr68227.f90:21:0:

forall (i=1:n) y(i)%a = x


internal compiler error: in gfc_do_allocate, at fortran/trans-stmt.c:3130

without your fix for pr68227.

[Bug rtl-optimization/68523] New: CFG Expansion Computes Incorrect Block Frequencies for Nested Loops

[kelvin at gcc dot gnu.org]

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

Bug ID: 68523
   Summary: CFG Expansion Computes Incorrect Block Frequencies for
Nested Loops
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

With a debug version of gcc, compile the following program with the
command-line options:
-S -O3 -fno-tree-vectorize -da

void foo(double *d, unsigned long int n) {
  unsigned long int i, j;

  for (j = 0; j < 1002; j++) {
for (i=0;i B2(100%)
B2:9 -> B4(100%)
B4:9 -> B7(100%)
B7:900 -> B5(100%)
B5:9100 -> B5(91%); B6(9%)
B6:900 -> B7(99%); B9(1%)
B9:9 -> EXIT(100%)
EXIT:9

There are several inconsistencies in the reported frequencies.

Note that the predecessors of B5 have combined frequency 900 + 91% of 9100 =
900 + 8281 = 9181 which does not equal the frequency of B5 (9100).

Also, note that predecessors of B6 have combined frequency 9% of 9100 = 819,
which does not equal 900, the frequency of B6.

To correct the error, block B5 should have frequency 10,000.  The value 10,000
can be computed by dividing 900, the combined frequency of edges entering this
run-time bounded loop, by 0.09.  Dividing by this magic number 0.09 corresponds
to the heuristic that each conditional exit from a loop whose iteration bounds
are determined at run-time has probability 9% of exiting the loop and 91% of
remaining inside the loop.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #9 from Josh Triplett  ---
(In reply to Tom Tromey from comment #6)
> (In reply to Josh Triplett from comment #4)
> > Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug
> > already exist for that somewhere?), but not something that should block
> > *this*
> > feature.
> 
> Offhand I don't know if there is a bug covering this.

Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 .

> > Sparse actually tracks context as a property of basic blocks.
> 
> I was thinking this might be doable but I don't really know how
> gcc handles basic block coalescing -- if two blocks are merged
> we'd want to ensure that the resulting block ends up with the
> correct context property.

Right; this would need specific handling when manipulating basic blocks.

> It might help to see exactly where __context__ is used in real code.

A few patterns:

First, you can use __context__(some_lock, 1, 1) to assert that you hold
some_lock.

Second, you can use __context__(some_lock, 0, 1) to note that you have acquired
some_lock; that may make sense within the definition of a lock acquisition
function, since the function's declaration will have a context attribute saying
it returns with the lock held, and the body needs to match that.  It also makes
sense in the body of a lock acquisition macro.

Third, ditto for __context__(some_lock, 1, 0) and lock release functions.

And fourth, see the definition of __cond_lock:

# define __acquire(x) __context__(x,1)
# define __release(x) __context__(x,-1)
# define __cond_lock(x,c) ((c) ? ({ __acquire(x); 1; }) : 0)

You can then define a wrapper for a trylock function:

#define trylock(l) __cond_lock(l, trylock(l))

If you then use this in an if, the compiler can know that one path has a
different context than the other:

/* l has context 0 */
if (trylock(l)) {
/* l has context 1 */
} else {
/* l still has context 0 */
}

> > (if
> > they ship it at all; AFAICT Debian only ships gcc-python3-plugin).
> 
> The version of python doesn't matter much.
> 
> For people whose distro doesn't package gcc-python-plugin, it is simple
> to build; just git clone + make.

Sparse requires exactly the same, but even that level of difficulty means a
tiny fraction of people building kernels actually use it.  Integrating it with
GCC means it could work automatically for everyone.

[Bug rtl-optimization/68520] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in quick_push, at vec.h:845

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Tue Nov 24 21:23:25 2015
New Revision: 230843

URL: https://gcc.gnu.org/viewcvs?rev=230843=gcc=rev
Log:
shrink-wrap: Fix thinko (PR68520)

Part of the shrink-wrapping algorithm has this comment:

  /* Now see if we can put the prologue at the start of PRO.  Putting it
 there might require duplicating a block that cannot be duplicated,
 or in some cases we cannot insert the prologue there at all.  If PRO
 wont't do, try again with the immediate dominator of PRO, and so on.

 The blocks that need duplicating are those reachable from PRO but
 not dominated by it.  We keep in BB_WITH a bitmap of the blocks
 reachable from PRO that we already found, and in VEC a stack of
 those we still need to consider (to find successors).  */

Two of the cases that push to that stack do not actually check the
bitmap first.  Either I thought those blocks could not be on the stack
already, or more likely I didn't think and it just didn't crash during
any testing.  But of course those blocks *can* already be on the stack
(if you have a hideous loop structure), and then we end up with the
same block on the stack more than once.  This is harmless, except that
(like in the PR) this can overflow the stack.

This fixes it, by doing the necessary bitmap checks before pushing.


PR rtl-optimization/68520
* shrink-wrap.c (try_shrink_wrapping): Don't push a block to VEC if
its bit was already set in BB_WITH.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/shrink-wrap.c

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  ---
On Tue, Nov 24, 2015 at 07:48:19PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68486
> 
> --- Comment #14 from Dominique d'Humieres  ---
> > Not sure how the gcc/testsuite got on the end.  Oh well, the
> > testcase won't hurt anything.
> 
> [Book15] f90/bug% gfca /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr68227.f90
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr68227.f90:21:0:
> 
> forall (i=1:n) y(i)%a = x
> 
> 
> internal compiler error: in gfc_do_allocate, at fortran/trans-stmt.c:3130
> 
> without your fix for pr68227.
> 

Of course.  As I stated, it won't hurt anything.
FAILs in the testsuite are not a problem.  The
issue with EXPR_FUNCTION and cshift is a problem.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #4 from Josh Triplett  ---
(In reply to Tom Tromey from comment #3)
> (In reply to Josh Triplett from comment #2)
> 
> > > The attribute syntax in the test case doesn't work with gcc.  The 
> > > attributes
> > > on the function definitions can't appear at the end.
> > 
> > Placing attributes at the end of the function definition works with Sparse,
> > and as far as I can tell with GCC as well.  The Linux kernel uses trailing
> > attributes on functions (both prototypes and definitions) fairly frequently,
> > including with the context attribute.
> 
> Experimentally it works with function declarations but not function
> definitions.
> There was some reason for this (ambiguity with K style?), but I forget
> exactly.
> 
> void declaration(void) __attribute__((const));
> 
> void definition(void) __attribute__((const))
> {
> }
> 
> pokyo. gcc --syntax-only q.c
> q.c:3:1: error: attributes should be specified before the declarator in a
> function definition
>  void definition(void) __attribute__((const))
>  ^

OK, that explains a lot.  The kernel extensively uses trailing attributes on
declarations, but a more careful look shows that the *only* trailing attributes
used in definitions appear via macros that only have non-empty definitions for
Sparse.  And Sparse parses those just fine.

Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug
already exist for that somewhere?), but not something that should block *this*
feature.

(As a vaguely related aside, how does GCC disambiguate whether an attribute
preceding the function declaration or definition applies to the return type or
to the function?  I really hope that doesn't depend on the specific attribute.)

> > In general, it seems useful to have the ability to reference argument names
> > in attributes on a function.  For instance, imagine using argument names
> > rather than indexes for the printf attribute or another attribute like it.
> 
> Yeah, I agree.
> 
> > The context attribute, though, wants something more complex than that: the
> > ability to provide expressions based on those arguments, such as arg->lock. 
> > That does seem like a tall order.
> 
> Ok, it wasn't clear to me exactly what the meaning of that argument was.
> From the original text here it seemed like it would just be a plain name.
> So, that's something to nail down.  I looked at sparse's test suite but
> it doesn't test this construct.

Because Sparse doesn't actually do anything with that argument yet other than
parse it. :)

The theory was that Sparse would associate locks with actual objects, and match
them up.  (And/or feed that information into a runtime checker.)  But since
Sparse doesn't have the necessary semantic analysis to check if two expressions
refer to the same object, and probably never will, that didn't happen.

GCC, on the other hand, has alias analysis and similar.  It doesn't seem too
ridiculous for GCC to detect that arg->lock in two successive function calls
refers to the same location.

> > So I suspect it may make sense to run this after inlining, specialization,
> > dead-code elimination, and similar.
> 
> One difficulty in this case is choosing how to represent __context__.
> My hack makes it a const function, and the value is never used, so gcc
> is free to just drop all the calls to it.  But the further back in
> the pipeline the new pass is added, the harder it is to preserve this.
> 
> It would be simpler for the plugin if __context__ were instead another
> attribute on a different set of functions.  I don't know how hard this
> is on the kernel end though.

Well, on the one hand, the compiler-specific header files could easily enough
provide a different definition for Sparse and GCC.  On the other hand, it seems
unfortunate if the syntax doesn't actually match Sparse.  On the third hand,
very few users exist *outside* the kernel, and Sparse could potentially support
a new syntax as well.

Could you represent __context__ as a new GCC builtin?  Would that make this any
easier?

Sparse actually tracks context as a property of basic blocks.

> > I don't mind the use of Python, though I wonder how easily such a script
> > could work by default.  Given this script, how do you invoke GCC and run it?
> > How much stability does this interface provide?  Could the Linux kernel ship
> > such a script and invoke it as part of the compile, given some dependency
> > checks (and likely a Kconfig option if it increases build time
> > significantly)?
> 
> One nice thing about Python is that because it is so dynamic, it's reasonably
> easy to make it adapt to different versions of gcc-python-plugin, if needed.
> 
> Running it is easy.  The "gcc-with-python2" wrapper script is just a
> single line:
> 
> ${CC:-gcc} -fplugin=python2 -fplugin-arg-python2-script=$@
> 
> So, it's really just adding a couple of options to the command line.
> 
> It wouldn't be completely nuts to just put the 

[Bug fortran/66465] Procedure pointer component & non-component interpreted as different type or kind

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Tue Nov 24 20:40:10 2015
New Revision: 230839

URL: https://gcc.gnu.org/viewcvs?rev=230839=gcc=rev
Log:
2015-11-24  Paul Thomas  

Backport from trunk.
PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-24  Paul Thomas  

Backport from trunk.
PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

Backport from trunk.
PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr66465.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/check.c
branches/gcc-5-branch/gcc/fortran/class.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[nenad at intrepid dot com]

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

--- Comment #9 from Nenad Vukicevic  ---
On 11/24/15 12:07 PM, iains at gcc dot gnu.org wrote:

> So I agree, the root problem is that we are creating something that the newer
> version of dsymutil doesn't understand - it could be we're making a mistake or
> new dsymutil could be still green.

I tried to run Clang's llvm-dsymutil form the locally built clang tools.
 Fails the same way.  And the error is coming from this routine:

124 /// Interpret the STAB entries to fill the DebugMap.
125 void MachODebugMapParser::handleStabSymbolTableEntry(uint32_t


> What happens if you do a clang link and then do "dsymutil result"?

Linking with clang and "dsymutil result" produces similar results -
'failed to insert symbol' messages.  But then it complains on lots of
object files as it cannot find them.

I checked the clang code (and some logs) and clang does NOT call
dsymutil for our case.

Note that we are compiling through a fairly complex UPC driver, part of
Berkeley UPC toolset, and we get this warnings only if our back-end
compiler is GCC from our GNU UPC branch (which is in sync with the
trunk).  Using Clang as back-end compiler does not produce warning as
they do not run the tool at the and - linking phase.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[tromey at gcc dot gnu.org]

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

--- Comment #7 from Tom Tromey  ---
(In reply to PaX Team from comment #5)

> since PaX already has a checker plugin

Why not just contribute that then?

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[pageexec at gmail dot com]

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

--- Comment #5 from PaX Team  ---
(In reply to Josh Triplett from comment #4)
> (In reply to Tom Tromey from comment #3)
> (As a vaguely related aside, how does GCC disambiguate whether an attribute
> preceding the function declaration or definition applies to the return type
> or to the function?  I really hope that doesn't depend on the specific
> attribute.)

AFAIK, you can't put an attribute on the return type, it'll be interpreted as a
function attribute instead (and on definitions you can't place them after the
function arguments). the only way to put attrs on the return type is via a
typedef.

> Could you represent __context__ as a new GCC builtin?  Would that make this
> any easier?

it can be a builtin or just a regular function declaration, the latter is easy
to create from a plugin too.

> So, I suspect the unfortunate answer is that Linux would probably want to
> ship the plugin as C/C++ and build it at build time if enabled.  (Or we could
> integrate this functionality into GCC itself.)

since PaX already has a checker plugin i subscribed to this bug a while ago but
completely forgot about it until now ;P. in any case, i've begun to work on
this along a somewhat different angle: instead of adding completely new
machinery to detect context imbalances i'd like to reuse existing gcc passes to
compute this property, we'll see how it goes.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #26 from mrs at gcc dot gnu.org  ---
Are there any symbols in .text?  If so, this is wrong.  All symbols have to
have 1 or more bytes after them.  This is just how the ABI is.  The creator of
a symbol with no content after is needs to be fixed, if so.  gcc_unreablable is
one way to zap things so that there is no nop.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #7)

> > Maybe line 820 should pass 'false' as this is the case similar to LTO
> > not being enabled?
> 
> That seems reasonable a first blush, we should _not_ call dsymutil for

I made this change on gcc-5.2.1 and it appears to DTRT (I think we need to find
the original PR that got this introduced, and check we're not missing some
corner-case tho).

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[tromey at gcc dot gnu.org]

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

--- Comment #6 from Tom Tromey  ---
(In reply to Josh Triplett from comment #4)

> Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug
> already exist for that somewhere?), but not something that should block
> *this*
> feature.

Offhand I don't know if there is a bug covering this.

> (As a vaguely related aside, how does GCC disambiguate whether an attribute
> preceding the function declaration or definition applies to the return type
> or
> to the function?  I really hope that doesn't depend on the specific
> attribute.)

It does, see the various *_required fields in struct attribute_spec
(tree-core.h).  It's worse than you think, as I believe a given
attribute handler can decide where to put the attribute based on any
criteria it likes.

> Could you represent __context__ as a new GCC builtin?  Would that make this
> any
> easier?

It's basically the same thing.

One idea might be not to make the function const; then have the pass
rip out the calls to it.

However then you might have a situation where these calls formerly
interfered with some optimization, meaning that their presence did
affect code generation.  I don't really know if this is possible.

> Sparse actually tracks context as a property of basic blocks.

I was thinking this might be doable but I don't really know how
gcc handles basic block coalescing -- if two blocks are merged
we'd want to ensure that the resulting block ends up with the
correct context property.

It might help to see exactly where __context__ is used in real code.

> (if
> they ship it at all; AFAICT Debian only ships gcc-python3-plugin).

The version of python doesn't matter much.

For people whose distro doesn't package gcc-python-plugin, it is simple
to build; just git clone + make.

> So, I suspect the unfortunate answer is that Linux would probably want to
> ship
> the plugin as C/C++ and build it at build time if enabled.

That's also fine, it's easy(-ish) to rewrite.

[Bug c/68524] New: Please support attributes between function definition and opening brace

[josh at joshtriplett dot org]

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

Bug ID: 68524
   Summary: Please support attributes between function definition
and opening brace
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josh at joshtriplett dot org
  Target Milestone: ---

GCC supports placing attributes after the closing parenthesis of a function
declaration and before the semicolon.  However, GCC produces an error on
attributes between the closing parenthesis of a function definition and the
opening brace; for instance:

void f(void) __attribute__((const))
{
}

test.c:1:1: error: attributes should be specified before the declarator in a
function definition
 void f(void) __attribute__((const))
 ^

Sparse's C parser supports this.  Could GCC support this syntax as well?

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #13 from Josh Triplett  ---
(In reply to PaX Team from comment #12)
> 2. as for my idea, it's simple: track the context via an artificially
> injected local integer variable (one per context if you want context
> sensitivity) and initialize it to the 'in' attr parameter or 0 otherwise
> then adjust its value on function calls that affect it based on the callee's
> context attribute. at the end compare the variable against the 'out' attr
> parameter (or 0) and complain on a mismatch (in my proof-of-concept i just
> called builtin_trap on a mismatch). now where gcc comes in is that it'll do
> constant propagation, DCE, etc for free so the final check either gets
> removed by dead code elimination (the locking is correct) or we detected a
> locking problem and can even determine the bad path(s). using this simple
> method on Josh's test file there're no false positives or false negatives.
> i'll work it into something usable (actual reports instead of having to
> check for leftover builtin_traps) and release it in PaX then linux can pick
> it up when the time comes.

That sounds really plausible to me.  GCC's constant propagation seems likely to
do *at least* as well as Sparse does, if not better.  (As long as you have
optimizations turned on, anyway.)

Note that in addition to complaining if *any* exit to the function doesn't have
the correct "out" value, you also need to complain if calls to functions with
the context attribute don't have the necessary "in" value.  You may want to
make that a separate warning option, though, as that option tends to force
adding annotations to far more functions.

This approach won't necessarily provide the "different contexts for basic
block" warning that Sparse has, but I don't necessarily think we need that; we
only care about running a block with different locks if that block actually
wants a lock.  (Some prototypes in Sparse once provided a separate attribute
for use on structure fields, that specified the lock you have to hold to touch
that field; that could act as another assertion on the context.)

[Bug target/68532] New: [ARM] Incorrect code result on arm big endian

[michael.collison at linaro dot org]

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

Bug ID: 68532
   Summary: [ARM] Incorrect code result on arm big endian
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.collison at linaro dot org
  Target Milestone: ---

The following test case produces the incorrect answer on arm big endian with
the following options:  -O2 -ftree-vectorize -fno-vect-cost-model 
-mcpu=cortex-a8 -mfpu=neon

Result should be '960', armbe generate '992' as the result.

#include 
#include 

#define SIZE 128
unsigned short alignas(16) in[SIZE];

__attribute__ ((noinline)) int
test (unsigned short diff, unsigned short *in, int x)
{
for (int j = 0; j < SIZE; j+=8)
  diff += in[j] * x;
return diff;
}

int main()
{
for (int i = 0; i

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Created attachment 36829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36829=edit
Reduced test case for gfortran.dg/minlocval_3.f90

With the attached test the warnings with '-g -flto' are

warning: (x86_64)  could not find object file symbol for symbol _A.28.3542
warning: (x86_64)  could not find object file symbol for symbol _A.36.3560
warning: (x86_64)  could not find object file symbol for symbol _A.44.3580
warning: (x86_64)  could not find object file symbol for symbol _A.50.3594
warning: (x86_64)  could not find object file symbol for symbol _A.56.3608
warning: (x86_64)  could not find object file symbol for symbol _A.62.3622
warning: (x86_64)  could not find object file symbol for symbol _A.68.3636
warning: (x86_64)  could not find object file symbol for symbol _A.74.3650
warning: (x86_64)  could not find object file symbol for symbol _A.80.3664
warning: (x86_64)  could not find object file symbol for symbol _A.86.3678
warning: (x86_64)  could not find object file symbol for symbol _A.92.3690
warning: (x86_64)  could not find object file symbol for symbol _A.102.3710
warning: (x86_64)  could not find object file symbol for symbol _A.123.3779
warning: (x86_64)  could not find object file symbol for symbol _A.131.3805
warning: (x86_64)  could not find object file symbol for symbol _A.154.3862
warning: (x86_64)  could not find object file symbol for symbol _A.164.3882
warning: (x86_64)  could not find object file symbol for symbol _A.174.3905
warning: (x86_64)  could not find object file symbol for symbol _A.190.3938
warning: (x86_64)  could not find object file symbol for symbol _A.206.3971
warning: (x86_64)  could not find object file symbol for symbol _A.222.4004
warning: (x86_64)  could not find object file symbol for symbol _A.238.4034
warning: (x86_64)  could not find object file symbol for symbol _A.250.4057

These warnings disappear if I remove a single 'if'.

[Bug middle-end/68512] Non-deterministic behavior from gcc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/68437] [concepts] fold expression, pack expansion, and deduced constraint requirement

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #29 from Joost VandeVondele  
---
(In reply to Thomas Koenig from comment #27)
> (In reply to Joost VandeVondele from comment #22)
> If the compiler turns out not to be reasonably smart, file a bug report :-)

what is needed for large matrices (in my opinion) is some simple loop tiling,
as can, in principle, be achieved with graphite : this is my PR14741

Good vectorization, which gcc already does well, just requires the proper
compiler options for the matmul implementation, i.e. '-O3 -march=native
-ffast-math'. However, this would require the Fortran runtime to be compiled
with such options, or at least a way to provide specialized (avx2 etc)
routines.

There is however the related PR (inner loop of matmul) : PR25621, where some
unusual flag combo helps (-fvariable-expansion-in-unroller -funroll-loops)

I think external blas and inlining of small matmuls are good things, but I
would expect the default library implementation to reach at least 50% of peak
(for e.g. a 4000x4000 matrix), which is not all that hard. Actually, would be
worth an experiment, but a Fortran loop nest which implements a matmul compiled
with ifort would presumably reach that or higher :-).

These slides show how to reach 90% of peak:
http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/
the code actually is not too ugly, and I think there is no need for the
explicit vector intrinsics with gcc.

I believe I had once a bug report open for small matrices, but this might have
been somewhat fixed in the meanwhile.

[Bug c++/68434] [concepts] ICE: same canonical type node for different types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle  ---
(In reply to Janne Blomqvist from comment #25)

> 
> But, that is not particularly impressive, is it? I don't know about current
> low end graphics adapters, but at least the high end GPU cards (Tesla) are
> capable of several Tflops. Of course, there is a non-trivial threshold size
> to amortize the data movement to/from the GPU.

Not even a graphics card, just the on system chip on a low end laptop. Not
trying to impress, just pointing out that the hardware acceleration is fairly
ubiquitous these days, so why not just use it.  Maybe not important for serious
computing where users already have things like your 20 core machine.
> 
> With the test program from #12, with OpenBLAS (which BTW should be available
> in Fedora 22 as well) I get 337 Gflops/s, or 25 Gflops/s if I restrict it to
> a single core with the OMP_NUM_THREADS=1 environment variable. This on a
> machine with 20 2.8 GHz Ivy bridge cores.
> 
> I'm not per se against using GPU's, but I think there's a lot of low hanging
> fruit to be had just by making it easier for users to use a high performance
> BLAS implementation.

I agree, if available external BLAS does what is needed very good, What I am
exploring is one of those external BLAS libraries that uses GPU.  Maybe the
answer to this PR is "use an external BLAS" and close this PR.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> We are getting a similar issue while linking a program with GCC and
> without '-flto' switch.  We enable 'lto' when configuring languages,
> which in turn enables post ld processing inside collect2.  This was done
> as part of the bug #61352 patch.

I am not sure to understand the comment. Do you mean that your build is
configured to use '-flto' by default? Do you have a non-fortran reproducer? If
yes, could you please post it?

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
A slightly different, but equivalent testcase:

int i;
unsigned u;
volatile unsigned int *e;
void
fn1 (void)
{
  (short) ((i ? *e : 0) & ~u | i & u);
}

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Just as an update: the series is now tested and hopefully ready to post.  I
just need to clear a few things first.

[Bug c++/68449] ICE in cxx_eval_constant_expression on atomic_load in C++

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

[Bug c++/68429] [concepts] ICE in in placeholder_extract_concept_and_args, at cp/constraint.cc:1401

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 CC||paolo.carlini at oracle dot com
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/68411] Error in template instantiation, cause recursive template reference.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c++/68394] [concepts] segfault in valid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/68395] [concepts] segfault in valid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/68388] incomplete type bug when using decltype

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Done.

[Bug c++/68388] incomplete type bug when using decltype

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Nov 24 18:16:26 2015
New Revision: 230827

URL: https://gcc.gnu.org/viewcvs?rev=230827=gcc=rev
Log:
2015-11-24  Paolo Carlini  

PR c++/68388
* g++.dg/cpp1y/pr68388.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68388.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68278] internal compiler error with C++14 polymorphic lambda and type alias

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Nov 24 18:30:02 2015
New Revision: 230828

URL: https://gcc.gnu.org/viewcvs?rev=230828=gcc=rev
Log:
2015-11-24  Paolo Carlini  

PR c++/68278
* g++.dg/cpp1y/pr68278.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68278.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68278] internal compiler error with C++14 polymorphic lambda and type alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug c++/68252] [5 regression] left operand of shift expression, while we shift > 0 integer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords|wrong-code  |rejects-valid
Summary|regiression left operand of |[5 regression] left operand
   |shift expression, while we  |of shift expression, while
   |shift > 0 integer   |we shift > 0 integer

--- Comment #3 from Paolo Carlini  ---
Mainline is fine, anyway.

[Bug target/67089] [4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 36830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36830=edit
gcc6-pr67089.patch

Untested patch for matching hand written unsigned addition/subtraction overflow
checks as {ADD,SUB}_OVERFLOW if target has u{add,sub}v4 optabs.

[Bug c++/68518] ICE on invalid code using lambda in variadic template in tsubst_copy, at cp/pt.c:12997

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

[Bug c++/68475] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

[Bug c++/68469] warn_unused_result attribute ignored for templates return templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

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

[ysrumyan at gmail dot com]

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

--- Comment #11 from Yuri Rumyantsev  ---
In fact, the problem is quite different although it is caused by non-profitable
pattern matching ~X CMP ~Y -> Y CMP X. In general this pattern may be helpful
if we can delete not operation, e.g.
  x1 = ~x;
  y1 = ~y;
  if (x1  y1) ... and there no any other uses of x1 and y1, i.e. x1 and y1
have single use. But if this is not truth we will increase register pressure
since we can not use the same register for x,x1 and y,y1.

Richard proposed to use the same simplification for min/max operations but
in original test-case nested min/max operation (min(x,min(y,z)) or multi
operand min/max (min(x,y,z)) are not recognized by gcc (Note that icc does such
transformation) and so this won't help since we have the same register pressure
issue:
c = ~r; 
m = ~g;
y = ~b;
k = min(c, m, y);
*out++ = c - k;
*out++ = m - k;
*out++ = y - k;
*out++ = k;
and we can see that value of 'c' is used in min computation and resulting
store, so if we will use r  g comparison we will increase live range for
r, g, b variables and additional registers will require for them (till
comparison).
Note also that there exists another issue with path-splitting (aka tail
duplication) which duplicate loop back edge and in fact move tail block to
hammock. This transformation does not loop useful (at least at given stage of
design) but this is another topic for discussion.

I'd like to propose to introduce new predicate for pattern matching which tells
us how much uses have left-hand side of ~x.

[Bug c++/68451] internal compiler error: Segmentation fault when using decltype with friend inside a class template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

[Bug c++/68487] [concepts] bad "invalid reference to variadic concept" error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 Ever confirmed|0   |1

[Bug target/68059] [arm] libgcc uses __write to report error

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Nov 24 16:10:55 2015
New Revision: 230820

URL: https://gcc.gnu.org/viewcvs?rev=230820=gcc=rev
Log:
2015-11-24  Szabolcs Nagy  

Backport from mainline
2015-11-23  Szabolcs Nagy  

PR target/68059
* config/arm/linux-atomic-64bit.c (__write): Rename to...
(write): ...this and fix the return type.


Modified:
branches/gcc-5-branch/libgcc/ChangeLog
branches/gcc-5-branch/libgcc/config/arm/linux-atomic-64bit.c

[Bug tree-optimization/68522] New: [6 Regression] SPEC CPU2006 435.gromacs miscomparison

[afomin.mailbox at gmail dot com]

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

Bug ID: 68522
   Summary: [6 Regression] SPEC CPU2006 435.gromacs miscomparison
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com, law at redhat dot com
  Target Milestone: ---
Target: i686-*-*

There is a miscomparison between actual and reference data after r230364 for
435.gromacs benchmark from SPEC CFP006.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> This one fails for me with -O2 ...

You don't need any optimization to reproduce. The ICE comes from the nested
CSHIFT.

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[guille at cal dot berkeley.edu]

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

--- Comment #27 from Guille  ---
(In reply to Guille from comment #26)
> In the case below (fails to compile ssl.h on OSX 10.9.5), 
>  I could simply go to ssl.h lines 337 and 339 and comment out the
>  'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER'.. 
> then it compiled no problem. 

I tested that again. Ignore the above comment. 
One can make it compile as follows.
This is the *original* relevant part of ssl.h:
330: struct bn_gencb_st
 {
  unsigned int ver;   /* To handle binary (in)compatibility */
  void *arg;  /* callback-specific data */
  union
335:  {
  /* if(ver==1) - handles old style callbacks */
  void (*cb_1)(int, int, void *)
DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
  /* if(ver==2) - new callback style */
  int (*cb_2)(int, int, BN_GENCB *)
DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
340:  } cb;
  };

take the union outside the struct and give it a name: 

   union bn_gencb_st__cb_t
   {
  void (*cb_1)(int, int, void *)
DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
  int (*cb_2)(int, int, BN_GENCB *)
DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
   };
   struct bn_gencb_st
   {
  unsigned int ver;
  void *arg;
  bn_gencb_st__cb_t cb;
   };

then it compiles fine. 

> 
> 
> (In reply to Guille from comment #24)
> > Yes, just checked that. 
> > 'gcc -g file_that_include_ssl_h.cpp' builds fine, but 
> > 'g++ -g file_that_include_ssl_h.cpp' ICEs. 
> > 
> > 
> > (In reply to Magnus Fromreide from comment #23)
> > > One more question - you are using the command
> > > 
> > > g++ -g file_that_include_ssl_h.cpp
> > > 
> > > right? Building it as C works for me as well.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[nenad at intrepid dot com]

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

--- Comment #6 from Nenad Vukicevic  ---
On 11/24/15 9:27 AM, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
> 
> --- Comment #5 from Dominique d'Humieres  ---
>> We are getting a similar issue while linking a program with GCC and
>> without '-flto' switch.  We enable 'lto' when configuring languages,
>> which in turn enables post ld processing inside collect2.  This was done
>> as part of the bug #61352 patch.
> 
> I am not sure to understand the comment. Do you mean that your build is
> configured to use '-flto' by default? Do you have a non-fortran reproducer? If
> yes, could you please post it?
> 

No, we configured for 'lto' with '--enable-languages' option, but do not
use it, no '-flto' on any of the compiled objects.

However, collect2 tries to find all the objects compiled with lto, it
does not find any, and calls 'post_ld_pass (true)' which executes
'dsymutil'.  This was the code that was added in the specified patch,
lines 819-820 of collect2.c.  If you configure without LTO you will not
see the problem as 'dsymutil' is not getting called.

If you look at the calls of procedure 'post_ld_pass()' (which calls
dsymutil), I think it calls dsymutil only if true is passed in and
debugging is enabled:

807:  post_ld_pass (true);  <--- LTO enabled, has LTO compiled objects
 (Fortran test issue)
814:  post_ld_pass (false); <--- LTO enabled, no LTO objects, force
 linking
820:  post_ld_pass (true);  <--- LTO enabled, NO LTO objects
 (My issue)
  post_ld_pass (false);
  post_ld_pass (false);
  post_ld_pass (false);

Maybe line 820 should pass 'false' as this is the case similar to LTO
not being enabled?

I think the problem is in the symbols we generate, or the tool itself,
and this issue shows up only if you have LTO enabled.  I can provide the
object file that has problems and this might be enough if someone builds
LLVM on Apple and tries llvm-dsymutil tool on it.  This should be the
same tool as Apple's dsymutil, if we can duplicate the problem then we
can debug it.

[Bug target/68059] [arm] libgcc uses __write to report error

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #5 from nsz at gcc dot gnu.org ---
fixed in r230820 (branch 5) and r230762 (mainline)

[Bug tree-optimization/67984] [GRAPHITE] internal compiler error: isl_ctx freed, but some objects still reference it

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
  Known to fail||5.2.1

--- Comment #4 from Sebastian Pop  ---
Fixed in trunk gcc 6.0 at r230826.

[Bug c++/68388] incomplete type bug when using decltype

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
This again compiles fine. I'm going to add a testcase and close the bug.

[Bug libstdc++/68515] std::result_of<F(X)> doesn't work when F is abstract (with pure virtual functions)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com
  Component|c++ |libstdc++

--- Comment #1 from Paolo Carlini  ---
Jon can you have a look?

[Bug c++/68495] Error when expanding nontype variadic argument in trailing return type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 CC||paolo.carlini at oracle dot com
 Blocks||55004
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Fixed on trunk. Should we backport to 5 branch?

[Bug libstdc++/68515] std::result_of<F(X)> doesn't work when F is abstract (with pure virtual functions)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I think it's a front-end problem, it (rightly) says that F(X) is not a valid
function type, because functions can't return abstract types. The problem is 
that we don't really have (or want) a function of that type, it's just the
notational trick used by result_of.

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[guille at cal dot berkeley.edu]

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

--- Comment #26 from Guille  ---
In the case below (fails to compile ssl.h on OSX 10.9.5), 
 I could simply go to ssl.h lines 337 and 339 and comment out the
 'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER'.. 
then it compiled no problem. 


(In reply to Guille from comment #24)
> Yes, just checked that. 
> 'gcc -g file_that_include_ssl_h.cpp' builds fine, but 
> 'g++ -g file_that_include_ssl_h.cpp' ICEs. 
> 
> 
> (In reply to Magnus Fromreide from comment #23)
> > One more question - you are using the command
> > 
> > g++ -g file_that_include_ssl_h.cpp
> > 
> > right? Building it as C works for me as well.

[Bug c++/68464] [6 Regression] ICE in valid constexpr function: ../../src/gcc/tree.c:11497

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
Summary|ICE in valid constexpr  |[6 Regression] ICE in valid
   |function:   |constexpr function:
   |../../src/gcc/tree.c:11497  |../../src/gcc/tree.c:11497
 Ever confirmed|0   |1

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Nov 24 18:58:28 2015
New Revision: 230832

URL: https://gcc.gnu.org/viewcvs?rev=230832=gcc=rev
Log:
2015-11-24  Steven G. Kargl  

PR fortran/68486
* simplify.c (gfc_simplify_cshift): Allow all EXPR_*.

2015-11-24  Steven G. Kargl  

PR fortran/68486
* gfortran.dg/simplify_cshift_3.f90

Added:
trunk/gcc/testsuite/gfortran.dg/pr68227.f90
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Unreopen.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Added:
> trunk/gcc/testsuite/gfortran.dg/pr68227.f90

Is it intended?

[Bug target/68416] [MPX] GCC emits a lot of redundant bndmov instructions

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Vladimir Makarov  ---
The first I thought it is a LRA inheritance bug but after more thorough
analysis I found that the problem comes from IRA.  IRA never assigns BND hard
registers to pseudos because it never assigns BNDREGS class to pseudos.  After
some investigation I found that ALL_REGS does not contain BNDREGS.  IRA starts
with ALL_REGS and uses narrow reg class if the mode is prohibited for some hard
registers.  That is why class BNDREGS is never used for pseudos.

The following patch solves the problem:

Index: config/i386/i386.h
===
--- config/i386/i386.h  (revision 230664)
+++ config/i386/i386.h  (working copy)
@@ -1457,7 +1457,7 @@ enum reg_class
 { 0x1ff1,0xffe0,   0x1f },   /* FLOAT_INT_SSE_REGS */\
{ 0x0,   0x0, 0x1fc0 },   /* MASK_EVEX_REGS */   \
{ 0x0,   0x0, 0x1fe0 },   /* MASK_REGS */ \
-{ 0x,0x, 0x1fff }\
+{ 0x,0x,0x1 }\
 }

 /* The same information, inverted:


Please, submit the patch to the trunk.

[Bug tree-optimization/68521] [6.0 regression] ICE on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-24
 CC||rsandifo at gcc dot gnu.org
  Component|fortran |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE appeared between revisions r228586 (2015-10-07, compiles) and r228678
(2015-10-10, ICE). The test compiles with -O1 but not with -O2.

Backtrace

Program received signal SIGSEGV, Segmentation fault.
gimple_stmt_nonnegative_warnv_p (stmt=,
strict_overflow_p=, depth=)
at ../../_clean/gcc/gimple-fold.c:6251
6251  switch (gimple_code (stmt))
(gdb) bt
#0  gimple_stmt_nonnegative_warnv_p (stmt=,
strict_overflow_p=, depth=)
at ../../_clean/gcc/gimple-fold.c:6251
#1  0x00010068ee65 in tree_expr_nonnegative_p (t=) at
../../_clean/gcc/fold-const.c:13182
#2  0x0001001e4948 in generic_simplify (loc=,
code=, type=, op0=)
at generic-match.c:6639
#3  0x00010069f244 in fold_unary_loc (loc=, code=, type=, op0=)
at ../../_clean/gcc/fold-const.c:7625
#4  0x0001006a072a in fold_build1_stat_loc (loc=,
code=, type=, op0=)
at ../../_clean/gcc/fold-const.c:12288
#5  0x0001009c7aaf in gimplify_build1 (gsi=, code=, type=, a=)
at ../../_clean/gcc/tree-cfg.c:8475
#6  0x0001009d7ca0 in tree_lower_complex () at
../../_clean/gcc/tree-complex.c:1113
#7  0x0001009d8b62 in ?? () at ../../_clean/gcc/tree-complex.c:1723
#8  0x0001008c390f in execute_one_pass (pass=) at
../../_clean/gcc/passes.c:2335
#9  0x0001008c3f28 in execute_pass_list_1 (pass=) at
../../_clean/gcc/passes.c:2408
#10 0x0001008c3f3a in execute_pass_list_1 (pass=) at
../../_clean/gcc/passes.c:2409
#11 0x0001008c3f8d in execute_pass_list (fn=,
pass=) at ../../_clean/gcc/passes.c:2419
#12 0x00010057a266 in cgraph_node::expand (this=) at
../../_clean/gcc/cgraphunit.c:1965
#13 0x00010057ba0f in symbol_table::compile (this=) at
../../_clean/gcc/cgraphunit.c:2101
#14 0x00010057daa4 in symbol_table::finalize_compilation_unit
(this=) at ../../_clean/gcc/cgraphunit.c:2514
#15 0x00010098fb4e in compile_file () at ../../_clean/gcc/toplev.c:489
#16 0x000100d8b983 in ?? ()
#17 0x000100d8d349 in main (argc=3, argv=0x7fff5fbff300) at
../../_clean/gcc/main.c:39

Revision r228614?

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Tue, Nov 24, 2015 at 07:07:44PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68486
> 
> --- Comment #12 from Dominique d'Humieres  ---
> > Added:
> > trunk/gcc/testsuite/gfortran.dg/pr68227.f90
> 
> Is it intended?
> 

Of course, not.  Hmmm, seems I fat-fingered commit.

% svn commit gcc/fortran/ChangeLog gcc/fortran/simplify.c \
  gcc/testsuite/gfortran.dg/simplify_cshift_3.f90 gcc/testsuite/

Not sure how the gcc/testsuite got on the end.  Oh well, the
testcase won't hurt anything.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #11 from Josh Triplett  ---
(In reply to Tom Tromey from comment #10)
> (In reply to Josh Triplett from comment #9)
> 
> > > It might help to see exactly where __context__ is used in real code.
> > 
> > A few patterns:
> 
> Sorry, I wasn't very clear.
> It seems to me that __context__ must be used as a kind of annotation
> alongside some effect-ful statement.  I'm curious what those statements
> are; and whether we could somehow annotate them directly.
> (I presume not since sparse didn't go that route, but I figured I'd ask.)

Such statements could potentially consist of inline assembly implementing a
lock.  __context__ potentially helps when implementing things as a macro.

That said, if absolutely necessary, I could imagine using exclusively the
context attribute and appropriate static inlines with that attribute.