[Bug target/61618] [5 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Uroš Bizjak  ---
Fixed in recent builds.

[Bug middle-end/63884] ICE: SIGSEGV in is_sec_implicit_index_fn with -fcilkplus and __builtin_sadd_overflow()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/63527] [5 Regression] -fPIC uses 2 registers for GOT

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #3 from Uroš Bizjak  ---
Still happens with r217599.

[Bug middle-end/63884] ICE: SIGSEGV in is_sec_implicit_index_fn with -fcilkplus and __builtin_sadd_overflow()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
It's just that the Cilk code isn't prepared for internal functions, which have
NULL CALL_EXPR_FN.

I'll prepare a patch.

[Bug c++/63885] New: ICE in static assert of constexpr forwarding xvalue container member rvalue reference

[listcrawler at gmail dot com]

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

Bug ID: 63885
   Summary: ICE in static assert of constexpr forwarding xvalue
container member rvalue reference
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: listcrawler at gmail dot com

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

Internal compiler error in static assert of constexpr forwarding xvalue
container member rvalue reference. 

g++ 4.8 and 4.9 passes, but trunk built from r217559 on ubuntu 14.04 fails
compilation with

$ g++-trunk -std=c++11 -Wall -Wextra constexpr_static_assert.ii
constexpr_static_assert.cpp:50:39:   in constexpr expansion of ‘get<0, S
>((* & S((* &1’
constexpr_static_assert.cpp:35:35:   in constexpr expansion of ‘__get<0,
T>::value&&>((* & std::forward >((* & arg’
constexpr_static_assert.cpp:50:44: internal compiler error: in
verify_ctor_sanity, at cp/constexpr.c:1779
 static_assert (get <0> (S  (1)) == 1, ""); // g++ 4.9 passes, g++
trunk r217559 fails

...

///
///
//
// source
//

#include 

using namespace std;

///

template  struct member_forward
{
typedef typename remove_reference ::type::type T;
typedef typename conditional
<
is_lvalue_reference ::value && not is_reference ::value,
typename add_lvalue_reference ::type,
T
>::type type;
};

template  using member_forward_t = typename member_forward
::type;

///

template  struct __get;
template <   typename T> struct __get <0, T> 
{ 
constexpr static auto value (T arg) 
 -> decltype ((forward > (arg.t))) 
{  
return forward > (arg.t); 
} 
};

template  constexpr auto get (T && arg)
 -> decltype (__get ::value (forward  (arg)))
{
return__get ::value (forward  (arg));
}

///

template  struct S
{
typedef T type;
T t;

template  constexpr S (U && u) : t (forward  (u)) {} 
};

///

static_assert (get <0> (S  (1)) == 1, ""); // g++ 4.9 passes, g++ trunk
r217559 fails

int main () {}

///
///

[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #8)
> I bet this is really the same as bug 63881.  The kernel is using /dev/null
> for both the input and output when testing if the options work.

No. From scripts/Kbuild.include:

126 # cc-disable-warning
127 # Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable) 
128 cc-disable-warning = $(call try-run,\   
129 $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -x c
/dev/null -o "$$TMP",-Wno-$(strip $(1)))

[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #8)
> I bet this is really the same as bug 63881.  The kernel is using /dev/null
> for both the input and output when testing if the options work.

Andrew, could you try if the patch above fixes bug 63881? If so, I would mark
that one as duplicate of this. I'm waiting for a bootstrap to finish just for
safe-checking, but then I will commit it as obvious.

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

[fxcoudert at gcc dot gnu.org]

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

Bug 63622 Summary: [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] 
after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622

   What|Removed |Added

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

[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #37 from Francois-Xavier Coudert  ---
Closing as fixed.

[Bug bootstrap/32719] ICE when compiling c-format.c

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Francois-Xavier Coudert  ---
There are still problems with powerpc-darwin on more recent GCC versions, but
they are tracked by other PRs. Let's close this one.

[Bug libstdc++/14608] nukes isfinite macro from

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|ia64-hp-hpux11.23,*-*-darwi |ia64-hp-hpux11.23
   |n   |

--- Comment #12 from Francois-Xavier Coudert  ---
I don't know what's the status of this on hpux, but on darwin it got fixed at
some point.

[Bug testsuite/29404] "make check" fails to compile library testcases

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #11 from Francois-Xavier Coudert  ---
*** Bug 42308 has been marked as a duplicate of this bug. ***

[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #5 from Francois-Xavier Coudert  ---
Indeed a duplicate of 29404 (and still present on trunk)

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

[Bug testsuite/29404] "make check" fails to compile library testcases

[fxcoudert at gcc dot gnu.org]

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

--- Comment #12 from Francois-Xavier Coudert  ---
Still present on trunk (5.0, end of stage 1).

[Bug libgcc/56634] libgcc does not compile for 4.7.2: Yields internal compiler error: Bus error

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #2 from Francois-Xavier Coudert  ---
Current branches (4.8, 4.9 and trunk) don't trigger this anymore on
ppc-darwin9. Closing.

[Bug boehm-gc/18135] gctest (boehm-gc) uses the installed libgcc_s on darwin

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #5 from Francois-Xavier Coudert  ---
Closing.

[Bug c/63886] New: float will fit into int with abs - possible missing warning Wabsolute-value

[dcb314 at hotmail dot com]

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

Bug ID: 63886
   Summary: float will fit into int with abs - possible missing
warning Wabsolute-value
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

# include 

extern void g(int);

void f( float qw)
{
int n = abs(qw);

g(n);
}

$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -pedantic nov15z.c
$ ~/gcc/results/bin/gcc -v
gcc version 5.0.0 20141112 (experimental) (GCC) 
$ ~/llvm/results/bin/clang -c -g -O2 -Wall nov15z.c
nov15z.c:10:10: warning: using integer absolute value function 'abs' when
  argument is of floating point type [-Wabsolute-value]
int n = abs(qw);
^

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
warning: conversion to ‘int’ from ‘float’ may alter its value
[-Wfloat-conversion]

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to Marc Glisse from comment #1)
> warning: conversion to ‘int’ from ‘float’ may alter its value
> [-Wfloat-conversion]

Thanks for that. 

Given the obscurity of -Wfloat-conversion, maybe it is time for it 
to be included in -Wall, where more folks will notice it ?

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> Given the obscurity of -Wfloat-conversion, maybe it is time for it 
> to be included in -Wall, where more folks will notice it ?

Scratch that. While -Wfloat-conversion does check fine for
int into double, it also does the "whole lot less useful, even
though technically accurate" double into float message.

Like

float f = 3.1;

warning: conversion to ‘float’ alters ‘double’ constant value
[-Wfloat-conversion]

I'll proceed with -Wfloat-conversion, but I'll be stripping out
(fgrep -v) these unwanted warnings.

[Bug c++/63887] New: abi_tag confuses demangler

[redi at gcc dot gnu.org]

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

Bug ID: 63887
   Summary: abi_tag confuses demangler
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org

struct __attribute((abi_tag("cxx11"))) time_get
{
  ~time_get();
};

int main()
{
  time_get t;
}

/tmp/ccvqinyx.o: In function `main':
/tmp/t.cc:8: undefined reference to `time_get[abi:cxx11]::~cxx11()'
collect2: error: ld returned 1 exit status

Note that the destructor name is ~cxx11 not ~time_get

[Bug bootstrap/63888] New: [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[hjl.tools at gmail dot com]

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

Bug ID: 63888
   Summary: [5 Regression] bootstrap failed when configured with
-with-build-config=bootstrap-asan --disable-werror
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86-64, r217602 gave

build/genmddeps /export/gnu/import/git/sources/gcc/gcc/common.md
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.md > tmp-mddeps
build/genmodes -h > tmp-modes.h

=
==31507==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x47b5da in __interceptor_malloc
/export/gnu/import/git/sources/gcc/libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x4b42d7 in xmalloc
/export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:147

SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s).
make[5]: *** [s-mddeps] Error 23

There are some global string variables initialized with

Breakpoint 5, xmalloc (size=size@entry=40)
at /export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:146
146size = 1;
(gdb) bt
#0  xmalloc (size=size@entry=40)
at /export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:146
#1  0x004b43d1 in xstrndup (
s=0x7fffe18a "/export/gnu/import/git/sources/gcc/gcc/common.md", 
n=)
at /export/gnu/import/git/sources/gcc/libiberty/xstrndup.c:56
#2  0x004aff9e in handle_toplevel_file (
handle_directive=handle_directive@entry=0x0)
at /export/gnu/import/git/sources/gcc/gcc/read-md.c:1008
#3  0x004b0672 in read_md_files (argc=, 
argv=, parse_opt=parse_opt@entry=0x0, 
handle_directive=handle_directive@entry=0x0)
at /export/gnu/import/git/sources/gcc/gcc/read-md.c:1138
#4  0x004059d1 in main (argc=, argv=)
at /export/gnu/import/git/sources/gcc/gcc/genmddeps.c:50
(gdb) c

They aren't freed before exit and are detected as memory leaks.
How can they be suppressed?

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[derrick.k at gmx dot de]

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

Derrick Kay  changed:

   What|Removed |Added

 CC||derrick.k at gmx dot de

--- Comment #53 from Derrick Kay  ---
Hi guys,

sorry for asking such a stupid question here: I wanted to install and use
Fortran on my Mac (never used it before) and ran into the problems with
compiling described here.

I have basically two questions:

1) which one of the patches reported and listed above shall I use?
2) I tried all of them, but I seem to have difficulties implementing them.
Someone suggested to go to the appropriate directory where gcc is stored (i.e.
SSD1 ▸ Applications ▸ Xcode ▸ Contents ▸ Developer ▸ usr ▸ bin) store the patch
file there (as a .diff, right?) and then execute in the terminal

patch -p1 < patchfilename.diff

then, i get

wlan251-121:patch3 Derrick$ patch -p1 < patch.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
|index 196eb3b..d55e200 100644
|--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
|+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
--
File to patch: 

i enter gcc, and then i get

patching file gcc
Hunk #1 FAILED at 835.
1 out of 1 hunk FAILED -- saving rejects to file gcc.rej
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?

I am really new to all of this... any hint on how to implement one of the
patches, and ideally which patch to use, would be very much appreciated. thank
you, best,
derrick

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

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

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

--- Comment #4 from Andreas Schwab  ---
float f = 3.1f;

[Bug fortran/63857] fixed form OpenACC directive ICE with -fopenacc -fopenmp

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Isn't it a duplicate of pr63858?

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[fxcoudert at gcc dot gnu.org]

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

--- Comment #54 from Francois-Xavier Coudert  ---
(In reply to Derrick Kay from comment #53)
I've redirected that question to the mailing list (and answered it):
https://gcc.gnu.org/ml/fortran/2014-11/msg00088.html

[Bug c++/63889] New: Ice with redundant static in class scope constexpr variable template.

[emsr at gcc dot gnu.org]

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

Bug ID: 63889
   Summary: Ice with redundant static in class scope constexpr
variable template.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emsr at gcc dot gnu.org

Created attachment 33984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33984&action=edit
Class snippet demonstrating the ICE.

This little test ices instead of issuing a warning (I'm not even sure it should
error) if a constexpr variable template member is declared static.

>From N3651 "A variable template at class scope is a static data member
template."

So the 'static', is at worst, redundant.

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.6.4
   Keywords||rejects-valid
   Last reconfirmed||2014-11-15
 CC||bur...@net-b.de
 Ever confirmed|0   |1
Summary|Duplicate use-statement |[4.8/4.9/5 Regression]
   |causes error|Duplicate use-statement
   ||causes error
  Known to fail||4.6.4, 4.8.3, 4.9.2, 5.0

--- Comment #1 from Dominique d'Humieres  ---
The code is accepted by fortran 4.7.0 r176194 (2011-07-12) and rejected by
r176695 (2011-07-23) and above (up to trunk 5.0). I think it is r176375
(pr34657) where the error message has been introduced.

[Bug target/63890] New: [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63890
   Summary: [4.9/5.0 regression] Compiling trivial program with -O
-p leads to misaligned stack
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Created attachment 33985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33985&action=edit
Assembler generated by trunk compiler with "-m32 -O -p"

Compile the following trivial program with trunk (rev. 217599) or the released
4.9.2 gcc leads to runtime segfault, on x86_64-apple-darwin14:

$ cat a.c
int main (void) { __builtin_exit (0); }
$ ./bin/gcc -m32 -O -p a.c && ./a.out
zsh: segmentation fault  ./a.out

This shows up as a failure of gcc.dg/20021014-1.c in the testsuite results
(https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01533.html).

Removing -p, or -O, or compiling for 64-bit doesn't trigger the bug. The
backtrace is:

  * frame #0: 0x9036f440 libdyld.dylib`misaligned_stack_error_
frame #1: 0x1f75 a.out`main + 17
frame #2: 0x903716d9 libdyld.dylib`start + 1

Comparing the generated assembly by the trunk compiler (bad-trunk.s) with that
generated by the 4.8.3 compiler (ok-48.s) shows the difference is simple:

--- ok-48.s2014-11-15 16:17:55.0 +0100
+++ bad-trunk.s2014-11-15 16:17:44.0 +0100
@@ -1,4 +1,4 @@
-.text
+.section __TEXT,__text_startup,regular,pure_instructions
 .globl _main
 _main:
 LFB0:
@@ -7,12 +7,12 @@ LCFI0:
 movl%esp, %ebp
 LCFI1:
 pushl%ebx
-subl$20, %esp
+subl$16, %esp
 LCFI2:
 call___x86.get_pc_thunk.bx
 L1$pb:
 call mcount
-movl$0, (%esp)
+pushl$0
 call_exit
 LFE0:
 .section __TEXT,__textcoal_nt,coalesced,pure_instructions

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

[Bug target/63891] New: [5.0 regression] Failure of darwin-weakimport-3.c

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63891
   Summary: [5.0 regression] Failure of darwin-weakimport-3.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Current trunk shows runtime failure for gcc.dg/darwin-weakimport-3.c on
x86_64-apple-darwin14 with -m32. The difference in the assembler between the
4.9.2 compiler (good) and the trunk compiler (bad, revision 217599) is:

$ diff -pu good-49.s bad-trunk.s 
--- good-49.s2014-11-15 16:33:50.0 +0100
+++ bad-trunk.s2014-11-15 16:33:30.0 +0100
@@ -3,6 +3,15 @@
 _foo:
 pushl%ebp
 movl%esp, %ebp
+call___x86.get_pc_thunk.ax
+L1$pb:
+nop
 popl%ebp
 ret
+.section __TEXT,__textcoal_nt,coalesced,pure_instructions
+.weak_definition___x86.get_pc_thunk.ax
+.private_extern___x86.get_pc_thunk.ax
+___x86.get_pc_thunk.ax:
+movl(%esp), %eax
+ret
 .subsections_via_symbols


The presence of the line with "coalesced" makes the test fail.

[Bug target/63891] [5.0 regression] Failure of darwin-weakimport-3.c

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2014-11-15
 CC||iains at gcc dot gnu.org
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Dominque, as you changed:

- Status: UNCONFIRMED
+ Status: NEW
+ Keywords: rejects-valid 

Can you quote the standard which permits this? My feeling is that the code is
invalid, but I have to admit that it is only a feeling.

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net

--- Comment #1 from Francois-Xavier Coudert  ---
Also failing due to the same bug: gcc.dg/pr43643.c

[Bug target/63891] [5.0 regression] Failure of darwin-weakimport-3.c

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||evstupac at gmail dot com

--- Comment #1 from Iain Sandoe  ---
confirmed on x86_64-darwin12.

this is generating an unnecesary picbase (since it is unused in the function),
and thus the thunk - which triggers the failure.

This is probably more fallout from the EBX changes.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[howarth at bromo dot med.uc.edu]

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

--- Comment #55 from howarth at bromo dot med.uc.edu ---
(In reply to Derrick Kay from comment #53)

If you just want the gfortran compiler for Yosemite, either install the gcc49
package under the fink (http://www.finkproject.org), MacPorts
(http://www.macports.org) or homebrew (http://brew.sh) packaging systems. Also,
a stand-alone installation of gfortran for Yosemite is available at
http://hpc.sourceforge.net.

[Bug target/63891] [5.0 regression] Failure of darwin-weakimport-3.c

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> This is probably more fallout from the EBX changes.

Yep! I see the failure with r216154 but not with 216153.

[Bug c/61053] [4.9/4.10 Regression] _Alignas(long long) reduces alignment of long long

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||fxcoudert at gcc dot gnu.org,
   ||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net
 Resolution|FIXED   |---

--- Comment #8 from Francois-Xavier Coudert  ---
The testcase introduced in fixing this bug (gcc.dg/pr61053.c) fails on
x86_64-apple-darwin14 with -m32, because of excess errors:

gcc.dg/pr61053.c:70:28: error: '_Alignas' specifiers cannot reduce alignment of
'ldi'
gcc.dg/pr61053.c:71:33: error: '_Alignas' specifiers cannot reduce alignment of
'ldl'
gcc.dg/pr61053.c:72:38: error: '_Alignas' specifiers cannot reduce alignment of
'ldll'
gcc.dg/pr61053.c:73:30: error: '_Alignas' specifiers cannot reduce alignment of
'ldf'
gcc.dg/pr61053.c:74:31: error: '_Alignas' specifiers cannot reduce alignment of
'ldd'

The testcase does not expect those for ia32, but we have them on darwin because
long double has 16 bytes alignment both at -m32 and -m64.
I don't know what's the best way to adapt the dg-error clauses, however.

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||evstupac at gmail dot com

--- Comment #2 from Iain Sandoe  ---
confirmed on x86_64-darwin12 (217256 gcc04.9 and recent trunk).

this would presumably affect targets other than darwin, too.

looks like the call to the pic base is both (a) unnecessary and (b) hoisted too
early in the routine.  Having said that, the call to mvount would fail if the
thunk call was dropped.

possibly? more fallout from the EBX changes? (maybe not, but worth a look).

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Can you quote the standard which permits this? My feeling is that the code
> is invalid, but I have to admit that it is only a feeling.

How do you read the following?

> 11.2.2 The USE statement and use association
> ...
> R rename is local-name => use-name
> ...
> NOTE 11.9
> There is no prohibition against a use-name or use-defined-operator appearing
> multiple times in one USE statement or in multiple USE statements involving
> the same module. As a result, it is possible for one use-associated entity
> to be accessible by more than one local identier.

[Bug target/63892] New: [5.0 regression] gcc.dg/sibcall-3.c fails on darwin with -m32

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63892
   Summary: [5.0 regression] gcc.dg/sibcall-3.c fails on darwin
with -m32
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Created attachment 33986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33986&action=edit
Assembler generated by the 4.9.2 compiler and trunk

Compiling sibcall-3.c with "-O2 -foptimize-sibling-calls -m32" on
x86_64-apple-darwin14 leads to runtime abort: on line 76, the test (trackpoint
!= stackpos) is true.

I attach to this PR the sibcall-3.c source (slightly amended so it prints out
the values of the pointers that should be equal), and the assembler generated
by the 4.9.2 compiler and trunk, both with "-O2 -foptimize-sibling-calls -m32".

[Bug target/63892] [5.0 regression] gcc.dg/sibcall-3.c fails on darwin with -m32

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

--- Comment #1 from Francois-Xavier Coudert  ---
Also, maybe worth mentioning: there was a patch (PR60104) for
sibling-tail-calls that broke darwin earlier this year, maybe this is related.

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> possibly? more fallout from the EBX changes? (maybe not, but worth a look).

I doubt it: r203168 (2013-10-03) is OK, r203190 (2013-10-03) is not.

[Bug middle-end/63879] ICE compiling Linux Kernel fs/ext3/namei.c

[sasha.levin at oracle dot com]

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

--- Comment #2 from Sasha Levin  ---
$ gcc -Wp,-MD,fs/ext3/.namei.o.d  -nostdinc -isystem
/home/sasha/gcc-inst/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include
-I./arch/x86/include -Iarch/x86/include/generated  -Iinclude
-I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -m64
-mno-80387 -mno-fp-ret-in-387 -march=native -mno-red-zone -mcmodel=kernel
-funit-at-a-time -maccumulate-outgoing-args -DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -fno-delete-null-pointer-checks -O2
--param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone
-fno-partial-inlining -Wframe-larger-than=2048 -fstack-protector
-Wno-unused-but-set-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fno-var-tracking-assignments -g -gdwarf-4 -pg
-mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO   
-fsanitize=kernel-address -fasan-shadow-offset=0xdfffe900 --param
asan-instrumentation-with-call-threshold=1   -fsanitize=undefined 
-fno-sanitize=unreachable  -fno-sanitize=float-cast-overflow   
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(namei)" 
-D"KBUILD_MODNAME=KBUILD_STR(ext3)" -c -o fs/ext3/.tmp_namei.o fs/ext3/namei.i
{standard input}: Assembler messages:
{standard input}:2183: Warning: end of file not at end of a line; newline
inserted
{standard input}:4163: Error: number of operands mismatch for `movq'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
gcc: internal compiler error: Segmentation fault (program cc1)
0x40c3cc execute
../../gcc/gcc.c:2912
0x410917 driver::do_spec_on_infiles() const
../../gcc/gcc.c:7674
0x40322b driver::main(int, char**)
../../gcc/gcc.c:6911
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/63892] [5.0 regression] gcc.dg/sibcall-3.c fails on darwin with -m32

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
This is cause by r216305: no failure with r216304.

[Bug target/63891] [5.0 regression] Failure of darwin-weakimport-3.c

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert  ---
This same bug may also be the root for:
 FAIL: gcc.dg/torture/builtin-self.c   -O0   scan-assembler-not \\tcall

which is also a 5.0 regression, due to the extra "call   
___x86.get_pc_thunk.ax". Dominique, could you check whether both appeared at
the same time?

[Bug target/63891] [5.0 regression] Failure of darwin-weakimport-3.c

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Dominique, could you check whether both appeared at the same time?

Yes: r216154.

[Bug middle-end/63879] ICE compiling Linux Kernel fs/ext3/namei.c

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Sasha Levin from comment #2)
> $ gcc -Wp,-MD,fs/ext3/.namei.o.d  -nostdinc -isystem
> /home/sasha/gcc-inst/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include
> -I./arch/x86/include -Iarch/x86/include/generated  -Iinclude
> -I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I./include/uapi
> -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__
> -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> -fno-common -Werror-implicit-function-declaration -Wno-format-security
> -std=gnu89 -m64 -mno-80387 -mno-fp-ret-in-387 -march=native -mno-red-zone
 ^
Please show the output of "gcc -v" when -march=native is used.  No one
can guess what your CPU is.

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
>From archives on x86_64-apple-darwin10, the problem was already there at
r203176.

[Bug middle-end/63879] ICE compiling Linux Kernel fs/ext3/namei.c

[sasha.levin at oracle dot com]

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

--- Comment #4 from Sasha Levin  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/sasha/gcc-inst/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/sasha/gcc-inst/ --with-arch=native
--with-tune=native --enable-languages=c --enable-lto --enable-gold
--enable-stage1-languages=c
Thread model: posix
gcc version 5.0.0 20141114 (experimental) (GCC)

[Bug target/61570] -march=native CPU you selected does not support x86-64 instruction under QEMU

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.4

--- Comment #9 from Francois-Xavier Coudert  ---
I think this one should have been closed.

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---

recent trunk on linux -m32 -O -p doesn't segv 
- but the stack looks odd at the mcount call.

.file"t.c"
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
leal4(%esp), %ecx
.cfi_def_cfa 1, 0
andl$-16, %esp
pushl-4(%ecx)
pushl%ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
movl%esp, %ebp
pushl%ecx
.cfi_escape 0xf,0x3,0x75,0x7c,0x6
subl$16, %esp
1:callmcount
pushl$0
callexit
.cfi_endproc
.LFE0:
.sizemain, .-main
.ident"GCC: (GNU) 5.0.0 20141112 (experimental) [trunk revision
217427]"
.section.note.GNU-stack,"",@progbits

[Bug target/60104] load not folded into indirect branch on x86-64

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert  ---
Testcase gcc.target/i386/sibcall-1.c fails on x86_64-apple-darwin14 (compiled
with "-O2 -m32"). Assembler code generated is:

.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB0:
.text
LHOTB0:
.align 4,0x90
.globl _boo
_boo:
LFB0:
call___x86.get_pc_thunk.ax
L1$pb:
movlL_foo$non_lazy_ptr-L1$pb(%eax), %eax
movl(%eax), %eax
jmp*%eax
LFE0:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE0:
.text
LHOTE0:
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
.weak_definition___x86.get_pc_thunk.ax
.private_extern___x86.get_pc_thunk.ax
___x86.get_pc_thunk.ax:
LFB1:
movl(%esp), %eax
ret
LFE1:
.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long0
.byte0x1
.ascii "zR\0"
.byte0x1
.byte0x7c
.byte0x8
.byte0x1
.byte0x10
.byte0xc
.byte0x5
.byte0x4
.byte0x88
.byte0x1
.align 2
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.longLASFDE1-EH_frame1
.longLFB0-.
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte0
.align 2
LEFDE1:
LSFDE3:
.set L$set$3,LEFDE3-LASFDE3
.long L$set$3
LASFDE3:
.longLASFDE3-EH_frame1
.longLFB1-.
.set L$set$4,LFE1-LFB1
.long L$set$4
.byte0
.align 2
LEFDE3:
.section __IMPORT,__pointers,non_lazy_symbol_pointers
L_foo$non_lazy_ptr:
.indirect_symbol _foo
.long0
.subsections_via_symbols

[Bug fortran/63858] fixed form OpenACC directive ICE with -fopenacc -fopenmp

[cesar at codesourcery dot com]

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

--- Comment #4 from Cesar Philippidis  ---
*** Bug 63857 has been marked as a duplicate of this bug. ***

[Bug fortran/63857] fixed form OpenACC directive ICE with -fopenacc -fopenmp

[cesar at codesourcery dot com]

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

Cesar Philippidis  changed:

   What|Removed |Added

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

--- Comment #2 from Cesar Philippidis  ---
Yeah. For some reason, I thought I had two specific bugs with -fopenacc
-fopenmp. I'll close this one as a duplicate.

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

[Bug target/63893] New: gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63893
   Summary: gcc.dg/pr61599-1.c fails on darwin, due to
-mcmodel=medium
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

$ ./bin/gcc pr61599-1.c pr61599-2.c -mcmodel=medium -fdata-sections
Undefined symbols for architecture x86_64:
  "_GLOBAL_OFFSET_TABLE_", referenced from:
  _main in ccHQCqNA.o
  _bar in cckQelee.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

I get that -mcmodel=medium is not working well for darwin at the moment, but
didn't know whether there is already a bug tracking that in general at the
moment. So I open this one.

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC|bur...@net-b.de |

--- Comment #4 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #3)
> > 11.2.2 The USE statement and use association
> > ...
> > R rename is local-name => use-name
> > ...
> > NOTE 11.9
> > There is no prohibition against a use-name or use-defined-operator appearing
> > multiple times in one USE statement or in multiple USE statements involving
> > the same module. As a result, it is possible for one use-associated entity
> > to be accessible by more than one local identier.

But that means things like:
  use m, only: A => X
  use m, only: B => X
which makes m's X (use-name) available under the names A and B (local-name).

In the case at hand, we have something more like:
  use m, only: A => X
  use m, only: A => Y
i.e. the LHS (local-name) is the same. In this example of mine A and A point to
a different object (X and Y), which is clearly ambiguous and invalid (at least
as soon as "A" is used). The question is whether it becomes valid if one uses:
  use m, only: A => X
  use m, only: A => X
i.e. the same object on the RHS.

The Fortran standard has:
"Within its scope, a local identifier of one class shall not be the same as
another local identifier of the same class, except that a generic name may be
the same as the name of a procedure as explained in 12.4.3.5 or the same as
the name of a derived type (4.5.10). A local identifier of one class may be the
same as a local identifier of another class." (F2015 draft, 14-007r2, 16.3.1)

And in the module section (11.2.2)
"Two or more accessible entities, other than generic interfaces or defined
operators, may have the same local identifier only if the identifier is not
used. Generic interfaces and defined operators are handled as described in
12.4.3.5. Except for these cases, the local identifier of any entity given
accessibility by a USE statement shall differ from the local identifiers of all
other entities accessible to the scoping unit."

I have to admit that I am unsure whether it is valid or not.

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[fxcoudert at gcc dot gnu.org]

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

--- Comment #1 from Francois-Xavier Coudert  ---
gcc.target/i386/pr63538.c also fails, also due to -mcmodel=medium

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> I have to admit that I am unsure whether it is valid or not.

I share the same feeling, but if

  use m, only: A => X
  use m, only: B => X

is valid, I don't see why

  use m, only: A => X
  use m, only: A => X

should not.

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #2 from howarth at bromo dot med.uc.edu ---
pr63793 also is -mcmodel=medium bug on darwin which is detected by the linker.

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Another sequel of r216154.

Note that tests with -mcmodel=* are compiled on darwin, but produce codes that
are not accepted by as (see also pr50077).

[Bug middle-end/63879] ICE compiling Linux Kernel fs/ext3/namei.c

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Sasha Levin from comment #4)
> $ gcc -v

Please add "-v" to the gcc command line used to compile fs/ext3/namei.c
and show the whole output.

[Bug lto/63894] New: [5 Regression] ICE in inline_call, at ipa-inline-transform.c:339 building Firefox

[trippels at gcc dot gnu.org]

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

Bug ID: 63894
   Summary: [5 Regression] ICE in inline_call, at
ipa-inline-transform.c:339 building Firefox
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

Executing: ../../../../gcc_test/usr/local/bin/c++ -o js -Wall
-Wignored-qualifiers -Wsign-compare -Wtype-limits -Werror=char-subscripts
-Werror=comment -Werror=empty-body -Werror=endif-labels
-Werror=int-to-pointer-cast -Werror=missing-braces -Werror=overloaded-virtual
-Werror=pointer-arith -Werror=reorder -Werror=return-type
-Werror=sequence-point -Werror=switch -Werror=trigraphs -Werror=unknown-pragmas
-Werror=unused-label -Werror=unused-value -Werror=write-strings
-Werror=conversion-null -Wno-invalid-offsetof -Wcast-align -flto=64 --param
lto-partitions=64 -mcpu=power7 -fno-semantic-interposition -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread
-pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer
/home/trippels/moz-build-dir/js/src/shell/tmpKUuVPB.list -lpthread
-Wl,--hash-style=gnu,--as-needed,--gc-sections,--icf=all -Wl,-z,noexecstack
-Wl,-z,text -Wl,--build-id -Wl,-rpath-link,../../../dist/bin
-Wl,-rpath-link,/home/trippels/moz-build-dir/dist/lib ../libjs_static.a
-rdynamic ../../../nsprpub/lib/ds/libplds4.so
../../../nsprpub/lib/libc/src/libplc4.so ../../../nsprpub/pr/src/libnspr4.so
-lm -ldl -lffi -lz -lm -ldl
/home/trippels/moz-build-dir/js/src/shell/tmpKUuVPB.list:
INPUT("OSObject.o")
INPUT("js.o")
INPUT("jsheaptools.o")
INPUT("jsoptparse.o")
INPUT("../editline/editline.o")
INPUT("../editline/sysunix.o")
INPUT("../../../mozglue/build/dummy.o")
INPUT("../../../mfbt/Compression.o")
INPUT("../../../mfbt/Decimal.o")
INPUT("../../../mfbt/FloatingPoint.o")
INPUT("../../../mfbt/HashFunctions.o")
INPUT("../../../mfbt/JSONWriter.o")
INPUT("../../../mfbt/Poison.o")
INPUT("../../../mfbt/SHA1.o")
INPUT("../../../mfbt/TaggedAnonymousMemory.o")
INPUT("../../../mfbt/bignum-dtoa.o")
INPUT("../../../mfbt/bignum.o")
INPUT("../../../mfbt/cached-powers.o")
INPUT("../../../mfbt/diy-fp.o")
INPUT("../../../mfbt/double-conversion.o")
INPUT("../../../mfbt/fast-dtoa.o")
INPUT("../../../mfbt/fixed-dtoa.o")
INPUT("../../../mfbt/strtod.o")
INPUT("../../../mfbt/unused.o")

lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:339
0x10d422df inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc/gcc/ipa-inline-transform.c:334
0x10d3b9d7 inline_small_functions
../../gcc/gcc/ipa-inline.c:1827
0x10d3b9d7 ipa_inline
../../gcc/gcc/ipa-inline.c:2198
0x10d3b9d7 execute
../../gcc/gcc/ipa-inline.c:2568
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: ../../../../gcc_test/usr/local/bin/c++ returned 1
exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [js] Error 1

adding -r -nostdlib to the invocation triggers another ICE:

lto1: internal compiler error: in update_visibility_by_resolution_info, at
ipa-visibility.c:427

(gdb) l
422  next != node; next = next->same_comdat_group)
423   gcc_assert (!next->externally_visible
424   || define == (next->resolution ==
LDPR_PREVAILING_DEF_IRONLY
425 || next->resolution ==
LDPR_PREVAILING_DEF
426 || next->resolution == LDPR_UNDEF
427 || next->resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP));
428
429   if (node->same_comdat_group)
430 for (symtab_node *next = node->same_comdat_group;
431  next != node; next = next->same_comdat_group)
(gdb) p next->externally_visible
$1 = 1
(gdb) p define
$2 = true
(gdb) p next->resolution
$3 = LDPR_PREVAILING_DEF

I will try to reduce this issue.

[Bug middle-end/63879] ICE compiling Linux Kernel fs/ext3/namei.c

[sasha.levin at oracle dot com]

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

--- Comment #6 from Sasha Levin  ---
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/sasha/gcc-inst/ --with-arch=native
--with-tune=native --enable-languages=c --enable-lto --enable-gold
--enable-stage1-languages=c
Thread model: posix
gcc version 5.0.0 20141114 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-nostdinc' '-isystem'
'/home/sasha/gcc-inst/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include' '-I'
'./arch/x86/include' '-I' 'arch/x86/include/generated
' '-I' 'include' '-I' './arch/x86/include/uapi' '-I'
'arch/x86/include/generated/uapi' '-I' './include/uapi' '-I'
'include/generated/uapi' '-include' './include/linux/kconfig.h
' '-D' '__KERNEL__' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wno-trigraphs'
'-fno-strict-aliasing' '-fno-common' '-Werror=implicit-function-declaration'
'-Wno-format-security'
 '-std=gnu90' '-m64' '-mno-80387' '-mno-fp-ret-in-387' '-march=native'
'-mno-red-zone' '-mcmodel=kernel' '-funit-at-a-time'
'-maccumulate-outgoing-args' '-D' 'CONFIG_X86_X32_AB
I' '-D' 'CONFIG_AS_CFI=1' '-D' 'CONFIG_AS_CFI_SIGNAL_FRAME=1' '-D'
'CONFIG_AS_CFI_SECTIONS=1' '-D' 'CONFIG_AS_FXSAVEQ=1' '-D' 'CONFIG_AS_CRC32=1'
'-D' 'CONFIG_AS_AVX=1' '-D' 'C
ONFIG_AS_AVX2=1' '-pipe' '-Wno-sign-compare' '-fno-asynchronous-unwind-tables'
'-mno-sse' '-mno-mmx' '-mno-sse2' '-mno-3dnow' '-mno-avx'
'-fno-delete-null-pointer-checks' '-O2'
 '--param' 'allow-store-data-races=0' '-fno-reorder-blocks' '-fno-ipa-cp-clone'
'-fno-partial-inlining' '-Wframe-larger-than=2048' '-fstack-protector'
'-Wno-unused-but-set-vari
able' '-fno-omit-frame-pointer' '-fno-optimize-sibling-calls'
'-fno-var-tracking-assignments' '-g' '-gdwarf-4' '-pg' '-mfentry' '-D'
'CC_USING_FENTRY' '-Wdeclaration-after-stat
ement' '-Wno-pointer-sign' '-fno-strict-overflow' '-fconserve-stack'
'-Werror=implicit-int' '-Werror=strict-prototypes' '-Werror=date-time' '-D'
'CC_HAVE_ASM_GOTO' '-fsanitize=
kernel-address' '-fasan-shadow-offset=0xdfffe900' '--param'
'asan-instrumentation-with-call-threshold=1' '-fsanitize=undefined'
'-fno-sanitize=unreachable' '-fno-sa
nitize=float-cast-overflow' '-D' 'KBUILD_STR(s)=#s' '-D'
'KBUILD_BASENAME=KBUILD_STR(namei)' '-D' 'KBUILD_MODNAME=KBUILD_STR(ext3)' '-c'
'-o' 'fs/ext3/.tmp_namei.o' 
 /home/sasha/gcc-inst/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1
-fpreprocessed fs/ext3/namei.i -march=nehalem -mmmx -mno-3dnow -msse -msse2
-msse3 -mssse3 -mno-sse4a -mcx1
6 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2
-msse4.2 -msse4.1 -mno-l
zcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed
-mno-prfchw -  
mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=24576 -mtune=nehalem -quiet
-dumpbase namei.i -m64 -mno-80387 -mno-fp-ret-in-387 -mno-red-zone
-mcmodel=kernel -maccumulate-outgoing-args -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -mno-avx -mfentry -auxbase-strip fs/ext3/.tmp_namei.o -g -gdwarf-4
-O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror=implicit-function-declaration -Wno-format-security -Wno-sign-compare
-Wframe-larger-than=2048 -Wno-unused-but-set-variable
-Wdeclaration-after-statement -Wno-pointer-sign -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -std=gnu90 -version -p
-fno-strict-aliasing -fno-common -funit-at-a-time
-fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks
-fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fstack-protector
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -fno-strict-overflow -fconserve-stack
-fsanitize=kernel-address -fasan-shadow-offset=0xdfffe900
-fsanitize=undefined -fno-sanitize=unreachable
-fno-sanitize=float-cast-overflow --param allow-store-data-races=0 --param
asan-instrumentation-with-call-threshold=1 -o - | 
 as -v -I ./arch/x86/include -I arch/x86/include/generated -I include -I
./arch/x86/include/uapi -I arch/x86/include/generated/uapi -I ./include/uapi -I
include/generated/uapi --64 -o fs/ext3/.tmp_namei.o
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.24
GNU C (GCC) version 5.0.0 20141114 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141114 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 5.0.0 20141114 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141114 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-

[Bug rtl-optimization/63895] New: [5 Regression] r217588 miscompled 178.galgel from cpu2000

[hjl.tools at gmail dot com]

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

Bug ID: 63895
   Summary: [5 Regression] r217588 miscompled 178.galgel from
cpu2000
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com

On Linux/x86-64, r217588 miscompiled 178.galgel from cpu2000:

# gfortran -O3 -funroll-loops -ffast-math  -DSPEC_CPU2000_LP64 
...
0203: C1 = (  -0.3411,  0.2388)
  C1 = (   0.2181E+13, -0.3477E+12)
^
0206: Error in right eigenvector is   0.000
  Error in right eigenvector is   156.7
  ^
0249: D(Lambda)/D(Gr) = (   0.3254E-04,  0.6779E-04)
  D(Lambda)/D(Gr) = (  -0.4526E-13, -0.6501E-13)
 ^
0251:Calculated estimations of errors:
Error in BifGel: D(alpha)/D(Anu) = 0
   ^
0252: Error in calculation of Omega   =  0.000
BifGel: weakly nonlinear analysis failed
   ^
0253: Error in calculation of Amu2=  0.000
Error return from BifGel called by Cyklap: ier=  139
 ^
'galgel.out' short

[Bug lto/63894] [5 Regression] ICE in inline_call, at ipa-inline-transform.c:339 building Firefox

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  ---
> (gdb) p next->externally_visible
> $1 = 1
> (gdb) p define
> $2 = true
> (gdb) p next->resolution
> $3 = LDPR_PREVAILING_DEF
> 
> I will try to reduce this issue.

Thanks, the inline-transform ICE is result of Martin's ipa-cp devirtualization
changes.  There are quite few details that needs to be solved correctly, I have
some cleanups on queue to test and commit today.  Hopefully these will care
this (it also reproduces for me, the visibility ICE doesn't, but my tree is
old).
I also get ICE preprocessing one .S file.

Honza

[Bug target/63890] [4.9/5.0 regression] Compiling trivial program with -O -p leads to misaligned stack

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz, jh at 
suse dot cz

--- Comment #6 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #4)
> From archives on x86_64-apple-darwin10, the problem was already there at
> r203176.

yup - looks like 203171 or 203172.

Honza, all yours :)

[Bug c++/63896] New: g++.dg/ipa/devirt-7.C produces code that trips the darwin linker

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63896
   Summary: g++.dg/ipa/devirt-7.C produces code that trips the
darwin linker
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

g++.dg/ipa/devirt-7.C fails on x86_64-apple-darwin14: it generates code that
makes the darwin linker error out. Minimal reproducer is:


class Distraction
{
  virtual float bar ();
};

class A
{
public:
  virtual void foo ();
};

class B : Distraction, A
{
public:
  void __attribute__ ((noinline)) middleman () { foo(); }
};

void A::foo ()
{
}

extern int get_input ();

int main (void)
{
  class B b;

  for (int i = 0; i < get_input(); i++)
b.middleman();
}


Compiling it with "./bin/g++ -W -Wall -O3 devirt-7.C", the linker aborts
uglily:

0  0x10d4fcb51  __assert_rtn + 144
1  0x10d524c99 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3269
2  0x10d5080fd  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 375
3  0x10d54b8cd  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 705
4  0x10d54d7ec  ld::tool::InputFiles::parseWorkerThread() + 496
5  0x7fff89c5f2fc  _pthread_body + 131
6  0x7fff89c5f279  _pthread_body + 0
A linker snapshot was created at:
/tmp/a.out-2014-10-15-191218.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/SourceCache/ld64/ld64-241.9/src/ld/parsers/macho_relocatable_file.cpp, line
1745.
collect2: error: ld returned 1 exit status


Here is a diff between the assembler code emitted by gcc 4.9.2 (which doesn't
trigger the ld issue), and that of trunk gcc:

--- good.s2014-11-15 18:58:24.0 +0100
+++ bad.s2014-11-15 18:58:14.0 +0100
@@ -23,7 +23,6 @@ LHOTB1:
 .align 4,0x90
 __ZN1B9middlemanEv.constprop.0:
 LFB12:
-ret
 LFE12:
 .section __TEXT,__text_cold,regular,pure_instructions
 LCOLDE1:
@@ -37,19 +36,16 @@ LHOTB2:
 .globl _main
 _main:
 LFB2:
-pushq%rbx
+subq$24, %rsp
 LCFI0:
-xorl%ebx, %ebx
-jmpL4
-.align 4
-L5:
-addl$1, %ebx
-L4:
 call__Z9get_inputv
-cmpl%eax, %ebx
-jlL5
+testl%eax, %eax
+jleL4
+movq%rsp, %rdi
+call__ZN1B9middlemanEv.constprop.0
+L4:
 xorl%eax, %eax
-popq%rbx
+addq$24, %rsp
 LCFI1:
 ret
 LFE2:
@@ -63,14 +59,19 @@ __ZTS1A:
 .ascii "1A\0"
 .globl __ZTI1A
 .const_data
-.align 4
+.align 3
 __ZTI1A:
 .quad__ZTVN10__cxxabiv117__class_type_infoE+16
 .quad__ZTS1A
+.globl __ZTS1B
+.weak_definition __ZTS1B
+.section __TEXT,__const_coal,coalesced
+__ZTS1B:
+.ascii "1B\0"
 .globl __ZTI1B
 .weak_definition __ZTI1B
 .section __DATA,__const_coal,coalesced
-.align 5
+.align 3
 __ZTI1B:
 .quad__ZTVN10__cxxabiv121__vmi_class_type_infoE+16
 .quad__ZTS1B
@@ -80,15 +81,9 @@ __ZTI1B:
 .quad0
 .quad__ZTI1A
 .quad2048
-.globl __ZTS1B
-.weak_definition __ZTS1B
-.section __TEXT,__const_coal,coalesced
-__ZTS1B:
-.ascii "1B\0"
 .globl __ZTV1B
 .weak_definition __ZTV1B
-.section __DATA,__const_coal,coalesced
-.align 5
+.align 3
 __ZTV1B:
 .quad0
 .quad__ZTI1B
@@ -98,7 +93,7 @@ __ZTV1B:
 .quad__ZN1A3fooEv
 .globl __ZTV1A
 .const_data
-.align 4
+.align 3
 __ZTV1A:
 .quad0
 .quad__ZTI1A
@@ -158,9 +153,7 @@ LASFDE5:
 .set L$set$7,LCFI0-LFB2
 .long L$set$7
 .byte0xe
-.byte0x10
-.byte0x83
-.byte0x2
+.byte0x20
 .byte0x4
 .set L$set$8,LCFI1-LCFI0
 .long L$set$8

[Bug target/63896] g++.dg/ipa/devirt-7.C produces code that trips the darwin linker

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
  Component|c++ |target
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

[Bug target/60104] load not folded into indirect branch on x86-64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
(In reply to Francois-Xavier Coudert from comment #3)
> Testcase gcc.target/i386/sibcall-1.c fails on x86_64-apple-darwin14
> (compiled with "-O2 -m32"). Assembler code generated is:

It is expected since this testcase always fails with PIC in 32-bit.

[Bug rtl-optimization/63895] [5 Regression] r217588 miscompled 178.galgel from cpu2000

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It also miscompiled

 1x171.swim 1x176.gcc 1x178.galgel 1x253.perlbmk 1x301.apsi

from SPEC CPU 2000 on ia32 with

-m32 -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math

[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert  ---
(In reply to Jakub Jelinek from comment #6)
> Author: jakub
> Date: Mon Apr  8 13:46:00 2013
> New Revision: 197580

It appears that the fix doesn't work for darwin:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56906

[Bug target/56906] FAIL: g++.dg/opt/vt4.C -std=gnu++* scan-assembler-not _ZTV.A

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org
  Component|testsuite   |target

--- Comment #3 from Francois-Xavier Coudert  ---
Still present. Seems like the patch for PR50243 never actually worked on
darwin, because I get this failure with g++ 4.7.4, 4.8.3, 4.9.2 and trunk.

[Bug target/63896] [5 Regression] g++.dg/ipa/devirt-7.C produces code that trips the darwin linker

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|g++.dg/ipa/devirt-7.C   |[5 Regression]
   |produces code that trips|g++.dg/ipa/devirt-7.C
   |the darwin linker   |produces code that trips
   ||the darwin linker

--- Comment #1 from Dominique d'Humieres  ---
This appeared between r217559 (PASS) and r217602 (FAIL).

[Bug c++/63889] Ice with redundant static in class scope constexpr variable template.

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The code example looks invalid for several reasons, but the following is a
simplified example that is free of library dependencies and ICEs as well:

//-
template
struct A
{
  template
  static constexpr bool is_ok = true;

  template>
  A(T) { }
};

A p(42);
//-

For gcc 5.0.0 20141115 (experimental) using the flags

-Wall -Wextra -std=c++1y -pedantic 

I get:

"prog.cc:7:21: internal compiler error: in retrieve_specialization, at
cp/pt.c:1047 template> ^ 0x5d8a93 retrieve_specialization
/home/heads/gcc/gcc-source/gcc/cp/pt.c:1047 0x5e17de instantiate_template_1
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15821 0x5e17de
instantiate_template(tree_node*, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15915 0x6796c5
finish_template_variable(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/semantics.c:2454 0x6796c5
finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*, bool,
bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
/home/heads/gcc/gcc-source/gcc/cp/semantics.c:3551 0x628e4b
cp_parser_primary_expression /home/heads/gcc/gcc-source/gcc/cp/parser.c:4727
0x62c968 cp_parser_postfix_expression
/home/heads/gcc/gcc-source/gcc/cp/parser.c:6089 0x6343ed
cp_parser_unary_expression /home/heads/gcc/gcc-source/gcc/cp/parser.c:7370
0x6350e4 cp_parser_binary_expression
/home/heads/gcc/gcc-source/gcc/cp/parser.c:8104 0x63564f
cp_parser_assignment_expression /home/heads/gcc/gcc-source/gcc/cp/parser.c:8347
0x635ae5 cp_parser_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/parser.c:8593 0x63753a
cp_parser_default_argument /home/heads/gcc/gcc-source/gcc/cp/parser.c:19052
0x6314b9 cp_parser_parameter_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:18968 0x63d40b
cp_parser_template_parameter /home/heads/gcc/gcc-source/gcc/cp/parser.c:13289
0x63d40b cp_parser_template_parameter_list
/home/heads/gcc/gcc-source/gcc/cp/parser.c:13192 0x644991
cp_parser_template_declaration_after_export
/home/heads/gcc/gcc-source/gcc/cp/parser.c:23445 0x6468ae
cp_parser_member_declaration /home/heads/gcc/gcc-source/gcc/cp/parser.c:20601
0x62e53c cp_parser_member_specification_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:20528 0x62e53c
cp_parser_class_specifier_1 /home/heads/gcc/gcc-source/gcc/cp/parser.c:19720
0x62e53c cp_parser_class_specifier
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19956 Please submit a full bug
report, with preprocessed source if appropriate. Please include the complete
backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for
instructions."

[Bug ada/63656] a-tags.adb:82:04: warning: types for unchecked conversion have different sizes

[arekm at maven dot pl]

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

Arkadiusz Miskiewicz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Arkadiusz Miskiewicz  ---
Invalid system.ads was used (sparc64 version) due to local broken patch (even
on x86_64).

[Bug target/60104] load not folded into indirect branch on x86-64

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sat Nov 15 19:46:14 2014
New Revision: 217611

URL: https://gcc.gnu.org/viewcvs?rev=217611&root=gcc&view=rev
Log:
PR target/60104
* gcc.target/i386/sibcall-1.c: Don't run on pic targets.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/sibcall-1.c

[Bug middle-end/63884] ICE: SIGSEGV in is_sec_implicit_index_fn with -fcilkplus and __builtin_sadd_overflow()

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sat Nov 15 20:20:05 2014
New Revision: 217612

URL: https://gcc.gnu.org/viewcvs?rev=217612&root=gcc&view=rev
Log:
PR middle-end/63884
c-family/
* array-notation-common.c (is_sec_implicit_index_fn): Return false
for NULL fndecl.
(extract_array_notation_exprs): Return for NULL node.
testsuite/
* c-c++-common/cilk-plus/AN/pr63884.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/pr63884.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/array-notation-common.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63884] ICE: SIGSEGV in is_sec_implicit_index_fn with -fcilkplus and __builtin_sadd_overflow()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug target/63897] New: [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 63897
   Summary: [5.0 regression] gcc.dg/torture/vector-2.c fails at on
x86_64-apple-darwin14
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Created attachment 33987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33987&action=edit
Assembler generated by "gcc -msse vector-2.c -O1 -m32 -S"

gcc.dg/torture/vector-2.c currently fails on trunk, when compiled with "-msse
vector-2.c -O1 -m32". Here is a minimal reproducer:


#define vector __attribute__((vector_size(16) ))

vector int f0(vector int t)
{
 ((int*)&t)[0] = 1;
 return t;
}
vector int f1(vector int t)
{
 ((int*)&t)[1] = 1;
 return t;
}

int main(void)
{
  vector int a = {0, 0, 0, 0};
  vector int b = {1, 0, 0, 0};
  vector int c = {0, 1, 0, 0};
  vector int a0 = f0(a);
  if (__builtin_memcmp (&a0, &b, sizeof(a0)))
__builtin_abort ();
  a0 = f1(a);
  if (__builtin_memcmp (&a0, &c, sizeof(a0)))
__builtin_abort ();
  return 0;
}



When compiled with "gcc -msse vector-2.c -O1 -m32", this segfaults at runtime.
The backtrace is:

* thread #1: tid = 0xdc2a68, 0x1ea9 a.out`main + 81, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xb0)
frame #0: 0x1ea9 a.out`main + 81
a.out`main + 81:
-> 0x1ea9:  movd   0xb0(%eax), %xmm0
   0x1eb1:  pshufd $-0x1f, %xmm0, %xmm0
   0x1eb6:  movaps %xmm0, 0x10(%esp)
   0x1ebb:  subl   $0x4, %esp

The assembler generated is attached.

[Bug target/63897] [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-15
   Host||x86_64-apple-darwin14
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin14

[Bug target/63897] [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
I don't see it on my builds.

[Book15] f90/bug% gcc410 -msse -O1 -m32
/opt/gcc/work/gcc/testsuite/gcc.dg/torture/vector-2.c
[Book15] f90/bug% a.out 
[Book15] f90/bug% gcc410 -msse -O1 -m32 pr63897.c
[Book15] f90/bug% a.out 
[Book15] f90/bug% gcc410 -v
Using built-in specs.
COLLECT_GCC=gcc410
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.10w/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/lto-wrapper
Target: x86_64-apple-darwin14.0.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc4.10w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7
Thread model: posix
gcc version 5.0.0 20141115 (experimental) [trunk revision 217602p25] (GCC)

[Bug target/63897] [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert  ---
(In reply to Dominique d'Humieres from comment #1)
> Configured with: ../work/configure --prefix=/opt/gcc/gcc4.10w
> --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto
> --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto
> --enable-plugin --with-arch=corei7 --with-cpu=corei7

Apparently, it's because you configure --with-arch=corei7. If I compile with
-march=corei7, it generates good code (well, it doesn't segfault, at least).
Try compiling with -march=core2, you should see it.

[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction

[ztong at vt dot edu]

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

Tong Zhang  changed:

   What|Removed |Added

 CC||ztong at vt dot edu

--- Comment #5 from Tong Zhang  ---
I am able to reproduce the bug. It affects 4.7.2, 4.7.3 and 4.8.3 on various of
systems(tested on gentoo and debian).

[Bug target/63897] [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Try compiling with -march=core2, you should see it.

Confirmed.

[Bug tree-optimization/63898] New: [5 Regression] r217560 caused segfault building 462.libquantum from cpu2006

[hjl.tools at gmail dot com]

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

Bug ID: 63898
   Summary: [5 Regression] r217560 caused segfault building
462.libquantum from cpu2006
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de

On Linux/x86-64, r217560 caused:

gcc -c -o measure.o -DSPEC_CPU -DNDEBUG   -O2 -ffast-math -fwhole-program
-flto=jobserver -fuse-linker-plugin   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
  measure.c
gcc: internal compiler error: Segmentation fault (program cc1)
0x40c2ec execute
../../src-trunk/gcc/gcc.c:2912
0x40c5d9 do_spec_1
../../src-trunk/gcc/gcc.c:4837
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
0x40d167 do_spec_1
../../src-trunk/gcc/gcc.c:5491
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
0x40d167 do_spec_1
../../src-trunk/gcc/gcc.c:5491
0x40ca63 do_spec_1
../../src-trunk/gcc/gcc.c:5606
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
0x40d167 do_spec_1
../../src-trunk/gcc/gcc.c:5491
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
0x40d167 do_spec_1
../../src-trunk/gcc/gcc.c:5491
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
0x40d167 do_spec_1
../../src-trunk/gcc/gcc.c:5491
0x40f07b process_brace_body
../../src-trunk/gcc/gcc.c:6120
0x40f07b handle_braces
../../src-trunk/gcc/gcc.c:6034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake[3]: *** [measure.o] Error 4

[Bug target/63897] [5.0 regression] gcc.dg/torture/vector-2.c fails at on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
This due to r216154.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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

Anthony Brandon  changed:

   What|Removed |Added

 CC||anthony.brandon at gmail dot 
com

--- Comment #24 from Anthony Brandon  ---
Hi,

> It could be done specifically for uses in mem-initializers by walking the
> initializer in perform_mem_init to look for any references to members that
> haven't been marked yet.

I've been working on this using this approach.
At the moment I can detect and give a warning for something like:

struct S 
{ 
int i, j; 
S() : i(j), j(1) {} 
}; 

However it doesn't cover cases like i(j+1), and in the case of i(i) there would
currently be two warnings (due to -Winit-self).
Lastly, the warning is given like so:
a.cpp:8:2: warning: ‘S::i’ is initialized with uninitialized field ‘S::j’
[-Wuninitialized]
  S() : i(j), j(b) {}
  ^

So I have a couple of questions:
* How to get the right location for the mark. In other words:
  S() : i(j), j(b) {}
  ^
* Is there a function to traverse a tree structure looking for a particular
tree (or some other way to get things like i(j+1) to work)?

* Should this give a warning in the case of i(i)?

[Bug tree-optimization/63898] [5 Regression] r217560 caused segfault building 462.libquantum from cpu2006

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Where is the testcase?

[Bug testsuite/63899] New: WARNING: Could not compile g++.dg/compat/struct-layout-1 generator

[richard at netbsd dot org]

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

Bug ID: 63899
   Summary: WARNING: Could not compile
g++.dg/compat/struct-layout-1 generator
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard at netbsd dot org

Created attachment 33988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33988&action=edit
g++.dg/compat/struct-layout-1 run output

Never noticed this with 4.8.x, but with 4.9.2 the testsuite has some new
warnings of the sort:
>WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
and
>WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

Is this something to be concerned about? I attach the gcc and g++ individual
test run details.

[Bug testsuite/63899] WARNING: Could not compile g++.dg/compat/struct-layout-1 generator

[richard at netbsd dot org]

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

--- Comment #1 from Richard PALO  ---
Created attachment 33989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33989&action=edit
gcc.dg/compat/struct-layout-1 run output

[Bug tree-optimization/63898] [5 Regression] r217560 caused segfault building 462.libquantum from cpu2006

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 33990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33990&action=edit
A testcase

 ./xgcc -B./ -O2  -ffast-math-S /tmp/pr63898.i 
xgcc: internal compiler error: Segmentation fault (program cc1)
0x405c1f execute
/export/gnu/import/git/gcc/gcc/gcc.c:2912
0x409b0a do_spec(char const*)
/export/gnu/import/git/gcc/gcc/gcc.c:4518
0x411bca driver::do_spec_on_infiles() const
/export/gnu/import/git/gcc/gcc/gcc.c:7674
0x40f587 driver::main(int, char**)
/export/gnu/import/git/gcc/gcc/gcc.c:6911
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/63898] [5 Regression] r217560 caused segfault building 462.libquantum from cpu2006

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
We get an infinite recursive call:

#0  fold_binary_loc (loc=0, code=RDIV_EXPR, type=0x77df2d20, 
op0=0x77c544c0, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9649
#1  0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54460, op1=0x77c54160)
at generic-match.c:6547
#2  0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54460, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#3  0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54400, op1=0x77c54160)
at generic-match.c:6547
#4  0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54400, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#5  0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c543a0, op1=0x77c54160)
at generic-match.c:6547
#6  0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c543a0, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#7  0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54340, op1=0x77c54160)
---Type  to continue, or q  to quit---
at generic-match.c:6547
#8  0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54340, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#9  0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c542e0, op1=0x77c54160)
at generic-match.c:6547
#10 0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c542e0, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#11 0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54280, op1=0x77c54160)
at generic-match.c:6547
#12 0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54280, op1=0x77c54160)
at /export/gnu/import/git/gcc/gcc/fold-const.c:9729
#13 0x00a81ecd in generic_simplify (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54220, op1=0x77c54160)
at generic-match.c:6547
#14 0x0094f8c4 in fold_binary_loc (loc=0, code=RDIV_EXPR, 
type=0x77df2d20, op0=0x77c54220, op1=0x77c54160)

until we ran out of stack.

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

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

--- Comment #10 from Janne Blomqvist  ---
Author: jb
Date: Sun Nov 16 01:56:54 2014
New Revision: 217623

URL: https://gcc.gnu.org/viewcvs?rev=217623&root=gcc&view=rev
Log:
PR 60324 VLA related fixes to random number generator.

2014-11-16  Janne Blomqvist  

PR libfortran/60324
* intrinsics/random.c (kiss_size): Rename to KISS_SIZE, make it a
macro instead of a variable.
(random_seed_i4): Make seed correct size, remove assert, KISS_SIZE
related changes.
(random_seed_i8): KISS_SIZE related changes.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/random.c

[Bug inline-asm/63900] New: memory constrains needlessly doing memory clobber

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 63900
   Summary: memory constrains needlessly doing memory clobber
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Using a constraint like this:

   "=m" ( *(struct { char __x[BUFSIZE]; } *)b)

only works for very specific sizes of BUFSIZE (1, 2, 4, 8, 16).  All other
sizes (3, 12, 1000, etc) cause gcc to (silently) fall back to doing a full
memory clobber.

-
#include 

#define MYSIZE 8

inline void 
__stosb(unsigned char *Dest, unsigned char Data, size_t Count)
{
   struct _reallybigstruct { char x[MYSIZE]; } 
  *p = (struct _reallybigstruct *)Dest;

   __asm__ __volatile__ ("rep stosb"
  : "+D" (Dest), "+c" (Count), "=m" (*p)
  : [Data] "a" (Data)
  //: "memory"
   );
}

int main()
{
   unsigned char buff[100], buff2[100];

   buff[5] = 'A';
   buff2[5] = 'M';
   asm("#" : : "r" (buff2));

   __stosb(buff, 'B', sizeof(buff));
   printf("%c %c\n", buff[5], buff2[5]);
}
-

Compile this (4.9.0 x86_64-win32-seh-rev2, using -m64 -O2) with MYSIZE 8 and
look at the -S output.  If this is NOT doing a full clobber, gcc should be able
to just print buff2[5] by moving 77 into r8d before calling printf (which it
does).

Change MYSIZE to 3 (or 12, 1000, 0xfff, etc) we see the value getting read
from memory before calling printf, indicating the asm performed a full clobber
(affecting buff2) instead of just clobbering buff as was intended.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
(In reply to David from comment #0)
> Change MYSIZE to 3 (or 12, 1000, 0xfff, etc) we see the value getting
> read from memory before calling printf, indicating the asm performed a full
> clobber (affecting buff2) instead of just clobbering buff as was intended.

So that is just an optimization anyways.  So closing as invalid.

[Bug target/54272] [SH] Add support for addv / subv instructions

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Recently some __builtin_*_overflow functions have been added, of which some
could utilize the addv and subv instructions.  See also
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Michael Karcher from comment #3)
> Created attachment 33954 [details]
> Remove assumption that "not" is logical negate
> 
> Indeed the treg combine pass is broken. Thanks to the nicely documented
> code, it could easily be determined, that this optimization pass contains
> the wrong assumption that "not" is an assembler instruction that can be used
> for logical negation of a register. As this is a bitwise negate instruction,
> it can not be used that way.

I'm not sure about this.  The first hunk of your patch that removes the example
in the top comment block should be valid, as far as I can see at the moment. 
This is because the result of the bitwise not is then again tested for zero
before the conditional jump.
I haven't looked at the details (RTL dumps etc), but looking at the problematic
code in the description, the problem could be that the variable 'condition'
gets the wrong value assigned.  'condition' should have a value of either 0 or
1.  But the sh_treg_combine pass changes the value.  If the conditional jump is
eliminated and the 'condition' value is then added to 'truecount' directly, it
will produce wrong values. 

> As I was unable to find a machine instruction that performs logical
> negation, I prepared a patch that completely removes the parts that rely on
> a logical negate instruction, while keeping all other aspects on the
> optimization pass intact.

Thanks for the patch.  Before completely eliminating the bitwise not insn, I'd
like to do some further analysis and try to keep the bitwise not except for
cases, where it would change the code semantics.

[Bug target/63901] New: msp430 multilib must distinguish mhwmult

[pab at pabigot dot com]

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

Bug ID: 63901
   Summary: msp430 multilib must distinguish mhwmult
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pab at pabigot dot com

The msp430 target has an option -mhwmult that is used to select among emulated
and hardware-assisted multiplication capabilities.  Because this option does
not contribute to the selection of multilib an application built for
-mhwmult=f5series linking with newlib will reference a strtoul implementation
that is built for a default -mhwmult=16.  Since the 16-bit multiply peripheral
does not exist on an F5 series MCU, the processor will fault.