date:20131030

[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner

2013-10-30 Thread ebotcazou at gcc dot gnu.org

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

--- Comment #11 from Eric Botcazou  ---
> So why don't reject it at
> TARGET_LEGITIMATE_COMBINED_INSN/ix86_legitimate_combined_insn
> instead of limit at combine phase if it's only benefit for x86 ?

The question sounds self-contradictory...  Anyway, rather than inventing a new
hook for each problem, let's try to formulate it in terms of existing hooks.

[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2

2013-10-30 Thread abel at gcc dot gnu.org

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

--- Comment #6 from Andrey Belevantsev  ---
(In reply to Richard Biener from comment #5)
> Fixed according to
> 
> 2013-08-14  Andrey Belevantsev  
> 
> PR rtl-optimization/57662
> * sel-sched.c (code_motion_process_successors): When the current insn
> is removed after the recursive traversal, break from the loop.
> Add comments and debug printouts.
> 
> (?)

Yes.  Sorry, I keep forgetting that the post-commit Bugzilla autoupdate no
longer works so I didn't look at the PR after committing.

[Bug rtl-optimization/58934] New: [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c

2013-10-30 Thread hp at gcc dot gnu.org

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

Bug ID: 58934
   Summary: [4.9 Regression]: build fails on cris-elf in
reload_cse_simplify_operands for newlib dtoa.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Host: x86_64-unknown-linux-gnu
Target: cris-axis-elf

Created attachment 31115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31115&action=edit
Repeat as ./cc1 -fpreprocessed -O2 -o dtoa.s dtoa.i

Revision r204205 caused the build for cris-elf to fail as follows:

/tmp/break20131030_05/gccobj/./gcc/xgcc -B/tmp/break20131030_05/gccobj/./gcc/
-nostdinc -B/tmp/break20131030_05/gccobj/cris-elf/v8/newlib/ -isystem
/tmp/break20131030_05/gccobj/cris-elf/v8/newlib/targ-include -isystem
/tmp/break20131030_05/gcc/newlib/libc/include
-B/tmp/break20131030_05/gccobj/cris-elf/v8/libgloss/cris
-L/tmp/break20131030_05/gccobj/cris-elf/v8/libgloss/libnosys
-L/tmp/break20131030_05/gcc/libgloss/cris
-B/tmp/break20131030_05/pre/cris-elf/bin/
-B/tmp/break20131030_05/pre/cris-elf/lib/ -isystem
/tmp/break20131030_05/pre/cris-elf/include -isystem
/tmp/break20131030_05/pre/cris-elf/sys-include  -march=v8 -mbest-lib-options
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.20.0\" -DPACKAGE_STRING=\"newlib\ 1.20.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/tmp/break20131030_05/gcc/newlib/libc/stdlib -DHAVE_RENAME -D_USE_WRITE
-DCOMPACT_CTYPE -fno-builtin  -g -O2  -march=v8 -mbest-lib-options -c -o
lib_a-dtoa.o `test -f 'dtoa.c' || echo
'/tmp/break20131030_05/gcc/newlib/libc/stdlib/'`dtoa.c
/tmp/break20131030_05/gcc/newlib/libc/stdlib/dtoa.c: In function 'quorem':
/tmp/break20131030_05/gcc/newlib/libc/stdlib/dtoa.c:142:1: error: insn does not
satisfy its constraints:
 }
 ^
(insn 289 35 288 3 (set (reg/v/f:SI 171 [orig:132 S ] [132])
(reg/v/f:SI 11 r11 [orig:132 S ] [132])) 37 {*movsi_internal}
 (nil))
/tmp/break20131030_05/gcc/newlib/libc/stdlib/dtoa.c:142:1: internal compiler
error: in reload_cse_simplify_operands, at postreload.c:411
0x8a5018 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/tmp/break20131030_05/gcc/gcc/rtl-error.c:109
0x8a503f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/tmp/break20131030_05/gcc/gcc/rtl-error.c:120
0x858866 reload_cse_simplify_operands
/tmp/break20131030_05/gcc/gcc/postreload.c:411
0x858b44 reload_cse_simplify
/tmp/break20131030_05/gcc/gcc/postreload.c:123
0x858b44 reload_cse_regs_1
/tmp/break20131030_05/gcc/gcc/postreload.c:220
0x858bd3 reload_cse_regs
/tmp/break20131030_05/gcc/gcc/postreload.c:68
0x858bd3 rest_of_handle_postreload
/tmp/break20131030_05/gcc/gcc/postreload.c:2332
0x858bd3 execute
/tmp/break20131030_05/gcc/gcc/postreload.c:2368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[8]: *** [lib_a-dtoa.o] Error 1
make[8]: Leaving directory
`/tmp/break20131030_05/gccobj/cris-elf/v8/newlib/libc/stdlib'

Author of commit CC:ed.  Preprocessed code attached.

[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner

2013-10-30 Thread npickito at gmail dot com

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

Kito Cheng  changed:

   What|Removed |Added

 CC||npickito at gmail dot com

--- Comment #10 from Kito Cheng  ---
So why don't reject it at
TARGET_LEGITIMATE_COMBINED_INSN/ix86_legitimate_combined_insn
instead of limit at combine phase if it's only benefit for x86 ?

[Bug bootstrap/58933] IRA ICE in update_costs_from_allocno

2013-10-30 Thread vmakarov at gcc dot gnu.org

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Oct 31 03:14:07 2013
New Revision: 204245

URL: http://gcc.gnu.org/viewcvs?rev=204245&root=gcc&view=rev
Log:
2013-10-30  Vladimir Makarov  

PR bootstrap/58933
* ira-color.c (update_costs_from_copies): Add new parameter.  Use
it for calling update_costs_from_allocno.
(assign_hard_reg): Call restore_costs_from_copies only for
!retry_p.  Pass new argument to update_costs_from_copies.
(color_pass): Pass new argument to update_costs_from_copies.
(ira_mark_allocation_change): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

2013-10-30 Thread singhai at gcc dot gnu.org

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

--- Comment #6 from Sharad Singhai  ---
Author: singhai
Date: Thu Oct 31 01:01:40 2013
New Revision: 204244

URL: http://gcc.gnu.org/viewcvs?rev=204244&root=gcc&view=rev
Log:
2013-10-30  Sharad Singhai  

PR middle-end/58134
* opts.c (common_handle_option): Remove deprecated option
-ftree-vectorizer-verbose.
* doc/invoke.texi (Debugging Options): Ditto.
* opts-global.c (handle_common_deferred_options): Ditto.
(dump_remap_tree_vectorizer_verbose): Delete.
* common.opt: Set -ftree-vectorizer-verbose as an ignored option.

ada/ChangeLog
* gnat_ugn.texi: Remove option description for PR middle-end/58134.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_ugn.texi
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts-global.c
trunk/gcc/opts.c

[Bug target/58762] [missed optimization] Vectorizing abs(int).

2013-10-30 Thread congh at gcc dot gnu.org

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

--- Comment #3 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Oct 31 00:50:47 2013
New Revision: 204241

URL: http://gcc.gnu.org/viewcvs?rev=204241&root=gcc&view=rev
Log:
2013-10-30  Cong Hou  

Backport from mainline:
2013-10-30  Cong Hou  

PR target/58762
* config/i386/i386-protos.h (ix86_expand_sse2_abs): New function.
* config/i386/i386.c (ix86_expand_sse2_abs): New function.
* config/i386/sse.md: Add SSE2 support to abs (8/16/32-bit-int).


Modified:
branches/google/gcc-4_8/gcc/ChangeLog
branches/google/gcc-4_8/gcc/config/i386/i386-protos.h
branches/google/gcc-4_8/gcc/config/i386/i386.c
branches/google/gcc-4_8/gcc/config/i386/sse.md

[Bug ada/52121] [Ada] Compiler assertion on precondition

2013-10-30 Thread nicolas.boulenguez at free dot fr

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

nicolas.boulenguez at free dot fr changed:

   What|Removed |Added

 CC||nicolas.boulenguez at free dot 
fr

--- Comment #2 from nicolas.boulenguez at free dot fr ---
4.6.4 crashes with the same message.
4.8.2 compiles silently.

[Bug c++/43361] missing uninitialized warning without optimization (loop representation)

2013-10-30 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||noufal at nibrahim dot net.in

--- Comment #7 from Manuel López-Ibáñez  ---
*** Bug 58236 has been marked as a duplicate of this bug. ***

[Bug c/58236] -Wuninitialized doesn't report uninitialised variable as expected

2013-10-30 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Resolution|WONTFIX |DUPLICATE

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Noufal Ibrahim from comment #2)
> That solves the issue although I find the relationship between the
> optimisations and the warnings somewhat tenuous atleast from a user
> perspective. Would it not be a good idea to have this warning even by
> default?

You can find a very detailed description of the problems involved at:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Current_Situation

The relationship is easy to explain:

* More precise warnings require more expensive analysis
* The expensive analysis are only done when optimizations are enabled
* So you get more precise warnings when enabling more optimizations.

There are some ideas in that page on how to tackle these issues, but nothing is
sure to work reliably and all of them require considerable effort and time.
Until someone very determined steps up to the challenge, there will be little
progress.

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

[Bug ada/52120] [Ada] Compiler assertion in iterator

2013-10-30 Thread nicolas.boulenguez at free dot fr

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

--- Comment #2 from nicolas.boulenguez at free dot fr ---
4.8.2-1 produces the expected output for the last trigger
gcc-4.8 -c proc.adb
proc.adb:9:10: iterator is an Ada 2012 feature
gnatmake: "proc.adb" compilation error

[Bug other/58545] [4.7/4.8/4.9 Regression] error: unable to find a register to spill in class 'POINTER_REGS'

2013-10-30 Thread amylaar at gcc dot gnu.org

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

--- Comment #5 from Jorn Wolfgang Rennecke  ---
Author: amylaar
Date: Wed Oct 30 23:55:46 2013
New Revision: 204234

URL: http://gcc.gnu.org/viewcvs?rev=204234&root=gcc&view=rev
Log:
gcc:
PR other/58545
* reload1.c (update_eliminables_and_spill): New function, broken
out of reload.
(reload): Use it.  Check for frame size change after frame
size alignment, and call update_eliminables_and_spill first
if continue-ing.
gcc/testsuite:
PR other/58545
* gcc.target/avr/pr58545.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/avr/pr58545.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/58915] [missed optimization] GCC fails to get the loop bound for some loops.

2013-10-30 Thread congh at google dot com

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

--- Comment #2 from Cong Hou  ---
I am afraid that get_range_info () has little use here. The value range we care
about may only exist under specific conditions and is hence flow sensitive. For
example, we may need the value range of n in the if body:

if (n > 0)
  if (n < 4)
/* use of n */

However, n does not have a new name under the condition n>0 && n<4, making it
impossible to get the range (0, 4) from the SSA_NAME of n.

[Bug bootstrap/58933] IRA ICE in update_costs_from_allocno

2013-10-30 Thread dje at gcc dot gnu.org

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2013-10-30
 CC||pthaugen at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Host||powerpc*-*-*
 Ever confirmed|0   |1
   Target Milestone|--- |4.9.0
  Build||powerpc*-*-*

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/58933] New: IRA ICE in update_costs_from_allocno

2013-10-30 Thread dje at gcc dot gnu.org

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

Bug ID: 58933
   Summary: IRA ICE in update_costs_from_allocno
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

/nasfarm/edelsohn/src/src/libgcc/libgcov.c: In function 'gcov_exit':
/nasfarm/edelsohn/src/src/libgcc/libgcov.c:827:1: internal compiler error: in
up
date_costs_from_allocno, at ira-color.c:1334

[Bug c++/58932] New: [4.9 Regression][C++11] Deleted functions and SFINAE in partial template specializations

2013-10-30 Thread lucdanton at free dot fr

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

Bug ID: 58932
   Summary: [4.9 Regression][C++11] Deleted functions and SFINAE
in partial template specializations
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

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

Using:

$ gcc-snapshot --version
gcc-snapshot (Debian 20131021-1) 4.9.0 20131021 (experimental) [trunk revision
203899]

with flags -std=c++11 -Wall. The testcase is modified from PR 37208
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208). I'm fairly confident that
previous 4.9 snapshots used to accept that kind of code (i.e. compile,
undefined references notwithstanding), and I think 4.8 does -- no copy of 4.8.2
on hand though.

[Bug bootstrap/58918] [4.9 regression] cilk #includes alloc.h unconditionally, even when not present

2013-10-30 Thread bviyer at gcc dot gnu.org

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

--- Comment #4 from bviyer at gcc dot gnu.org ---
Author: bviyer
Date: Wed Oct 30 22:51:29 2013
New Revision: 204232

URL: http://gcc.gnu.org/viewcvs?rev=204232&root=gcc&view=rev
Log:
Fix for bug Bootstrap/58918.
+2013-10-30  Balaji V. Iyer  
+
+   * configure: Reconfigured.
+   * configure.ac: Add AC_FUNC_ALLOCA.
+   * runtime/sysdep-unix.c: Added check for alloca.h before
+   including it.
+   * config/x86/cilk-abi-vla.c: Likewise.
+   * runtime/cilk_fiber-unix.cpp: Likewise.
+


Modified:
trunk/libcilkrts/ChangeLog
trunk/libcilkrts/Makefile.in
trunk/libcilkrts/configure
trunk/libcilkrts/configure.ac
trunk/libcilkrts/runtime/cilk_fiber-unix.cpp
trunk/libcilkrts/runtime/config/x86/cilk-abi-vla.c
trunk/libcilkrts/runtime/sysdep-unix.c

[Bug c++/58931] New: condition_variable::wait_until overflowed by large time_point

2013-10-30 Thread lundberj at gmail dot com

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

Bug ID: 58931
   Summary: condition_variable::wait_until overflowed by large
time_point
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundberj at gmail dot com

With valid but large steady clock time_points, condition_variable.wait_until
does not sleep at all, but instead continues as if the time was passed. 

Perhaps related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562

Example: 

#include 
#include 
#include 
int main(){
  std::mutex m;
  std::condition_variable cv;
  std::unique_lock lk(m);
  // does not sleep at all:
  cv.wait_until(lk,
 std::chrono::time_point::max());
  // sleeps fine:
  //cv.wait_until(lk,
  //   std::chrono::steady_clock::now()+1*std::chrono::hours{24*365});
}

cheers / Johan -thanks for a great compiler! 

PS.
* I compiled gcc with --enable-libstdcxx-time=yes. Using 64 bit linux 3.5.0
* The bug does not occur with system_clock.
* I used time_point max() to let a worker thread wait when a queue of delayed
events was empty.

[Bug tree-optimization/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #9 from Jeffrey A. Law  ---
Using uninitialized objects results in undefined behaviour according to the
standards.  This is not a bug.

[Bug c/58183] Missing uninitialized warning

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #1 from Jeffrey A. Law  ---
You have to enable the optimizer to get uninitialized variable warnings.

Compiling your testcase with -O2 -Wuninitialized:


j.c: In function 'main':
j.c:5:12: warning: 'i' is used uninitialized in this function [-Wuninitialized]
 while(i++<10)
^

[Bug c/58236] -Wuninitialized doesn't report uninitialised variable as expected

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #3 from Jeffrey A. Law  ---
I agree it's not ideal and there's been some proposals to change it that have
never gotten any traction -- largely because many folks find the alternatives
even worse because they'll generate many more false positives than the current
implementation.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
 Blocks||19794

--- Comment #7 from Jeffrey A. Law  ---
I've long pondered separating jump threading from DOM and making jump threading
a backwards walk of the use-def chains from the condition.

Given such a structure one could envision a knob which controlled how far back
in the use-def chains we walk.  If that knob just allowed walking one
statement, we'd catch the jump threads in blocks #4 and #7 trivially.

But that's all work far into the future.

Of course that still leaves an open question about what, if any threading we'd
want to do at -Og.  We'd certainly have to look at that closely.

[Bug c++/58930] New: [C++11] Bogus error: converting to ... from initializer list would use explicit constructor

2013-10-30 Thread ppluzhnikov at google dot com

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

Bug ID: 58930
   Summary: [C++11] Bogus error: converting to ... from
initializer list would use explicit constructor
   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

Google ref: b/11448857

This is somewhat similar to PR54835.

// ---
struct SampleModule
{
   explicit SampleModule (int);
};

template < typename >
struct BaseHandler
{
#ifndef BUG
   BaseHandler ();
#endif
   SampleModule module_ { 0 };
};

BaseHandler a;
// ---

Clang compiles either variant.
Trunk GCC (g++ (GCC) 4.9.0 20131028 (experimental)):

g++ -c -std=c++11 t.cc && echo ok && g++ -c -std=c++11 t.cc -DBUG
ok
t.cc: In constructor 'constexpr BaseHandler::BaseHandler()':
t.cc:7:8: error: converting to 'SampleModule' from initializer list would use
explicit constructor 'SampleModule::SampleModule(int)'
 struct BaseHandler
   ^
t.cc: At global scope:
t.cc:15:18: note: synthesized method 'constexpr
BaseHandler::BaseHandler()' first required here
 BaseHandler a;
 ^

Making BaseHandler a non-template class also makes the problem go away.

[Bug rtl-optimization/58369] [4.8 regression] ICE in subreg_get_info when compiling boost for m68k-linux

2013-10-30 Thread mikpelinux at gmail dot com

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

Mikael Pettersson  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 regression] ICE in |[4.8 regression] ICE in
   |subreg_get_info when|subreg_get_info when
   |compiling boost for |compiling boost for
   |m68k-linux  |m68k-linux
  Known to fail|4.9.0   |4.8.2

--- Comment #6 from Mikael Pettersson  ---
Fixed on trunk so far.

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #6 from Jeffrey A. Law  ---
Jakub's comments in c#4 are 100% accurate.  This isn't something we're going to
change/fix.  Sorry.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

2013-10-30 Thread law at redhat dot com

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

Bug 24639 depends on bug 58488, which changed state.

Bug 58488 Summary: -Wuninitialized is useless for a variable whose address is 
later taken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

   What|Removed |Added

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

[Bug target/58901] vax bootstrap fails on subreg reload

2013-10-30 Thread martin at netbsd dot org

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

--- Comment #2 from Martin Husemann  ---
indexable_address_p() returns false for

(symbol_ref:SI ("DECPOWERS") [flags 0x40] )

because flag_pic is true and symbolic_operand (xfoo0, SImode)) returns true:

/* Return true if xfoo0 and xfoo1 constitute a valid indexed address.  */
static bool
indexable_address_p (rtx xfoo0, rtx xfoo1, enum machine_mode mode, bool strict)
{
  if (!CONSTANT_ADDRESS_P (xfoo0))
return false;
  if (BASE_REGISTER_P (xfoo1, strict))
return !flag_pic || mode == QImode;
  if (flag_pic && symbolic_operand (xfoo0, SImode))
return false;
  return reg_plus_index_p (xfoo1, mode, strict);
}

I don't know vax addressing modes - help!

[Bug c++/58929] New: condition_variable does not wait without -pthread

2013-10-30 Thread lundberj at gmail dot com

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

Bug ID: 58929
   Summary: condition_variable does not wait without -pthread
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundberj at gmail dot com

A warning would have been helpful for this case of missed -pthread. 
Normally a runtime error is at least generated but the following C++11 code
compiles fine with all warnings enabled, and also executes without run time
errors, but does so incorrectly if -pthread is not given. (wait_for is then
just skipped). 

cheers Johan.

#include 
#include 
#include 
void sleep10(){ // sleeps only of -pthread is used
  std::mutex m;
  std::condition_variable cv;
  std::unique_lock lk(m);
  cv.wait_for(lk,std::chrono::seconds{10}); 
}

[Bug c/58928] New: Different results from gcc when -mlzcnt is used

2013-10-30 Thread mikeb01 at gmail dot com

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

Bug ID: 58928
   Summary: Different results from gcc when -mlzcnt is used
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikeb01 at gmail dot com

Created attachment 31113
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31113&action=edit
Preprossed test.c code

I have the following code:

#include 
#include 
#include 

long long lzcnt(long long l)
{
return __lzcnt64(l);
}

int main(int argc, char** argv)
{
printf("%lld\n", lzcnt(atoll(argv[1])));
return 0;
}

If I compile and run with and without the -mlzcnt flag I get different results:

$ gcc src/test.c -D__LZCNT__ -mlzcnt && ./a.out 2047
10

$ gcc src/test.c -D__LZCNT__ && ./a.out 2047
53

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC) 

File test.i attached.  It was the same for both compilations, so only one file
attached.

[Bug target/58762] [missed optimization] Vectorizing abs(int).

2013-10-30 Thread congh at gcc dot gnu.org

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

--- Comment #2 from congh at gcc dot gnu.org ---
Author: congh
Date: Wed Oct 30 20:01:47 2013
New Revision: 204229

URL: http://gcc.gnu.org/viewcvs?rev=204229&root=gcc&view=rev
Log:
2013-10-30  Cong Hou  

PR target/58762
* config/i386/i386-protos.h (ix86_expand_sse2_abs): New function.
* config/i386/i386.c (ix86_expand_sse2_abs): New function.
* config/i386/sse.md: Add SSE2 support to abs (8/16/32-bit-int).

2013-10-30  Cong Hou  

* gcc.target/i386/vect-abs-s8.c: New test.
* gcc.target/i386/vect-abs-s16.c: New test.
* gcc.target/i386/vect-abs-s32.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/vect-abs-s16.c
trunk/gcc/testsuite/gcc.target/i386/vect-abs-s32.c
trunk/gcc/testsuite/gcc.target/i386/vect-abs-s8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/58901] vax bootstrap fails on subreg reload

2013-10-30 Thread martin at netbsd dot org

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

--- Comment #1 from Martin Husemann  ---
The real question is: why does memory_address_addr_space_p() return false for
this rtx. Stepping into it results in:

0x007618be in vax_legitimate_address_p (mode=HImode, x=0x7ea0fd2c, 
strict=20, 5, 2124479788, 0) at ../../gcc-4.8.2/gcc/config/vax/vax.c:1801
1801vax_legitimate_address_p (enum machine_mode mode, rtx x, bool strict)
(gdb) n
1805  if (nonindexed_address_p (x, strict))
(gdb) print mode
$4 = HImode
(gdb) p debug_rtx(x)
(plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81])
(const_int 4 [0x4]))
(symbol_ref:SI ("DECPOWERS") [flags 0x40] ))
$5 = void
(gdb) p strict
$6 = false
(gdb) n
1808  if (GET_CODE (x) != PLUS)
(gdb) 
1813  xfoo0 = XEXP (x, 0);
(gdb) 
1814  xfoo1 = XEXP (x, 1);
(gdb) 
1816  if (index_term_p (xfoo0, mode, strict)
(gdb) 
1826  if (indexable_address_p (xfoo0, xfoo1, mode, strict)
(gdb) 
1830  return false;

with a backtrace:

#0  vax_legitimate_address_p (mode=HImode, x=0x7ea0fd2c, 
strict=false, 5, 2124479788, 0)
at ../../gcc-4.8.2/gcc/config/vax/vax.c:1830
#1  0x0052049a in default_addr_space_legitimate_address_p (mode=HImode, 
mem=0x7ea0fd2c, strict=false, as=0 '\000', 5, 2124479788, 0, 0)
at ../../gcc-4.8.2/gcc/targhooks.c:1175
#2  0x004aa683 in memory_address_addr_space_p (mode=HImode, addr=0x7ea0fd2c, 
as=0 '\000', 5, 2124479788, 0) at ../../gcc-4.8.2/gcc/recog.c:1299
#3  0x00295454 in change_address_1 (memref=0x7ea2d560, mode=HImode, 
addr=0x7ea0fd2c, validate=1, 2124600672, 5, 2124479788, 1)
at ../../gcc-4.8.2/gcc/emit-rtl.c:2019

and, as expected:
(gdb) p debug_rtx(xfoo0)
(mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81])
(const_int 4 [0x4]))
$7 = void
(gdb) p debug_rtx(xfoo1)
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )
$8 = void

[Bug preprocessor/58687] "#line LINE ..." changes subsequent line numbers

2013-10-30 Thread mtewoodbury at gmail dot com

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

--- Comment #13 from Max TenEyck Woodbury  ---
(In reply to jos...@codesourcery.com from comment #12)
> On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:
> 
>> Thank you, I will look info all of that.  My own resources have limits; when
>> it comes to testing generated code on many architectures, I will definitely
>> need such resources.
> 
> A fix for this particular bug should only need testing on one 
> architecture.  It's not like changes to the register allocator that are 
> likely to have architecture-specific issues.

Yes.  'make -w -k check' on the base configuration is still in progress. 
There's enough stuff wrong with the base that I need a log to check against. 
Using the compile farm here would add a queuing delay, slowing the process
further.

Oh, and could you mark this bug as either 'confirmed' or 'in-progress'?

I do have another bug (58884) that will need those resources if I am the one
that tackles fixing it...

Later...

[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux

2013-10-30 Thread law at gcc dot gnu.org

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Wed Oct 30 19:21:27 2013
New Revision: 204224

URL: http://gcc.gnu.org/viewcvs?rev=204224&root=gcc&view=rev
Log:
PR rtl-optimization/58369
* reload1.c (compute_reload_subreg_offset): New function.
(choose_reload_regs): Use it to pass endian-correct
offset to subreg_regno_offset.

* PR rtl-optimization/58369
* g++.dg/torture/pr58369.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr58369.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

2013-10-30 Thread skunk at iskunk dot org

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

--- Comment #10 from Daniel Richard G.  ---
(In reply to Richard Biener from comment #9)
> What's the status of this bug?

Same as I reported in comment #5---I just confirmed with a build of 4.8.2.

[Bug preprocessor/58887] Allow recursion in variadic macros?

2013-10-30 Thread mtewoodbury at gmail dot com

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

--- Comment #13 from Max TenEyck Woodbury  ---
(In reply to jos...@codesourcery.com from comment #12)
> 
> I was agreeing with Andrew.  Jason, the other maintainer likely to review 
> libcpp patches, hasn't commented on this issue.  (There are plenty of 
> others who *can* review such patches but are unlikely to do so in 
> practice.)

Ahh. so 'We' is you and Andrew...  OK.

> That someone doesn't reply to some point (if they read it) only indicates, 
> at most, that they do not have anything to add that has not already been 
> said adequately somewhere in the totality of the discussion, rather than 
> whether they agree or disagree.

Yes, but it would be very helpful if there is some indication that the
appropriate people have at least looked at the submission.  Something far short
of a commitment to do anything, but at least an acknowledgment that the ideas
have not been rejected out-of-hand.  'CONFIRMED' would do nicely.

 But that bug was filed on the wrong component and has languished for YEARS
 as a result of that miss-filing.  It looks like no one has looked at its
 problem seriously...
>>> 
>>> That maintainers wouldn't necessarily object to the addition of a feature 
>>> doesn't mean any maintainer has any interest in implementing it.  There 
>>> are lots of "bugs" filed suggesting some vaguely reasonable new feature 
>>> that was of interest to the submitter but not of sufficient interest to 
>>> anyone wanting to implement it (but not rejected either, because the 
>>> feature might well be accepted if implemented).
>> 
>> I have worked for companies where there was a formal definition of roles, and
>> what you describe is something from that world.  On the other hand, I believe
>> open-source projects like GCC have less authoritarian structures and that
>> such decisions are much less formal.  In other words, membership in
>> 'maintainers' is consensus based on merit, not the open and shut rule of
>> corporate structure.
> 
> Bugs languish because the maintainers - and other developers who might fix 
> them - are individuals, there is indeed no formal structure as regards 
> reviewing bugs or assigning people to fix them, and each individual who 
> looked at it was not interested in implementing the feature / fixing the 
> bug.  Misfiling is only a minor part - it could be relevant, if someone 
> had gone through all the "preprocessor" bugs, implementing lots of things, 
> and missed that one because it wasn't a "preprocessor" bug - but it so 
> happens no-one has been active in that way with preprocessor bugs lately.
> 
> Maintainers are appointed by the Steering Committee (based on merit) (but 
> someone's views on a patch or feature can be relevant and useful without 
> them being a maintainer who can approve the patch).

That matches what I understand most open-source projects do.  Again, what is
missing is some indication that the submission has not fallen into oblivion.

>> As I said, I need to go over it carefully.  It is obviously pseudo-code and
>> both the code and the explanation deserve careful study.  Where it has
>> built in the no-recursion rule was not quite obvious at first glance, thus
>> the remark about hand waving.  Again, I need to study it carefully, and I
>> have not done that yet...
> 
> No-recursion is built in through hide sets - that is, each token has at 
> each time an associated set of names of macros that cannot be expanded if 
> encountered when expanding that token.  Thus, when expanding a macro M, 
> the name M is added to the hide sets of the tokens in the expansion before 
> they, and the rest of the input, are considered for reexpansion (for 
> details see the pseudocode).
> 
> Some discussions of C macro expansion use the term "blue paint" when 
> discussing the rules for recursion.
> 
> Your proposal is apparently something that means a macro is no longer in 
> or out of a hide set, but in a state meaning whether it can be expanded 
> depends on the number of parameters.  Maybe the hide sets will need to 
> contain pairs (macro, number of arguments), or something like that, 
> instead of just macro names.

Yes, paint the number of parameters as well as the spelling.  It was precisely
the lack of specificity of what put something in the 'hide set' that I was
going to have to study.  A demonstration that the resulting expansion is
bounded if the definition is extended would need to be added to that report.  I
could probably do it but it would take me a little while and quite a bit of
effort to get back into the mental mode to do it right.  Step 7.

Yes, it would be pairs, or triples.  Spelling, variadic flag and parameter
count with all spellings of a variadic macro hidden if its parameter count
matched or exceeded the current limit.  Additional expansions would temporarily
lower the limit.  Looks doable, even a bit fun...  Late undergrad or masters
level problem, not PhD, definitely not novice.

[Bug middle-end/58927] New: Despite loop->safelen=INT_MAX / GCC ivdep: loop versioned for vectorization because of possible aliasing

2013-10-30 Thread burnus at gcc dot gnu.org

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

Bug ID: 58927
   Summary: Despite loop->safelen=INT_MAX / GCC ivdep: loop
versioned for vectorization because of possible
aliasing
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Compiling the testsuite's pr33426-ivdep-4.cc
  g++ -std=c++11 -O3 -fopt-info-vec-optimized g++.dg/vect/pr33426-ivdep-4.cc

shows that the C++11 range-based loop has loop versioning, even though it
shouldn't due to GCC ivdep:

g++.dg/vect/pr33426-ivdep-4.cc:13:19: note: loop vectorized
g++.dg/vect/pr33426-ivdep-4.cc:13:19: note: loop versioned for vectorization
because of possible aliasing
g++.dg/vect/pr33426-ivdep-4.cc:13:19: note: loop peeled for vectorization to
enhance alignment


The function is simply:

#include 

template
void Loop(T *b, T2 c) {
#pragma GCC ivdep
  for (auto &i : *b) {
i *= *c;
  }
}

void foo(std::vector *ar, int *b) {
 Loop, int*>(ar, b);
}

[Bug tree-optimization/58926] New: -Wstrict-overflow unwanted warning comparing variables initialized from one of static duration

2013-10-30 Thread gabe.jones at ni dot com

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

Bug ID: 58926
   Summary: -Wstrict-overflow unwanted warning comparing variables
initialized from one of static duration
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabe.jones at ni dot com

The following code produces a warning when compiled -O2 -Wstrict-overflow with
gcc 4.8.1:

   int k = 0;

   int main(void)
   {
 int i = k++, j = k;
 return (j >= i);
   }

> gcc -Wstrict-overflow -O2 main.cc

main.cpp: In function 'int func()':
main.cpp:6:13: warning: assuming signed overflow does not occur when assuming
that (X + c) >= X is always true [-Wstrict-overflow]
   return (j >= i);
 ^
  ^

[Bug other/33426] Support of #pragma ivdep

2013-10-30 Thread burnus at gcc dot gnu.org

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

--- Comment #18 from Tobias Burnus  ---
Author: burnus
Date: Wed Oct 30 18:53:42 2013
New Revision: 204223

URL: http://gcc.gnu.org/viewcvs?rev=204223&root=gcc&view=rev
Log:
2013-10-30  Tobias Burnus  

gcc/cp/
PR other/33426
* cp-tree.h (RANGE_FOR_IVDEP): Define.
(cp_convert_range_for, finish_while_stmt_cond, finish_do_stmt,
finish_for_cond): Take 'bool ivdep' parameter.
* cp-array-notation.c (create_an_loop): Update call.
* init.c (build_vec_init): Ditto.
* pt.c (tsubst_expr): Ditto.
* parser.c (cp_parser_iteration_statement, cp_parser_for,
cp_parser_range_for, cp_convert_range_for): Update calls.
(cp_parser_pragma): Accept GCC ivdep for 'while' and 'do'.
* semantics.c (finish_while_stmt_cond, finish_do_stmt,
finish_for_cond): Optionally build ivdep annotation.

gcc/testsuite/
PR other/33426
* g++.dg/vect/pr33426-ivdep-2.cc: New.
* g++.dg/vect/pr33426-ivdep-3.cc: New.
* g++.dg/vect/pr33426-ivdep-4.cc: New.

gcc/
PR other/33426
* gcc/tree-cfg.c (replace_loop_annotate): Replace warning by
warning_at.


Added:
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-array-notation.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug rtl-optimization/57410] [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable

2013-10-30 Thread vmakarov at gcc dot gnu.org

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

--- Comment #1 from Vladimir Makarov  ---
I can not reproduce it on today trunk.  I guess it was fixed by some LRA patch
but I ca not say by what patch exactly as there were too many LRA patches since
May.

[Bug c++/58581] [4.7/4.8/4.9 Regression] [c++11] ICE with no-throw specification in deleted function

2013-10-30 Thread paolo.carlini at oracle dot com

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-10-30
 CC||paolo.carlini at oracle dot com
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug libstdc++/58912] make_shared value initializes storage space even when not desired

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.4
  Known to fail||4.7.3, 4.8.2

--- Comment #4 from Jonathan Wakely  ---
Fixed for 4.7.4 and 4.8.3, thanks for the report.

[Bug libstdc++/58912] make_shared value initializes storage space even when not desired

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 30 18:26:53 2013
New Revision: 204222

URL: http://gcc.gnu.org/viewcvs?rev=204222&root=gcc&view=rev
Log:
2013-10-30  Chris Studholme  

PR libstdc++/58912
* include/bits/shared_ptr_base.h (_Sp_counted_ptr_inplace): Remove
unnecessary initialization of storage buffer.

Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug libstdc++/58912] make_shared value initializes storage space even when not desired

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 30 18:24:56 2013
New Revision: 204221

URL: http://gcc.gnu.org/viewcvs?rev=204221&root=gcc&view=rev
Log:
2013-10-30  Chris Studholme  

PR libstdc++/58912
* include/bits/shared_ptr_base.h (_Sp_counted_ptr_inplace): Remove
unnecessary initialization of storage buffer.

Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug preprocessor/58687] "#line LINE ..." changes subsequent line numbers

2013-10-30 Thread joseph at codesourcery dot com

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

--- Comment #12 from joseph at codesourcery dot com  ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:

> Thank you, I will look info all of that.  My own resources have limits; when 
> it
> comes to testing generated code on many architectures, I will definitely need
> such resources.

A fix for this particular bug should only need testing on one 
architecture.  It's not like changes to the register allocator that are 
likely to have architecture-specific issues.

[Bug c++/58914] Internal compiler error when using lambdas as default parameters in static methods

2013-10-30 Thread paolo.carlini at oracle dot com

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #1 from Paolo Carlini  ---
Fixed long time ago, in 4.8.0.

[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner

2013-10-30 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Will try something based on PROMOTE_MODE.

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #4 from Jonathan Wakely  ---
Yes, I should dig Ian's bug out and have another look. I'm planning to throw
some ideas around on the mailing list ...

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

2013-10-30 Thread jakub at gcc dot gnu.org

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct 30 17:59:44 2013
New Revision: 204219

URL: http://gcc.gnu.org/viewcvs?rev=204219&root=gcc&view=rev
Log:
PR target/47754
* config/i386/i386.c (ix86_avx256_split_vector_move_misalign): If
op1 is misaligned_operand, just use *mov_internal insn
rather than UNSPEC_LOADU load.
(ix86_expand_vector_move_misalign): Likewise (for TARGET_AVX only).
Avoid gen_lowpart on op0 if it isn't MEM.

* gcc.target/i386/avx256-unaligned-load-1.c: Adjust scan-assembler
and scan-assembler-not regexps.
* gcc.target/i386/avx256-unaligned-load-2.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-4.c: Likewise.
* gcc.target/i386/l_fma_float_1.c: Use pattern for
scan-assembler-times instead of just one insn name.
* gcc.target/i386/l_fma_float_2.c: Likewise.
* gcc.target/i386/l_fma_float_3.c: Likewise.
* gcc.target/i386/l_fma_float_4.c: Likewise.
* gcc.target/i386/l_fma_float_5.c: Likewise.
* gcc.target/i386/l_fma_float_6.c: Likewise.
* gcc.target/i386/l_fma_double_1.c: Likewise.
* gcc.target/i386/l_fma_double_2.c: Likewise.
* gcc.target/i386/l_fma_double_3.c: Likewise.
* gcc.target/i386/l_fma_double_4.c: Likewise.
* gcc.target/i386/l_fma_double_5.c: Likewise.
* gcc.target/i386/l_fma_double_6.c: Likewise.

Modified:
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-2.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-3.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_6.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_6.c

[Bug preprocessor/58687] "#line LINE ..." changes subsequent line numbers

2013-10-30 Thread mtewoodbury at gmail dot com

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

--- Comment #11 from Max TenEyck Woodbury  ---
(In reply to Manuel López-Ibáñez from comment #10)
> 
> If you are planning to do sporadic GCC development, it may be worthwhile to
> ask for an account in the Compile Farm http://gcc.gnu.org/wiki/CompileFarm
> 
> (I could have never done any GCC development without it.)
> 
> For building GCC and testing patches there are several scripts in contrib/.
> I also have my own:
> http://gcc.gnu.org/wiki/
> ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming

Thank you, I will look info all of that.  My own resources have limits; when it
comes to testing generated code on many architectures, I will definitely need
such resources.

I will also look at the scripts after I have a bit better handle on exactly
what kinds of problems testing raise.  I was mildly surprised that changing
line numbers in headers produced differences in what is obviously generated
code.  Without having seen that buried deep in the build directory tree, I am
sure I would not appreciate any scripts that interact with that aspect of the
build process.

I am at the base of the learning curve here.  I have some climbing to do before
I will be able to make significant contributions...

'make check' on the un-patched sources in progress.  Later...

[Bug c++/29234] Call to operator() of temporary object wrongly parsed

2013-10-30 Thread paolo.carlini at oracle dot com

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

--- Comment #8 from Paolo Carlini  ---
Tentative patch here: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02536.html

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

2013-10-30 Thread paolo.carlini at oracle dot com

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

--- Comment #3 from Paolo Carlini  ---
At some point Ian Taylor filed a Bugzilla about these issues, I think it's
still open. Not sure what we should do in this area...

[Bug bootstrap/58918] [4.9 regression] cilk #includes alloc.h unconditionally, even when not present

2013-10-30 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |bviyer at gmail dot com

--- Comment #3 from Jeffrey A. Law  ---
I think the include ought to be wrapped inside an #ifdef HAVE_ALLOCA_H.  That's
the core issue here -- some systems simply don't have alloca.h.  So test for it
and only include it if it exists.

I agree with Joseph that XALLOCA isn't appropriate here.  Even  more so as GCC
is a downstream user of this library, so adding that kind of dependency simply
isn't going to fly.

[Bug middle-end/56341] GCC produces unaligned data access

2013-10-30 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-30
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.7.3, 4.8.0, 4.8.1, 4.9.0

--- Comment #14 from Ramana Radhakrishnan  ---
well, confirmed.

[Bug target/58423] [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard

2013-10-30 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from Ramana Radhakrishnan  ---
Fixed, presumably.

[Bug target/58847] ARM: emit NEON alignment hints for 32/16-bit accesses

2013-10-30 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
patches -> gcc-patc...@gcc.gnu.org

[Bug bootstrap/58918] [4.9 regression] cilk #includes alloc.h unconditionally, even when not present

2013-10-30 Thread joseph at codesourcery dot com

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

--- Comment #2 from joseph at codesourcery dot com  ---
XALLOCA is a libiberty macro, target libraries shouldn't be using 
libiberty headers.

[Bug preprocessor/58887] Allow recursion in variadic macros?

2013-10-30 Thread joseph at codesourcery dot com

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

--- Comment #12 from joseph at codesourcery dot com  ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:

> I think I understand consensus, but I only hear your voice here, not the voice
> of a multitude.  You may be part of the consensus you speak of, but you are 
> not

I was agreeing with Andrew.  Jason, the other maintainer likely to review 
libcpp patches, hasn't commented on this issue.  (There are plenty of 
others who *can* review such patches but are unlikely to do so in 
practice.)

That someone doesn't reply to some point (if they read it) only indicates, 
at most, that they do not have anything to add that has not already been 
said adequately somewhere in the totality of the discussion, rather than 
whether they agree or disagree.

> >> But that bug was filed on the wrong component and has languished for YEARS
> >> as a result of that miss-filing.  It looks like no one has looked at its
> >> problem seriously...
> > 
> > That maintainers wouldn't necessarily object to the addition of a feature 
> > doesn't mean any maintainer has any interest in implementing it.  There 
> > are lots of "bugs" filed suggesting some vaguely reasonable new feature 
> > that was of interest to the submitter but not of sufficient interest to 
> > anyone wanting to implement it (but not rejected either, because the 
> > feature might well be accepted if implemented).
> 
> I have worked for companies where there was a formal definition of roles, and
> what you describe is something from that world.  On the other hand, I believe
> open-source projects like GCC have less authoritarian structures and that such
> decisions are much less formal.  In other words, membership in 'maintainers' 
> is
> consensus based on merit, not the open and shut rule of corporate structure.

Bugs languish because the maintainers - and other developers who might fix 
them - are individuals, there is indeed no formal structure as regards 
reviewing bugs or assigning people to fix them, and each individual who 
looked at it was not interested in implementing the feature / fixing the 
bug.  Misfiling is only a minor part - it could be relevant, if someone 
had gone through all the "preprocessor" bugs, implementing lots of things, 
and missed that one because it wasn't a "preprocessor" bug - but it so 
happens no-one has been active in that way with preprocessor bugs lately.

Maintainers are appointed by the Steering Committee (based on merit) (but 
someone's views on a patch or feature can be relevant and useful without 
them being a maintainer who can approve the patch).

> As I said, I need to go over it carefully.  It is obviously pseudo-code and
> both the code and the explanation deserve careful study.  Where it has built 
> in
> the no-recursion rule was not quite obvious at first glance, thus the remark
> about hand waving.  Again, I need to study it carefully, and I have not done
> that yet...

No-recursion is built in through hide sets - that is, each token has at 
each time an associated set of names of macros that cannot be expanded if 
encountered when expanding that token.  Thus, when expanding a macro M, 
the name M is added to the hide sets of the tokens in the expansion before 
they, and the rest of the input, are considered for reexpansion (for 
details see the pseudocode).

Some discussions of C macro expansion use the term "blue paint" when 
discussing the rules for recursion.

Your proposal is apparently something that means a macro is no longer in 
or out of a hide set, but in a state meaning whether it can be expanded 
depends on the number of parameters.  Maybe the hide sets will need to 
contain pairs (macro, number of arguments), or something like that, 
instead of just macro names.

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Actually we can use this around the definition of default_delete<>

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wsystem-headers"
  /// Primary template of default_delete, used by unique_ptr
  template
struct default_delete
{
...
};
#pragma GCC diagnostic pop

[Bug preprocessor/58687] "#line LINE ..." changes subsequent line numbers

2013-10-30 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Max TenEyck Woodbury from comment #9)
> temporary file names, but I think that I can get past that.  It just takes
> hours for the builds to complete...

If you are planning to do sporadic GCC development, it may be worthwhile to ask
for an account in the Compile Farm http://gcc.gnu.org/wiki/CompileFarm

(I could have never done any GCC development without it.)

For building GCC and testing patches there are several scripts in contrib/. I
also have my own:
http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

2013-10-30 Thread wschmidt at gcc dot gnu.org

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

--- Comment #18 from Bill Schmidt  ---
spawn /home/wschmidt/gcc/build/gcc-mainline-test2/gcc/xgcc -B/home/wschmidt/gcc
/build/gcc-mainline-test2/gcc/ /home/wschmidt/gcc/gcc-mainline-test2/gcc/testsu
ite/gcc.dg/vect/vect-96.c -fno-diagnostics-show-caret -fdiagnostics-color=never
 -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -
fno-common -O2 -fdump-tree-vect-details -lm -m32 -o ./vect-96.exe
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-96.c: In f
unction 'main1':
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-96.c:16:5:
 internal compiler error: Segmentation fault
0x1068325b crash_signal
/home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:334
0x10c74f90 hash_table::elements()
/home/wschmidt/gcc/gcc-mainline-test2/gcc/hash-table.h:538
0x10c74f90 traverse<_vect_peel_extended_info*, vect_peeling_hash_get_most_frequ
ent>
/home/wschmidt/gcc/gcc-mainline-test2/gcc/hash-table.h:947
0x10c74f90 vect_peeling_hash_choose_best_peeling
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-data-refs.c:1248
0x10c74f90 vect_enhance_data_refs_alignment(_loop_vec_info*)
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-data-refs.c:1662
0x108cbc53 vect_analyze_loop_2
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-loop.c:1732
0x108cbc53 vect_analyze_loop(loop*)
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-loop.c:1810
0x108e750b vectorize_loops()
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vectorizer.c:360
0x107f866f tree_loop_vectorize
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-ssa-loop.c:149
0x107f866f execute
/home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-ssa-loop.c:184
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/58875] No float to int conversion warning in std::inner_product(x, x_end, y, 0)

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #1 from Jonathan Wakely  ---
Like PR58876 this is another case where you need -Wsystem-headers to get
warnings from within library code.

[Bug target/58784] [ARM] LRA legitimate address issue with misalign neon_store

2013-10-30 Thread vmakarov at gcc dot gnu.org

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

--- Comment #1 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Oct 30 15:04:39 2013
New Revision: 204215

URL: http://gcc.gnu.org/viewcvs?rev=204215&root=gcc&view=rev
Log:
2013-10-30  Vladimir Makarov  

PR target/58784
* lra.c (check_rtl): Remove address check before LRA work.

2013-10-30  Vladimir Makarov  

PR target/58784
* gcc.target/arm/pr58784.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr58784.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-30
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is because warnings are suppressed by default in system headers, and the
undefined delete operation occurs in a system header.  You get the warning if
you use -Wsystem-headers

I don't see an easy way to force the warning to always be emitted though.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

2013-10-30 Thread wschmidt at gcc dot gnu.org

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

--- Comment #17 from Bill Schmidt  ---
Initial news is not good -- I am seeing a lot of ICEs go by as the testing
proceeds, including in vect-96.c and vect-42.c.

[Bug other/58925] --enable-version-specific-runtime-libs breaks libcilk install

2013-10-30 Thread octoploid at yandex dot com

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

octoploid at yandex dot com changed:

   What|Removed |Added

 CC||bviyer at gmail dot com
Summary|libtool: install: error:|--enable-version-specific-r
   |cannot install  |untime-libs breaks libcilk
   |`libcilkrts.la' to a|install
   |directory not ending in |
   |/usr/lib/gcc/x86_64-pc-linu |
   |x-gnu/  |

--- Comment #1 from octoploid at yandex dot com ---
$ ../gcc/configure --enable-version-specific-runtime-libs --disable-bootstrap
--disable-werror --disable-multilib --enable-languages=c,c++

is enough to reproduce the issue.

[Bug c++/58848] constexpr function allows throw

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #3 from Jonathan Wakely  ---
The initializer for ReferenceElement::v calls the function in
a constant expression, but G++ doesn't diagnose it unless you instantiate that
member.

You get an error if you do:

int main() {
  return ReferenceElement::v;
}

[Bug c++/29234] Call to operator() of temporary object wrongly parsed

2013-10-30 Thread paolo.carlini at oracle dot com

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
  Known to fail||

--- Comment #7 from Paolo Carlini  ---
Looking into it.

[Bug c++/58796] throw nullptr not caught by catch(type*)

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I agree this looks like a bug. Reduced:

struct A {};
typedef int A::*PointerToMember;

int main() {
  try {
throw nullptr;
  } catch (PointerToMember) { // This *should* catch throw nullptr...
  }

  try {
throw nullptr;
  } catch(void *) { // This *should* catch throw nullptr...
  }
}

[Bug rtl-optimization/57100] [4.8/4.9 Regression] ICE: in pre_and_rev_post_order_compute, at cfganal.c:869 with -fdump-rtl-pro_and_epilogue-graph

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.9.0
 Resolution|--- |FIXED
   Target Milestone|4.8.3   |4.9.0
  Known to fail|4.8.1, 4.9.0|4.8.2

--- Comment #6 from Richard Biener  ---
Fixed for 4.9, not backporting.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

2013-10-30 Thread wschmidt at gcc dot gnu.org

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

--- Comment #16 from Bill Schmidt  ---
Thanks, testing in progress.

[Bug rtl-optimization/57100] [4.8/4.9 Regression] ICE: in pre_and_rev_post_order_compute, at cfganal.c:869 with -fdump-rtl-pro_and_epilogue-graph

2013-10-30 Thread rguenth at gcc dot gnu.org

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 30 14:22:01 2013
New Revision: 204211

URL: http://gcc.gnu.org/viewcvs?rev=204211&root=gcc&view=rev
Log:
2013-10-30  Richard Biener  

PR middle-end/57100
* basic-block.h (pre_and_rev_post_order_compute_fn): New function.
* cfganal.c (pre_and_rev_post_order_compute_fn): New function
as worker for ...
(pre_and_rev_post_order_compute): ... which now wraps it.
* graph.c (draw_cfg_nodes_no_loops): Use
pre_and_rev_post_order_compute_fn to avoid ICEing and dependence
on cfun.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/basic-block.h
trunk/gcc/cfganal.c
trunk/gcc/graph.c

[Bug libstdc++/58924] Non-member invocation of overload of operator<< when the first argument is a temporary of type std::stringstream

2013-10-30 Thread sir_nawaz959 at yahoo dot com

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

--- Comment #5 from Sarfaraz Nawaz  ---
(In reply to Fanael from comment #1)
> That's expected behavior AFAIU. 'operator<<(basic_ostream&&
> os, const T& x)' is a better match for const char[K] than
> 'basic_ostream& basic_ostream::operator<<(const
> void* p)', hence the former gets called, which then forwards the arguments
> to 'operator<<(basic_ostream&& os, const charT* x)'.


Oh. I didn't come across this overload. Great that they've added this.

Invalid bug.

[Bug libstdc++/58924] Non-member invocation of overload of operator<< when the first argument is a temporary of type std::stringstream

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
This is not a bug.

[Bug libstdc++/58912] make_shared value initializes storage space even when not desired

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-10-30
  Known to work||4.9.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
No, I don't think I did that for any good reason.

It's already fixed on trunk, due to some refactoring of the
_Sp_counted_ptr_inplace class, but I see no harm inremoving the init on the
active release branches.

[Bug c++/58477] [4.9 Regression] ice in cgraph_speculative_call_info

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/58418] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)

2013-10-30 Thread rguenth at gcc dot gnu.org

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

--- Comment #5 from Richard Biener  ---
*** Bug 58419 has been marked as a duplicate of this bug. ***

[Bug middle-end/58419] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Dup.

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

[Bug rtl-optimization/58384] [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-10-30
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Is it maybe fixed by the fix for PR58831?  I can't seem to pattern match
the assembler generated by trunk with your description anymore.

[Bug middle-end/58290] [4.9 Regression] error: virtual definition of statement not up-to-date

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #3 from Richard Biener  ---
Still broken - Honza?

[Bug c++/58924] Non-member invocation of overload of operator<< when the first argument is a temporary of type std::stringstream

2013-10-30 Thread daniel.kruegler at googlemail dot com

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

--- Comment #3 from Daniel Krügler  ---
(In reply to Fanael from comment #1)
I agree with Fanael: It is supposed to be that way in C++11 because of the
provided stream-rvalue support via

template 
basic_ostream&
operator<<(basic_ostream&& os, const T& x);

[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Assuming fixed.

[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
So, any progress here?

[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/58781] Unicode strings broken in a strange way

2013-10-30 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-30
 Ever confirmed|0   |1

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/58207] [4.7/4.8/4.9 Regression] ICE in sort_constexpr_mem_initializers due to out of bounds vector access

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug libstdc++/58764] [lwg/2193] error: converting to ‘const std::vector >’ from initializer list would use explicit constructor

2013-10-30 Thread redi at gcc dot gnu.org

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

--- Comment #7 from Jonathan Wakely  ---
IMHO following the precise wording of the standard is a mistake, the P/R is
obviously correct and fixing it for 4.9 is necessary. Just IMHO though :)

[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions

2013-10-30 Thread rguenth at gcc dot gnu.org

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

--- Comment #6 from Richard Biener  ---
Did you fix it?

[Bug tree-optimization/58121] [4.9 regression] FAIL: cc1224a

2013-10-30 Thread rguenth at gcc dot gnu.org

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

--- Comment #3 from Richard Biener  ---
I suppose a stack limit is necessary, might be 8MB for Andreas(?)

[Bug lto/58108] [4.9 regression] 32-bit g++.dg/torture/covariant-1.C -O2 -flto FAILs

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I think they are fixed.

[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I assume fixed.

[Bug tree-optimization/58069] [4.9 Regression] ICE in tree_ssa_unswitch_loops at -O3 in 32 bit mode

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
No longer reproduces, assuming fixed.

[Bug rtl-optimization/58048] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 Regression]|[4.8 Regression] internal
   |internal compiler error:|compiler error: Max. number
   |Max. number of generated|of generated reload insns
   |reload insns per insn is|per insn is achieved (90)
   |achieved (90)   |
  Known to fail|4.8.1, 4.9.0|4.8.2

--- Comment #13 from Richard Biener  ---
2013-08-02  Vladimir Makarov  

PR rtl-optimization/58048
* lra-constraints.c (process_alt_operands): Don't check asm
operand on register.

fixed on trunk sofar.

[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

2013-10-30 Thread pa...@matos-sorge.com

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

Paulo J. Matos  changed:

   What|Removed |Added

 CC||pa...@matos-sorge.com

--- Comment #8 from Paulo J. Matos  ---
(In reply to Teresa Johnson from comment #7)
> This looks like a separate issue from the edge probability issue that I
> fixed. The edge probability issue was introduced earlier. Almost certainly
> due to the following change, given that you noticed it at r203899 and it is
> an error about edge badness:
> 
> 
> r203897 | pmatos | 2013-10-21 08:41:46 -0700 (Mon, 21 Oct 2013) | 4 lines
> Changed paths:
>M /trunk/gcc/ChangeLog
>M /trunk/gcc/ipa-inline.c
> 
> * ipa-inline.c (edge_badness): Cap edge->count at max_count for
> badness
> calculations.
> 
> 
> 
> 
> Adding author to cc.
> 
> Teresa

Thanks for adding me to CC. I will try to confirm if it was my patch.

[Bug middle-end/57955] [4.7/4.8/4.9 Regression] Uniquization of constants reduces alignment of initializers

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #6 from Richard Biener  ---
Can you point to a revision that broke this?  Can you verify if adding
-fno-common fixes it?

With a simple cross I do see lvx instructions both with -m32 and -m64.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

2013-10-30 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Honza?

1 2 >

1 - 100 of 161 matches

Mail list logo