[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[dougmencken at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554

Douglas Mencken  changed:

   What|Removed |Added

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

--- Comment #6 from Douglas Mencken  ---
As for 4.8.0 release and current 4.9.0-pre, there are no issues with linking to
libgcc_s on bootstrap stages 1-3 on my side.
Problem is gone.

[Bug libgcc/57256] Building for arm-elf with CFLAGS_FOR_TARGET=-mabi=aapcs-linux fails in libgcc/crtstuff.c

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57256

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Earnshaw  ---
arm-elf is an obsolete target (deleted in 4.8).  It was never expected that
AAPCS features would work with that target.  Sorry, this is not going to be
fixed.

[Bug libstdc++/57270] std::is_function ignores function ref-qualifiers

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57270

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
I agree with that. And shortly after that we will hit the problem mentioned in 

http://cplusplus.github.io/LWG/lwg-active.html#2101

[Bug bootstrap/57266] [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266

--- Comment #3 from Mikael Pettersson  ---
My m68k bootstrap has now recompiled fold-const.c + your patch three times
without warnings or errors.  Thanks for the quick fix.

[Bug target/57261] [4.9 regression] libgcc_s.so always linked on Solaris

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57261

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-05/msg00698.htm
   ||l
 Resolution|--- |FIXED

--- Comment #3 from Rainer Orth  ---
Fixed for 4.9.0.  Sorry for the mess.

  Rainer

[Bug libgcc/57256] Building for arm-elf with CFLAGS_FOR_TARGET=-mabi=aapcs-linux fails in libgcc/crtstuff.c

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57256

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
you do mean wontfix don't you ?

[Bug gcov-profile/57269] [4.7 Regression] ICE in gcov_open, at gcov-io.c:82

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57269

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-14
  Known to work||4.6.4, 4.8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.7.4
Summary|ICE in gcov_open, at|[4.7 Regression] ICE in
   |gcov-io.c:82|gcov_open, at gcov-io.c:82
 Ever confirmed|0   |1
  Known to fail||4.7.2

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

2012-06-30  Nathan Sidwell  

...
(coverage_init): Initialize bbg_file_stamp.  Read counts file
before writing graph header.
...

fixed it for 4.8.

[Bug rtl-optimization/57268] [4.9 Regression] c nested loops hang compiler in sched-deps.c

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-14
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |4.9.0
Summary|c nested loops hang |[4.9 Regression] c nested
   |compiler|loops hang compiler in
   ||sched-deps.c
 Ever confirmed|0   |1

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

(gdb) 
Run till exit from #0  sched_analyze (deps=0x7fff881eecc0, 
head=0x7fc27676ec18, tail=0x7fc2767b3168)
at /space/rguenther/src/svn/trunk/gcc/sched-deps.c:3734


while processing func_62 at -O2.

[Bug lto/57267] [4.9 regression] -flto-partition=none : symbol is already defined

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug bootstrap/57266] [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug middle-end/57235] [4.9 Regression] ICE verify_ssa failied

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57235

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue May 14 08:41:14 2013
New Revision: 198863

URL: http://gcc.gnu.org/viewcvs?rev=198863&root=gcc&view=rev
Log:
2013-05-14  Richard Biener  

PR middle-end/57235
* tree-eh.c (sink_clobbers): Give up for successors with
multiple predecessors and no virtual uses.

* g++.dg/torture/pr57235.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr57235.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug gcov-profile/57269] [4.7 Regression] ICE in gcov_open, at gcov-io.c:82

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57269

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue May 14 10:49:28 2013
New Revision: 198875

URL: http://gcc.gnu.org/viewcvs?rev=198875&root=gcc&view=rev
Log:
2013-05-14  Richard Biener  

PR gcov-profile/57269
Backport from mainline
2012-06-30  Nathan Sidwell  

* coverage.c (coverage_init): Read counts file before writing
graph header.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/coverage.c

[Bug c++/57271] New: ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[java4ada at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

Bug ID: 57271
   Summary: ARM: gcc generates insufficient alignment for memory
passed as extra argument for function return large
composite type
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: java4ada at yahoo dot com

Created attachment 30109
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30109&action=edit
Testcase and output

Please find enclosed input Vector4.ii and Vector4.s compiled with "./xgcc -fpic
 -mfloat-abi=softfp -mthumb -Os -march=armv7-a -mfpu=neon -S Vector4.ii".

Because function initVector4() returns instance of Vector4 16-byte in size, GCC
passes internal memory buffer as the first argument to hold the return value. 
This is shown in Vector4.s line#54 "add r0,sp,#8", and the buffer is filled at
line#33 "vst1.64 {d16-d17}, [r0:128]".  The 128-bit alignment hint is due to
the fact that class Vector4 is declared to be 16-byte aligned.  Problem is, r0
may not be aligned to 16-byte if sp is 16-byte aligned, which results in crash
at vst1.64 [:128].  It seems that GCC doesn't honor the alignment of internal
memory buffer.

If Vector4 is declared to be 32-byte align, GCC generates extra code to ensure
r0 is properly aligned.  I assume GCC should do it as low as 16-byte too.

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-05-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
What does the ABI say about incoming stack alignment?  What target did you
configure for?

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[java4ada at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

--- Comment #2 from java4ada at yahoo dot com ---
I don't know if ABI dictates it but from observation the stack is aligned to
8-byte for the largest primitive type "double" (or long long). 

I configure it on Ubuntu 12.04 64-bit with the following:

 ~/m/gcc/gcc-4.8/configure \
--prefix=/tmp/gcc/prefix --target=arm-linux-androideabi
--host=x86_64-linux-gnu --build=x86_64-linux-gnu \
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ \
--with-gmp=/tmp/gcc/temp-install \
--with-mpfr=/tmp/gcc/temp-install \
--with-mpc=/tmp/gcc/temp-install \
--with-cloog=/tmp/gcc/temp-install \
--with-isl=/tmp/gcc/temp-install \
--with-ppl=/tmp/gcc/temp-install \
--disable-ppl-version-check --disable-cloog-version-check
--disable-isl-version-check \
--enable-cloog-backend=isl \
--with-host-libstdcxx="-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm"
\
--disable-libssp \
--enable-threads \
--disable-libmudflap --disable-libstdc__-v3 --disable-sjlj-exceptions
--disable-shared \
--disable-tls --disable-libitm --disable-nls --disable-bootstrap
--disable-libquadmath --disable-libsanitizer \
--with-float=soft --with-fpu=vfp --with-arch=armv5te \
--enable-target-optspace --enable-initfini-array \
--with-sysroot=/tmp/gcc/prefix/sysroot \
--enable-plugins --enable-libgomp \
--enable-gold=default

[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067

--- Comment #5 from Richard Biener  ---
The RTL except.c:can_nonlocal_goto () function does not consider setjmp.
Does

Index: gcc/except.c
===
--- gcc/except.c(revision 198867)
+++ gcc/except.c(working copy)
@@ -1936,7 +1936,9 @@ insn_nothrow_p (const_rtx insn)
 bool
 can_nonlocal_goto (const_rtx insn)
 {
-  if (nonlocal_goto_handler_labels && CALL_P (insn))
+  if ((nonlocal_goto_handler_labels
+   || cfun->calls_stjmp)
+  && CALL_P (insn))
 {
   rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
   if (!note || INTVAL (XEXP (note, 0)) != INT_MIN)

fix it?

For retaining edges we have to teach find_many_sub_basic_blocks to treat
abnormal outgoing edges similar to EH outgoing edges - they have to be
re-directed from the block ending in the actual call (and made
EDGE_ABNORMAL_CALL which doesn't exist on the GIMPLE CFG).

Also

  if ((e->flags & EDGE_ABNORMAL)
  && !(e->flags & EDGE_SIBCALL))
remove_edge (e);

will happily remove an EDGE_FALLTHRU|EDGE_ABNORMAL edge.

[Bug libstdc++/57272] New: node-based containers don't use allocator's pointer type internally

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272

Bug ID: 57272
   Summary: node-based containers don't use allocator's pointer
type internally
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: redi at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

Container nodes are linked together by built-in pointers, but they should use
the allocator's pointer type instead. Currently I think only std::vector does
this correctly.

This is quite an invasive change and not worth implementing until C++11
allocators are supported, which is only true of forward_list and unordered
containers so far.

I have a patch in progress for forward_list.   The change requires replacing
every _Node* with a _Node_ptr typedef and then using indirection through
std::pointer_traits to convert between e.g. _Node_ptr and _Node_base_ptr.
I need to do some measurement to see if the indirection has a cost and if so
then use partial specialization to avoid all the indirections when the pointer
is a built-in type.

[Bug other/56780] --disable-install-libiberty still installs libiberty.a

[matthew at linuxfromscratch dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780

--- Comment #3 from Matthew Burgess  ---
(In reply to Jonathan Wakely from comment #2)

> I suggest pinging the gcc-patches list about your patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00167.html and CC Ian as he is
> a maintainer for libiberty and he agreed on the gcc list that this is a bug.

Thanks for the reminder, Jonathan.  Pinged yesterday, including Ian on the CC
list.  The archived email is at
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00664.html.

[Bug tree-optimization/55761] process_assignment assumes -1 can be created

[pa...@matos-sorge.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761

Paulo J. Matos  changed:

   What|Removed |Added

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

--- Comment #9 from Paulo J. Matos  ---
Mark Glisse has submitted the patch for this to HEAD. I guess we can now
comfortably close the report.

[Bug tree-optimization/55761] process_assignment assumes -1 can be created

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761

--- Comment #10 from Marc Glisse  ---
Oups, I didn't notice you had already worked on this. Please don't hesitate to
post (and ping) your patch to gcc-patches next time. Also, I didn't touch
tree-tailcall.c, that might still be needed...

[Bug tree-optimization/55761] process_assignment assumes -1 can be created

[pa...@matos-sorge.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761

--- Comment #11 from Paulo J. Matos  ---
No worries Marc, that's fine. The most important thing is that's fixed. I did
post the patch to patches@ but haven't actually pinged. I tend to forget about
them myself.

Thanks for sorting it out.

[Bug tree-optimization/55761] process_assignment assumes -1 can be created

[pa...@matos-sorge.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761

--- Comment #12 from Paulo J. Matos  ---
Also, I haven't touched tree-tailcall.c on my patches but I can't see why you
would need to do it.

[Bug libstdc++/57273] New: stringstream str initialization fails

[ycollette.nospam at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

Bug ID: 57273
   Summary: stringstream str initialization fails
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ycollette.nospam at free dot fr

It tried to initialize the content of a stringstream using the following code:

std::stringstream tmpLabel;

tmpLabel.str("test ");
tmpLabel << 1;

And the result fails. I've got on screen: '1est' instead of 'test 1'.

The workaround:

std::stringstream tmpLabel;

tmpLabel.str("");
tmpLabel << "test " << 1;

Here is a test file:

#include 
#include 

int main()
{
std::stringstream tmp;

tmp.str("test\0");

tmp << 1;

std::cout << "result = |" << tmp.str() << "|" << std::endl;

tmp.str("");

tmp << "test " << 1;

std::cout << "result = |" << tmp.str() << "|" << std::endl;

return 0;
}

[Bug libstdc++/57273] stringstream str initialization fails

[ycollette.nospam at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

collette  changed:

   What|Removed |Added

Version|unknown |4.6.3

--- Comment #1 from collette  ---
I use mageia2 64 bits with gcc-4.6.3.

[Bug libstdc++/57273] stringstream str initialization fails

[ycollette.nospam at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

--- Comment #2 from collette  ---
Just tested with gcc-4.8.0 compiled from scratch and the bug is still here.

[Bug libstdc++/57273] stringstream str initialization fails

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
And this is not a bug, it's conforming behavior.

[Bug libstdc++/57273] stringstream str initialization fails

[ycollette.nospam at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

--- Comment #4 from collette  ---
Oups. OK, I just tested with intel c++ compiler and the behavior is the same.
Where is this behavior defined ?

[Bug libstdc++/57273] stringstream str initialization fails

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

--- Comment #5 from Jonathan Wakely  ---
[stringbuf.members]/3

[Bug gcov-profile/35568] missing gcov data spoils other files.

[david.claessens at bestsorting dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35568

David Claessens  changed:

   What|Removed |Added

 CC||david.claessens@bestsorting
   ||.com

--- Comment #4 from David Claessens  ---
This bug seems to regress a lot between versions

on my development station (Linux Mint 13):
$ gcov --version
gcov (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
$ gcov src/frames/framegrabcontroller.cpp --branch-counts
--branch-probabilities --preserve-paths --object-directory
build/intel-linux64/debug/intermediate/src/frames
build/intel-linux64/debug/intermediate/src/frames/framegrabcontroller.gcda:cannot
open data file, assuming not executed
File 'src/frames/framegrabcontroller.cpp'
Lines executed:0.00% of 78
Branches executed:0.00% of 270
Taken at least once:0.00% of 270
Calls executed:0.00% of 307
src/frames/framegrabcontroller.cpp:creating
'src#frames#framegrabcontroller.cpp.gcov'


on our jenkins server (Debian Testing):
$ gcov --version
gcov (Debian 4.7.2-5) 4.7.2
$ gcov src/frames/framegrabcontroller.cpp --branch-counts
--branch-probabilities --preserve-paths --object-directory
build/intel-linux64/debug/intermediate/src/frames
build/intel-linux64/debug/intermediate/src/frames/framegrabcontroller.gcda:cannot
open data file, assuming not executed
File 'src/frames/framegrabcontroller.cpp'
No executable lines
No branches
No calls
Removing 'src#frames#framegrabcontroller.cpp.gcov'

[Bug libstdc++/57273] stringstream str initialization fails

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

--- Comment #6 from Jonathan Wakely  ---
Which also explains that you can make the inserted characters append to the
buffer using std::ios::ate

e.g.
  std::stringstream tmpLabel(std::ios::ate|std::ios::out);

or using an ostringstream
  std::ostringstream tmpLabel(std::ios::out);

[Bug libstdc++/57273] stringstream str initialization fails

[ycollette.nospam at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57273

--- Comment #7 from collette  ---
Thanks for these informations. Sorry for the noise.

[Bug gcov-profile/57234] gcov 4.7.3 segfaults when reading Clang's .gc* files.

[magnus.reftel at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57234

--- Comment #3 from Magnus Reftel  ---
I understand that gcov has no reason to handle coverage files written by
anything other than its matching GCC version, but is a segfault a valid
response to reading a malformed input file?

[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line

[thutt at vmware dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264

--- Comment #7 from thutt at vmware dot com ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to thutt from comment #5)
> > 
> > Does the same error exist in the 4.8 branch, or any other forward moving
> > branch?
> 
> No, 4.8 and newer branches already contain the original patch.

Sorry to be a bother, but can you tell me if the issue was / is in the 4.4
branch?

[Bug c++/53903] [C++11] Incompatible exception-specification allowed if member explicitly-defaulted after first declaration

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53903

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|4.7.1   |4.9.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #1 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264

--- Comment #8 from Uroš Bizjak  ---
(In reply to thutt from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > (In reply to thutt from comment #5)
> > > 
> > > Does the same error exist in the 4.8 branch, or any other forward moving
> > > branch?
> > 
> > No, 4.8 and newer branches already contain the original patch.
> 
> Sorry to be a bother, but can you tell me if the issue was / is in the 4.4
> branch?

Yes, cld was removed in 4.3.0. Please see PR36079 that introduced -mcld.

[Bug c++/57274] New: [4.8/4.9 Regression] Bogus sequence-point warning in C++

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57274

Bug ID: 57274
   Summary: [4.8/4.9 Regression] Bogus sequence-point warning in
C++
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test case:


#include 

void fn (int *data) {
  write (1, data++, sizeof (*data));
}


Using trunk GCC:

gcc -c -Wall t.c && echo ok
ok

g++ -c -Wall t.c
t.c: In function ‘void fn(int*)’:
t.c:4:36: warning: operation on ‘data’ may be undefined [-Wsequence-point]
   write (1, data++, sizeof (*data));
^


sizeof(*data)  does *not* dereference data.

[Bug tree-optimization/57275] New: Error in data dependence analysis during gather vectorization

[andrey.turetskiy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

Bug ID: 57275
   Summary: Error in data dependence analysis during gather
vectorization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.turetskiy at gmail dot com
CC: kirill.yukhin at intel dot com

Created attachment 30110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30110&action=edit
Test showing the error

I've tried to compile this code for AVX2 with different optimization options:

 #include 
 #define N 1024

 float a[N], b[N], c[N];
 int k[N];

 __attribute__((noinline, noclone)) void
 f (void)
 {
   int i;
   for (i = 0; i < N; i++)
 {
   a[i] = b[k[i]];
   b[i] = c[i];
 }
 }

 int main ()
 {
   int i;

   for (i = 0; i < N; i++)
 {
   k[i] = i%2;
   b[i] = i;
   c[i] = 179;
 }

   f ();

   if (a[2] != 179 || a[3] != 179)
 printf("TEST FAILED\n\n");
   else
 printf("TEST PASSED\n\n");

   return 0;
 }

Results are different:

# ./gcc -mavx2 -O2 gather_test.c -o qqq.exe
# sde -- ./qqq.exe
TEST PASSED

# ./gcc -mavx2 -O3 gather_test.c -o www.exe
# sde -- ./www.exe
TEST FAILED

This bug have appeared because of error in data dependence analysis for
gathers. The loop in function f() has interleaving memory access, so it mustn't
be vectorized.
Before 4.9.0 it works correctly.

[Bug middle-end/57276] New: Waste work in cgraph_edge_brings_all_agg_vals_for_node()

[pchang9 at cs dot wisc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57276

Bug ID: 57276
   Summary: Waste work in
cgraph_edge_brings_all_agg_vals_for_node()
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pchang9 at cs dot wisc.edu

Created attachment 30111
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30111&action=edit
Suggested patch

The problem appears in version 4.9 and in revision 198887. I have attached
a one-line patch that fixes it.

In method "cgraph_edge_brings_all_agg_vals_for_node()" in ipa-cp.c, the
loop in 3210 should break immediately after "found" is set to "true".
All the iterations after "found" is set to "true" do not perform any
useful work, at best they just set "found" again to "true".

[Bug middle-end/57276] Waste work in cgraph_edge_brings_all_agg_vals_for_node()

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57276

--- Comment #1 from Paolo Carlini  ---
Note that normally patches go to gcc-patches.

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-14
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|Error in data dependence|[4.9 Regression] Error in
   |analysis during gather  |data dependence analysis
   |vectorization   |during gather vectorization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions

[dodji at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782

Dodji Seketeli  changed:

   What|Removed |Added

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

[Bug c++/55365] ICE in process_init_constructor_union, at cp/typeck2.c:1335

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55365

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 4.8.1.

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

[Bug c++/57041] [4.7/4.8/4.9 Regression] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57041

Jason Merrill  changed:

   What|Removed |Added

 CC||jasongross9+bugzilla@gmail.
   ||com

--- Comment #6 from Jason Merrill  ---
*** Bug 55365 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

--- Comment #2 from Richard Biener  ---
t.c:11: note: versioning for alias not supported for: can't determine
dependence between b[i_12] and b[_4]

this should cause vectorization to fail ... oops:

Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c   (revision 198867)
+++ tree-vect-data-refs.c   (working copy)
@@ -269,7 +269,7 @@ vect_analyze_data_ref_dependence (struct
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
 DR_REF (drb));
}
- return false;
+ return true;
}

   if (dump_enabled_p ())

should fix it.

[Bug middle-end/57276] Waste work in cgraph_edge_brings_all_agg_vals_for_node()

[pchang9 at cs dot wisc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57276

Po-Chun Chang  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug c++/57274] [4.8/4.9 Regression] Bogus sequence-point warning in C++

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57274

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-14
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 30112
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30112&action=edit
gcc49-pr57274.patch

Untested fix.

[Bug c++/57274] [4.8/4.9 Regression] Bogus sequence-point warning in C++

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57274

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |4.8.1
   Target Milestone|--- |4.8.1

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
There are two such spots in that function, not just one.

[Bug other/41400] unwind table not properly populated

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41400

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #4 from Kai Tietz  ---
This issue is fixed back atleast to gcc 4.7, so I close this bug as fixed.

[Bug rtl-optimization/57268] [4.9 Regression] c nested loops hang compiler in sched-deps.c

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is weird, I've tried to bisect it, r197678 still compiled it without
hanging, r197681 ICEd somewhere in lra-constraints.c, but if I rebuild
lra-constraints.o with -O0, it instead ICEs on frame reg uses during
final_scan_insns (i.e. LRA hasn't replaced the frame pointer with hard frame
pointer or stack pointer), r197696 still ICEs, r197700 hangs.
BTW, doing -da before it hangs, I'm seeing right in *.split4 dump REG_EQUIV
notes like:
(insn 20109 70 20110 19 (set (reg/f:DI 38 r9 [19927])
(plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10]))) 254 {*leadi}
 (expr_list:REG_EQUIV (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfff8]))
(nil)))
wonder if it isn't a bug that RA hasn't replaced the eliminable register in the
note with sp (or hfp).

[Bug rtl-optimization/56833] [4.9 Regression] Valid register is over written by reload pass

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56833

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #2 from Jorn Wolfgang Rennecke  ---
It's a postreload bug.

[Bug c++/37736] Problem with designated initializer and template

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37736

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org|
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Another Dup.

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

[Bug c++/57041] [4.7/4.8/4.9 Regression] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57041

Paolo Carlini  changed:

   What|Removed |Added

 CC||simartin at gcc dot gnu.org

--- Comment #7 from Paolo Carlini  ---
*** Bug 37736 has been marked as a duplicate of this bug. ***

[Bug c++/31952] parameters may be redeclared in a function try-block

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952

--- Comment #10 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #9)
> After Janis' patch (see Comment #6) in pushdecl_maybe_friend_1 we issue hard
> errors for some kinds of shadowings but not for others. For comparison,
> clang issues hard errors for all three testcases here, ICC warnings (like
> current GCC). If we wanted, I could tweak the parser to carefully
> do_pushlevel (sk_catch) and therefore change to errors only the specific
> shadowings at issue in this PR, but I'm also aiming for some consistency.

Well, the language requires diagnostics for some shadowings and not others, so
it makes sense for us to mirror that.  But we probably want permerror rather
than error.

[Bug c++/56998] [4.8 Regression] ICE in value_dependent_expression_p, at cp/pt.c:19598

[raphael.kubo.da.costa at intel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56998

--- Comment #3 from Raphael Kubo da Costa  ---
For reference, this was fixed in r198882:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=28038d26df63ee5755da90bb563db4097a9deec0

[Bug libgcc/57277] New: arm-unknown-linux-gnueabi: armv6 libgcc -march=armv6: not found

[Dominik.Bittner94 at web dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57277

Bug ID: 57277
   Summary: arm-unknown-linux-gnueabi: armv6 libgcc -march=armv6:
not found
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Dominik.Bittner94 at web dot de

Created attachment 30113
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30113&action=edit
The arm-unknown-linux-gnueabi/libgcc/config.log

I'm trying to compile a cross-compiler for armv6 so I added the
--with-arch=armv6 option, but the compilation fails on libgcc. I'm not sure if
I made a mistake befor compiling gcc or it is a bug. But I can not compile
libgcc.

---

configure:3587: 
/home/dominik/Entwicklung/android/temp-tools/src/gcc-build/./gcc/xgcc
-B/home/dominik/Entwicklung/android/temp-tools/src/gcc-build/./gcc/
-B/home/dominik/Entwicklung/android/temp-tools/data/develop//cross-tools/arm-unknown-linux-gnueabi/bin/
-B/home/dominik/Entwicklung/android/temp-tools/data/develop//cross-tools/arm-unknown-linux-gnueabi/lib/
-isystem
/home/dominik/Entwicklung/android/temp-tools/data/develop//cross-tools/arm-unknown-linux-gnueabi/include
-isystem
/home/dominik/Entwicklung/android/temp-tools/data/develop//cross-tools/arm-unknown-linux-gnueabi/sys-include
   -c -g -O2  conftest.c >&5
/home/dominik/Entwicklung/android/temp-tools/src/gcc-build/./gcc/as: 87: exec:
-march=armv6: not found
configure:3591: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3605: error: in
`/home/dominik/Entwicklung/android/temp-tools/src/gcc-build/arm-unknown-linux-gnueabi/libgcc':
configure:3608: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

[Bug libgcc/57277] arm-unknown-linux-gnueabi: armv6 libgcc -march=armv6: not found

[Dominik.Bittner94 at web dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57277

--- Comment #1 from Dominik Bittner  ---
Created attachment 30114
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30114&action=edit
The top config.log

[Bug libgcc/57277] arm-unknown-linux-gnueabi: armv6 libgcc -march=armv6: not found

[Dominik.Bittner94 at web dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57277

Dominik Bittner  changed:

   What|Removed |Added

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

--- Comment #2 from Dominik Bittner  ---
I do not know why, but after I deleted the gcc directory and the build
directory and tried to build gcc again it works. I does that before I post this
'bug' but there was the same error. But now i works for me..

[Bug c/57278] New: -fno-if-conversion and -fno-if-conversion2 do not work as intended

[shiwen.hu at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57278

Bug ID: 57278
   Summary: -fno-if-conversion and -fno-if-conversion2 do not work
as intended
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shiwen.hu at gmail dot com

Created attachment 30115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30115&action=edit
test code and binaries

I tried to use "-fno-if-conversion -fno-if-conversion2" in GCC 4.8.0 targeting
ARM cortex-a15 to replace predicated instructions with branches. However, the
compiled binaries still contain predicated instructions, disregarding whether
generating Thumb or ARM code. Attached are the source code and the two
binaries. Can someone look into the issue?

Below are the commands I used to compile the binaries:

FLAGS="-mfloat-abi=hard -static -static-libgcc -mcpu=cortex-a15
-mtune=cortex-a15 -mfpu=neon-vfpv4 -O3"

$CC $FLAGS -marm -fno-if-conversion -fno-if-conversion2 test_cond.c test_data.c
-o test_cond.a32.nocond.exe
$CC $FLAGS -mthumb -fno-if-conversion -fno-if-conversion2 test_cond.c
test_data.c -o test_cond.t32.nocond.exe

In another note, the code is not optimal in that two of the three sign
extensions in the main function assembly can be moved outside the main loop.

Thanks,

Shiwen

[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line

[thutt at vmware dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264

--- Comment #9 from thutt at vmware dot com ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to thutt from comment #7)
> > (In reply to Uroš Bizjak from comment #6)
> > > (In reply to thutt from comment #5)
> > > > 
> > > > Does the same error exist in the 4.8 branch, or any other forward moving
> > > > branch?
> > > 
> > > No, 4.8 and newer branches already contain the original patch.
> > 
> > Sorry to be a bother, but can you tell me if the issue was / is in the 4.4
> > branch?
> 
> Yes, cld was removed in 4.3.0. Please see PR36079 that introduced -mcld.

When the sample test program provided above was compiled with gcc 4.4, it did
not generate the stos instruction.  However, each of 4.5, 4.6 and 4.7 did
generate the stos instruction.

Given this, I'd like to clarify your answer.  If I may summarize:

  4.3.0 stopped using cld.
  After cld was not used, an error existed in versions 4.4, 4.5, 4.6 and 4.7.
  The error was fixed in 4.8.
  You have backported the fix from 4.8 to 4.7.
  You did not backport to 4.5 and 4.6 because they are closed.
  You do not state, but I infer that 4.4 is also closed.

Do you have an idea why the test case does not demonstrate the error on 4.4?
Is there a test case that will demonstrate the error on 4.4?

Thanks for your help and patience

[Bug lto/57267] [4.9 regression] -flto-partition=none : symbol is already defined

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267

--- Comment #2 from Jan Hubicka  ---
This is fixed by
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00695.html

Honza

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[andrey.turetskiy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

--- Comment #4 from Andrey Turetskiy  ---

> - return false;
> + return true;

Isn't it too strong?
Shouldn't it be like this:

return !(DR_IS_READ (dra) && DR_IS_READ (drb));

Gather is a load operation. If another statement is load too, I think the loop
still can be vectorized.

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

--- Comment #5 from Jakub Jelinek  ---
There is:

  /* Independent data accesses.  */
  if (DDR_ARE_DEPENDENT (ddr) == chrec_known)
return false;

  if (dra == drb
  || (DR_IS_READ (dra) && DR_IS_READ (drb)))
return false;

a few lines before this.

[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264

--- Comment #10 from Uroš Bizjak  ---
(In reply to thutt from comment #9)

> When the sample test program provided above was compiled with gcc 4.4, it
> did not generate the stos instruction.  However, each of 4.5, 4.6 and 4.7
> did generate the stos instruction.
> 
> Given this, I'd like to clarify your answer.  If I may summarize:
> 
>   4.3.0 stopped using cld.

Yes.

>   After cld was not used, an error existed in versions 4.4, 4.5, 4.6 and 4.7.

This was not an error, x86 ABI specifies that direction flag has to be cleared.
As a convenient feature, -mcld was introduced to "fix" non-conforming binaries
that played tricks with x86 direction flag.

>   The error was fixed in 4.8.

4.8 "fixed" this issue as a secondary effect of some other bugfix.

>   You have backported the fix from 4.8 to 4.7.

Yes.

>   You did not backport to 4.5 and 4.6 because they are closed.

Yes.

>   You do not state, but I infer that 4.4 is also closed.

Yes.

> Do you have an idea why the test case does not demonstrate the error on 4.4?
> Is there a test case that will demonstrate the error on 4.4?

As you have found out, the test is very fragile and depends on exact code
sequence of two consecutive instructions. This sequence is recognized in
combine pass as STOSL instruction. However, the dependence of STOSL on
direction flag is not modelled in the compiler, since it is not necessary for
ABI conformant binaries. In 4.4, the generated sequence is probably slightly
different, and for this reason not recognized as STOSL.

[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[andrey.turetskiy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275

--- Comment #6 from Andrey Turetskiy  ---
Oops, sorry.

[Bug middle-end/57278] -fno-if-conversion and -fno-if-conversion2 do not work as intended

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57278

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
I don't think  -fno-if-conversion and -fno-if-conversion2 are designed to turn
off all predicated instructions.

Note -O3 turns on -ftree-loop-if-convert which also causes production of
predicated instructions (predicated moves).

[Bug target/57260] Generated R_MIPS_GOT_MIPS relocation for direct function call while compiling with -O2 on MIPS N64

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-14
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Confirmed.

As discusseded on the binutils list, this is definitely a bug IMO.
It's a QoI requirement that we use lazy binding for direct calls.
I don't think I'd realised quite how important that is when
I implemented sibling calls for PIC way back when.

As for why GCC is using %got_disp for sibling calls: the problem
is that lazy-binding stubs require $gp to be valid on entry.
And $gp is call-saved on n32 and n64, so functions must restore
the _caller's_ value of $gp before returning from a function.
This means that $gp might hold the wrong value on entry to a
sibcalled stub.

I think the fix is simply to disable direct sibling calls for
n32 and n64 non-PLT abicalls.  (o32 is OK, because $gp is call-clobbered
there.)  It's unfortunate that we lose optimisation for a once-per-run
thing, but I don't think there's any alternative.

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

--- Comment #3 from Andrew Pinski  ---
(In reply to java4ada from comment #2)
> I don't know if ABI dictates it but from observation the stack is aligned to
> 8-byte for the largest primitive type "double" (or long long). 

I think this is wrong the alignment requirement for arm-eabi is 16 byte IIRC
(so neon can be supported).

[Bug c++/57279] New: [C++11] alias declaration fails to declare function types with cv-qualifiers

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279

Bug ID: 57279
   Summary: [C++11] alias declaration fails to declare function
types with cv-qualifiers
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com

The following code is rejected if compiled with gcc 4.9.0 20130505
(experimental) using the flags

-std=c++11 -Wall -pedantic-errors

//
typedef void fc1() const; // OK
typedef void frr1() &&; // OK
typedef void fcr1() const &;
using fc2 = void() const; // #4
using frr2 = void() &&; // OK
using fcr2 = void() const &; // #6
//

"main.cpp|4|error: invalid qualifiers on non-member function type|
 main.cpp|6|error: invalid qualifiers on non-member function type|"

According to 8.3.5 [dcl.fct] p6 function type declarations with cv-qualifiers
are valid via alias-declarations (b3).

[Bug libgcc/57280] New: new crtbegin1.o for __EH_FRAME_BEGIN__

[jan.kratochvil at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57280

Bug ID: 57280
   Summary: new crtbegin1.o for __EH_FRAME_BEGIN__
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
Target: x86_64-unknown-linux-gnu

GCC tracker for PR libc/15407:
http://sourceware.org/bugzilla/show_bug.cgi?id=15407

gold -static has a regression due to (new, since 2012) libc _start x86_64 CFI.

crti.o is linked before crtbegin.o where crtbegin.o contains
__EH_FRAME_BEGIN__.
But crti.o now contains CIE+FDE so its FDE is accidentally not registered.

[Bug target/57260] Generated R_MIPS_GOT_MIPS relocation for direct function call while compiling with -O2 on MIPS N64

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Created attachment 30116
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30116&action=edit
Candidate patch

Here's the patch I'm testing.  Lee, could you check that it
fixes the original libglx problem?

[Bug libgcc/57280] new crtbegin1.o for __EH_FRAME_BEGIN__

[jan.kratochvil at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57280

--- Comment #1 from Jan Kratochvil  ---
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html

[Bug c++/57274] [4.8/4.9 Regression] Bogus sequence-point warning in C++

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57274

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 14 20:50:43 2013
New Revision: 198903

URL: http://gcc.gnu.org/viewcvs?rev=198903&root=gcc&view=rev
Log:
PR c++/57274
* c-common.c (verify_tree): Don't recurse into SIZEOF_EXPR.

* c-c++-common/Wsequence-point-1.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wsequence-point-1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Tue May 14 20:52:27 2013
New Revision: 198904

URL: http://gcc.gnu.org/viewcvs?rev=198904&root=gcc&view=rev
Log:
PR c++/57274
* c-common.c (verify_tree): Don't recurse into SIZEOF_EXPR.

* c-c++-common/Wsequence-point-1.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/Wsequence-point-1.c
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-common.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/57243] Using auto in range based for with templated container in templated function requires extraneous template qualifier

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57243

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |4.8.1

--- Comment #1 from Jason Merrill  ---
Fixed for 4.8.1.

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

--- Comment #4 from Richard Earnshaw  ---
The ARM EABI only requires 8-byte alignment, as does Neon.

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[java4ada at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271

--- Comment #5 from java4ada at yahoo dot com ---
NEON instructions like vst/vld [:128] and [:256] need 16-byte and 32-byte
alignment, respectively.  Does it mean under ARM EABI both should be replaced
with [:64] ? (Probably only at the cost of 1-2 cycle anyway)

What other ARM ABI we can configure to get higher alignment than 8-byte?

[Bug target/57281] New: x86_64-linux loop fails to terminate at -O3 -m32

[dhazeghi at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281

Bug ID: 57281
   Summary: x86_64-linux loop fails to terminate at -O3 -m32
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhazeghi at yahoo dot com

The testcase below is miscompiled with current gcc trunk at -O3 optimization
level in 32-bit mode on x86_64-linux-gnu, and fails to terminate.  With other
optimizations levels in 64-bit mode, it executes successfully.  This is a
regression from 4.8, where the code works at all optimizations levels.

$ gcc-trunk -v
...
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130514 (experimental) [trunk revision 198875] (GCC)
$ gcc-trunk -O2 -m32 test.c
$ ./a.out
$ gcc-4.8 -O3 -m32 test.c
$ ./a.out
$ gcc-trunk -O3 -m32 test
$ ./a.out



--

int a = 1, b = 0, d;
long long c;
int *e = &d;
volatile long long f;
long long *g = &c;

int foo(int h)
{
  int j = *g = b;
  return h == 0 ? j : 0;
}

int
main ()
{
int h = a;
for (; b != -20; b--)
{
int i = f;
*e = 0;
*e = foo(h);
}
return 0;
}

[Bug c++/57211] wrong line indicated in warning for synthesized method

[anthony.foiani at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57211

Anthony Foiani  changed:

   What|Removed |Added

 CC||anthony.foiani at gmail dot com

--- Comment #1 from Anthony Foiani  ---
Created attachment 30117
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30117&action=edit
demonstration code showing problem and workaround

[Bug c++/57211] wrong line indicated in warning for synthesized method

[anthony.foiani at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57211

--- Comment #2 from Anthony Foiani  ---
I'm also seeing this bug, in version 4.7.2.

Instead of trying to fix the line offset, I believe the right thing is to not
emit this warning in this case at all.

The parameter is certainly used, even if the synthesized method uses a
different formal argument name.  (In which case, shouldn't it offer a
corresponding undeclared variable error?)

Put another way: if the method has a signature which can be defaulted, then the
parameter name(s) should be ignored.  (IMHO of course.)

A workaround is to omit the parameter name, but I feel that reduces
readability.  (It also makes some documentation-generating tools sad, e.g.,
doxygen.)

See attached for a version of Matthias's code that shows workaround via macro
flag.

[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies

[anthony.foiani at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477

Anthony Foiani  changed:

   What|Removed |Added

 CC||anthony.foiani at gmail dot com

--- Comment #7 from Anthony Foiani  ---
Sorry to resurrect an oldish bug, but I was just bitten by a related issue (bug
57211).

One case where I run into Miles' situation is when writing documentation; as
mentioned, root classes often have no-op stubs, but they're also where those
stubs are documented.  E.g.,

/**
 * Do stuff with @a foo.
 *
 * @param[in]   foo widget to frobnicate.
 *
 * @return whether foo was successfully frobbed.
 */

virtual bool frobnicate( Widget & foo ) {}

If I use "/* foo */", then doxygen will complain that there is no matching
parameter name.

If I don't use those comments, then -Wunused-parameters gives me a warning.

Would it be possible to introduce something like -Wno-virtual-unused-parameters
to accomodate this?

Or possibly merge it with a flag that would allow similar ignoring of defaulted
methods (which is how I got here).

Thanks!

[Bug other/57282] New: Canadian cross on FreeBSD to MingW32 fails with unknown warning "-Wno-narrowing" is build gcc is too old

[chris at contemporary dot net.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57282

Bug ID: 57282
   Summary: Canadian cross on FreeBSD to MingW32 fails with
unknown warning "-Wno-narrowing" is build gcc is too
old
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris at contemporary dot net.au

Using gcc-4.8-branch sources from the git repo.

FreeBSD 9.1 machine with the default gcc-4.2.1.

Build the ports for devel/mingw32-binutils, devel/mingw32-gcc and
devel/mingw32-zlib. This gives a mingw32-gcc that is gcc-4.7.2.

Follow the standard build process for a canadian cross to arm-rtems4.11 you end
up with:

../gcc-4.8.0/configure --prefix=/opt/rtems/4.11 --bindir=/opt/rtems/4.11/bin
--exec_prefix=/opt/rtems/4.11 --includedir=/opt/rtems/4.11/include
--libdir=/opt/rtems/4.11/lib --libexecdir=/opt/rtems/4.11/libexec
--mandir=/opt/rtems/4.11/share/man --infodir=/opt/rtems/4.11/share/info
--datadir=/opt/rtems/4.11/share --build=x86_64-freebsd9.0 --host=mingw32
--target=arm-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv --enable-threads
--disable-plugin --enable-obsolete --enable-languages=c,c++

This fails at:

/usr/bin/g++ -O2 -pipe
-I/usr/home/chrisj/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-chrisj/4.11/rtems-arm.bset/opt/rtems/4.11/include
-L/usr/home/chrisj/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-chrisj/4.11/rtems-
arm.bset/opt/rtems/4.11/lib -I/usr/local/include -L/usr/local/lib -c   -g -O2
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pe
dantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.0/gcc
-I../../gcc-4.8.0/gcc/build -I../../gcc-4.8.0/gcc/../include
-I../../gcc-4.8.0/gcc/../libcpp/include -I/usr/home/chri
sj/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1-4.8.0/build-cxc/./gmp
-I/usr/home/chrisj/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems
4.11-gcc-4.8.0-newlib-13-May-2013-1/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1-4.8.0/gcc-4.8.0/gmp
-I/usr/home/chrisj/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1/arm-rtems4.11-gcc-4.8.0-newlib-13
-May-2013-1-4.8.0/build-cxc/./mpfr
-I/usr/home/chrisj/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1-4.8.0/gcc-4.8.0/mpfr
-I/usr/home/chrisj/development/rt
ems/src/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1/arm-rtems4.11-gcc-4.8.0-newlib-13-May-2013-1-4.8.0/gcc-4.8.0/mpc/src
 -I../../gcc-4.8.0/gcc/../libdecnumber
-I../../gcc-4.8.0/gcc/../libdecnumber/dpd -I../libdecnumber
 -I../../gcc-4.8.0/gcc/../libbacktrace\
-DBASEVER="\"4.8.1\"" -DDATESTAMP="\" 20130515\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (RTEMS
4.11-RSB(1b40c77e7b9ed7d87ec555abe0a0f4691841a2f8)-1,gcc-4.8.0/newlib-13-May-2013)\""
-DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"\"" -o build/version.o
../../gcc-4.8.0/gcc/version.c
cc1plus: error: unrecognized command line option "-Wno-narrowing"

because the warnings test to select the warnings uses the mingw32 (host)
compiler rather than the build compiler. If I build and install a FreeBSD
gcc-4.7.2 compiler the error does not happen.

Also the warnings test is for the C compiler and not the C++ compiler, ie they
must be the same version which is fair enough but not tested for when configure
runs. I had configuration issues having the different versions on the machine
because of above this can be confusing.

If all the versions are correct things build however this error and reason are
not straight forward.

[Bug other/57282] Canadian cross on FreeBSD to MingW32 fails with unknown warning "-Wno-narrowing" as build gcc is too old

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57282

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 57059.

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

[Bug bootstrap/57059] [4.8/4.9 Regression] Host configuration of loose_warn breaks for build components for Canadian crosses

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57059

Andrew Pinski  changed:

   What|Removed |Added

 CC||chris at contemporary dot 
net.au

--- Comment #2 from Andrew Pinski  ---
*** Bug 57282 has been marked as a duplicate of this bug. ***