[Bug target/55701] Inline some instances of memset for ARM

2014-06-10 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00182.html

Bin might have a patch that fixes this under review.


[Bug target/56313] aarch64 backend not using fmls instruction

2014-06-10 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56313

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #3 from Ramana Radhakrishnan  ---
4.9 and trunk both generate. 


foo:
adrpx0, .LANCHOR0
add x0, x0, :lo12:.LANCHOR0
add x2, x0, 8
add x1, x0, 16
ldr d0, [x0]
ldr d2, [x2]
ldr d1, [x1]
fmlsv0.2s, v2.2s, v1.2s
str d0, [x0]
ret


[Bug other/61460] New: Demangler crash (GDB PR 17043)

2014-06-10 Thread gbenson at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61460

Bug ID: 61460
   Summary: Demangler crash (GDB PR 17043)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gbenson at redhat dot com

The demangler crashes when given this symbol:

_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeINS_9addressesEINS2_IRFRNS_5eventEP9_cl_eventEINS_14iterator_rangeIPKS7_NS0_16iterator_adaptorIS3_INSG_IS9_ISC_EESI_EcvT_ISt6vectorIPS4_SaISN_EEvEEv

See https://sourceware.org/bugzilla/show_bug.cgi?id=17043


[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

2014-06-10 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56924

--- Comment #2 from Ramana Radhakrishnan  ---

trunk and FSF 4.9.0 currently generates on ARM. 

and r0, r0, #224
cmp r0, #224
bxnelr
b   bar


which looks way better than what 4.8 generates.

I'm not sure what fixed this but this certainly looks much better already.


[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7

2014-06-10 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446

--- Comment #3 from Uroš Bizjak  ---
Proposed patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00775.html

[Bug middle-end/61456] Bogus "may be used uninitialized" warning

2014-06-10 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-10
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #3)
> >Note that there is no '__delta' in the original source, so the error message
> Well that is partly the front-end issue as it is pointer to member functions
> are implemented using a struct.

The FE should mark these compiler-generated declarations as artificial or some
such to avoid warning about them.

[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope

2014-06-10 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Schwinge  ---
Fixed in r211401.


[Bug middle-end/61456] Bogus "may be used uninitialized" warning

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
Hmm.

This is running into nonoverlapping_component_refs_of_decl_p which has

(gdb) p field1
$32 = 
(gdb) p field2
$33 = 

but they are clearly on the same offset and have the same size.  They
are members of different types (but same TYPE_MAIN_VARIANT) and appearantly
the TYPE_FIELDs of the variants are not shared.

So appearantly it is not safe to drop to TYPE_MAIN_VARIANT here (and in
nonoverlapping_component_refs_p).  But it's also not necessary - if the
TYPE_FILEDs are shared then the DECL_FIELD_CONTEXT of course points to the
same type already.


[Bug tree-optimization/61452] [4.8/4.9/4.10 Regression] hang at -O1 and -Os on x86_64-linux-gnu

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-06-10
  Known to work||4.7.4
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.8.4
Summary|hang at -O1 and -Os on  |[4.8/4.9/4.10 Regression]
   |x86_64-linux-gnu|hang at -O1 and -Os on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed (value-numbering).


[Bug middle-end/61456] Bogus "may be used uninitialized" warning

2014-06-10 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

--- Comment #6 from Manuel López-Ibáñez  ---
And this is a regression. We did not warn with r197260.

[Bug middle-end/61456] [4.9/4.10 Regression] Bogus "may be used uninitialized" warning

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.3
   Target Milestone|--- |4.9.1
Summary|Bogus "may be used  |[4.9/4.10 Regression] Bogus
   |uninitialized" warning  |"may be used uninitialized"
   ||warning


[Bug other/61439] contrib/download_prerequisites script does not verify integrity of packages

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61439

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Patches welcome.


[Bug tree-optimization/61438] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in loop_preheader_edge, at cfgloop.c:1668

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61438

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-06-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0
Summary|ICE on valid code at -O3 on |[4.10 Regression] ICE on
   |x86_64-linux-gnu in in  |valid code at -O3 on
   |loop_preheader_edge, at |x86_64-linux-gnu in in
   |cfgloop.c:1668  |loop_preheader_edge, at
   ||cfgloop.c:1668
 Ever confirmed|0   |1

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


[Bug regression/61436] [4.10 Regression]: g++.dg/tls/diag-1.C ICE (emutls)

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61436

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0


[Bug tree-optimization/61437] [4.10 Regression] wrong code on x86_64-linux-gnu when compile separately

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61437

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Eric has already posted a similar testcase and I have a patch.


[Bug c++/61433] [4.9/4.10 Regression] ICE: SIGSEGV in friend_accessible_p (search.c:778) with -std=gnu++11 -O -fcompare-debug -fno-inline -fno-ipa-pure-const -fipa-sra

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61433

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.1


[Bug libfortran/60324] Handle arbitrarily long path names

2014-06-10 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #5 from Janne Blomqvist  ---
There are still a number of cases (IO intrinsics, mostly) where we create a
null-terminated copy of a potentially unbounded input string on the stack,
leading to a potential stack overflow crash. But the stack limit is usually
several MB versus a few KB for PATH_MAX, so unlikely to be an issue in
practice.


[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

2014-06-10 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-10
 CC||dodji at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
I can reproduce it in trunk using:

#pragma GCC system_header
#define FOO(a, b) __LINE__;

I think the problem is that there is a push of the system-header-ness flag on
the expansion of the macro, but there is no pop to restore
non-system-header-ness.

That is, we generate:

# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "test.h" 1

# 2 "test.h" 3
# 2 "test.c" 2

int main()
{

 6
# 5 "test.c" 3
  ;
;
  char* a = 1;
}

but we should generate:

# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "test.h" 1

# 2 "test.h" 3
# 2 "test.c" 2

int main()
{

 6
# 5 "test.c" 3
  ;
# 6 "test.c"
;
  char* a = 1;
}

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

2014-06-10 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

--- Comment #4 from Manuel López-Ibáñez  ---
The meaning of the flags is given here:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html#Preprocessor-Output

[Bug tree-optimization/57186] implement load sinking in loops

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57186

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 10 10:29:44 2014
New Revision: 211404

URL: http://gcc.gnu.org/viewcvs?rev=211404&root=gcc&view=rev
Log:
2014-06-10  Richard Biener  

PR tree-optimization/57186
PR tree-optimization/59299
* gcc.dg/tree-ssa/ssa-sink-11.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-12.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-12.c
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/59299] We do not sink loads

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59299

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 10 10:29:44 2014
New Revision: 211404

URL: http://gcc.gnu.org/viewcvs?rev=211404&root=gcc&view=rev
Log:
2014-06-10  Richard Biener  

PR tree-optimization/57186
PR tree-optimization/59299
* gcc.dg/tree-ssa/ssa-sink-11.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-12.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-12.c
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/61452] [4.8/4.9/4.10 Regression] hang at -O1 and -Os on x86_64-linux-gnu

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452

--- Comment #2 from Richard Biener  ---
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
...

e.1_6 is a "better" leader for f.7_12.

Ok, one reason is that even though we don't change the lattice value
of the PHI g_1 = PHI  from g_1 (varying) to g_10 in the
7th (for example) iteration we _do_ adjust its ->expr and thus simplify
expressions differently.  That's of course a no-no, if the lattice
value doesn't change it may really not change.

The whole dance visit_phi does with trying to set ->expr and ->has_constants
when it figured out a leader is pointless anyway - those are only relevant
for VARYINGs (in which case they are bogus).


[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

2014-06-10 Thread dominiq at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Jun 10 11:42:38 2014
New Revision: 211405

URL: http://gcc.gnu.org/viewcvs?rev=211405&root=gcc&view=rev
Log:
2014-06-10  Dominique d'Humieres 
Mikael Morin 

PR fortran/41936
gcc/fortran/
* trans-expr.c (gfc_conv_expr_reference): Deallocate array
components.

gcc/testsuite/
* gfortran.dg/class_array_15.f03: Check memory leaks.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_15.f03


[Bug rtl-optimization/61461] New: -fdump-rtl-all-slim causes ICE with fold-const.c

2014-06-10 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61461

Bug ID: 61461
   Summary: -fdump-rtl-all-slim causes ICE with fold-const.c
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

When I try to print the dumps of fold-const.c
with -fdump-rtl-all-slim cc1plus crashes:


/home/ed/gnu/gcc-build/./gcc/xg++ -B/home/ed/gnu/gcc-build/./gcc/
-B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/ed/gnu/gcc-4.10-20140608/libstdc++-v3/libsupc++
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.10-20140608/gcc -I../../gcc-4.10-20140608/gcc/.
-I../../gcc-4.10-20140608/gcc/../include
-I../../gcc-4.10-20140608/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp
-I/home/ed/gnu/gcc-4.10-20140608/gmp -I/home/ed/gnu/gcc-build/./mpfr
-I/home/ed/gnu/gcc-4.10-20140608/mpfr -I/home/ed/gnu/gcc-4.10-20140608/mpc/src 
-I../../gcc-4.10-20140608/gcc/../libdecnumber
-I../../gcc-4.10-20140608/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-4.10-20140608/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-build/./cloog/include
-I/home/ed/gnu/gcc-4.10-20140608/cloog/include
-I../gcc-4.10-20140608/cloog/include  -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-4.10-20140608/isl/include  -o fold-const.o -MT fold-const.o
-MMD -MP -MF ./.deps/fold-const.TPo ../../gcc-4.10-20140608/gcc/fold-const.c
-fdump-rtl-all-slim
../../gcc-4.10-20140608/gcc/fold-const.c: In function 'bool
negate_mathfn_p(built_in_function)':
../../gcc-4.10-20140608/gcc/fold-const.c:353:1: internal compiler error:
Segmentation fault
 }
 ^
0xbeabcf crash_signal
../../gcc-4.10-20140608/gcc/toplev.c:337
0x11a41c0 pp_string(pretty_printer*, char const*)
../../gcc-4.10-20140608/gcc/pretty-print.c:906
0xb9ffc2 print_exp
../../gcc-4.10-20140608/gcc/sched-vis.c:391
0xba0afd print_value(pretty_printer*, rtx_def const*, int)
../../gcc-4.10-20140608/gcc/sched-vis.c:510
0xb9fb08 print_pattern(pretty_printer*, rtx_def const*, int)
../../gcc-4.10-20140608/gcc/sched-vis.c:620
0xb9f83b print_insn(pretty_printer*, rtx_def const*, int)
../../gcc-4.10-20140608/gcc/sched-vis.c:743
0xb9fa17 print_insn_with_notes
../../gcc-4.10-20140608/gcc/sched-vis.c:764
0xba0d4e dump_insn_slim(_IO_FILE*, rtx_def const*)
../../gcc-4.10-20140608/gcc/sched-vis.c:801
0x8a09f7 print_rtl_with_bb(_IO_FILE*, rtx_def const*, int)
../../gcc-4.10-20140608/gcc/cfgrtl.c:2196
0xb32e73 execute_function_dump
../../gcc-4.10-20140608/gcc/passes.c:1569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

-fdump-rtl-all-all does not crash, but it produces a 36GB large
fold-const.c.238r.vartrack file.


[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227

--- Comment #11 from Richard Biener  ---
I think there is no good way apart from treating single-element structs equal
to its single element in LTO with regarding to TYPE_CANONICAL.  At least not if
you want to inter-operate with both int i; and struct { int i; }.  Otherwise
I'd lean towards not using a struct in Fortran for single-element commons.
That should be an implementation detail anyways.

> Unfortunately, the idiom "use a single variable common block, say common/x/y,
> access it via the name of the common block, followed by an underscore, say x_"
> is also common.  At least in my workplace it's the way everybody uses.

But then simply name the symbol of the variable without a struct in that way,
no?


[Bug preprocessor/60723] Line directives with incorrect system header flag

2014-06-10 Thread matt at godbolt dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723

--- Comment #8 from Matt Godbolt  ---
Thanks Nicholas :)


[Bug middle-end/61456] [4.9/4.10 Regression] Bogus "may be used uninitialized" warning

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 10 14:10:57 2014
New Revision: 211411

URL: http://gcc.gnu.org/viewcvs?rev=211411&root=gcc&view=rev
Log:
2014-06-10  Richard Biener  

PR middle-end/61456
* tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p):
Do not use the main variant for the type comparison.
(ncr_compar): Likewise.
(nonoverlapping_component_refs_p): Likewise.

* g++.dg/opt/pr61456.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr61456.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c


[Bug middle-end/61456] [4.9/4.10 Regression] Bogus "may be used uninitialized" warning

2014-06-10 Thread tejohnson at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

--- Comment #8 from Teresa Johnson  ---
Thanks for the quick fix. Do you know if this fixed the issue I
reported in comment #2 (seg fault in a similar test case)?

Teresa

On Tue, Jun 10, 2014 at 7:11 AM, rguenth at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
>
> --- Comment #7 from Richard Biener  ---
> Author: rguenth
> Date: Tue Jun 10 14:10:57 2014
> New Revision: 211411
>
> URL: http://gcc.gnu.org/viewcvs?rev=211411&root=gcc&view=rev
> Log:
> 2014-06-10  Richard Biener  
>
> PR middle-end/61456
> * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p):
> Do not use the main variant for the type comparison.
> (ncr_compar): Likewise.
> (nonoverlapping_component_refs_p): Likewise.
>
> * g++.dg/opt/pr61456.C: New testcase.
>
> Added:
> trunk/gcc/testsuite/g++.dg/opt/pr61456.C
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/tree-ssa-alias.c
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.


[Bug tree-optimization/61438] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in loop_preheader_edge, at cfgloop.c:1668

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61438

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 10 14:18:50 2014
New Revision: 211413

URL: http://gcc.gnu.org/viewcvs?rev=211413&root=gcc&view=rev
Log:
2014-06-10  Richard Biener  

PR tree-optimization/61438
* tree-ssa-pre.c (eliminate_dom_walker): Add do_pre member.
(eliminate_dom_walker::before_dom_children): Only try to inhibit
insertion of IVs if running PRE.
(eliminate): Adjust.
(pass_pre::execute): Likewise.
(pass_fre::execute): Likewise.

* gcc.dg/torture/pr61438.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr61438.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c


[Bug middle-end/61456] [4.9/4.10 Regression] Bogus "may be used uninitialized" warning

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

--- Comment #9 from Richard Biener  ---
(In reply to Teresa Johnson from comment #8)
> Thanks for the quick fix. Do you know if this fixed the issue I
> reported in comment #2 (seg fault in a similar test case)?

I didn't check but I guess so.

> Teresa
> 
> On Tue, Jun 10, 2014 at 7:11 AM, rguenth at gcc dot gnu.org
>  wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
> >
> > --- Comment #7 from Richard Biener  ---
> > Author: rguenth
> > Date: Tue Jun 10 14:10:57 2014
> > New Revision: 211411
> >
> > URL: http://gcc.gnu.org/viewcvs?rev=211411&root=gcc&view=rev
> > Log:
> > 2014-06-10  Richard Biener  
> >
> > PR middle-end/61456
> > * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p):
> > Do not use the main variant for the type comparison.
> > (ncr_compar): Likewise.
> > (nonoverlapping_component_refs_p): Likewise.
> >
> > * g++.dg/opt/pr61456.C: New testcase.
> >
> > Added:
> > trunk/gcc/testsuite/g++.dg/opt/pr61456.C
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/testsuite/ChangeLog
> > trunk/gcc/tree-ssa-alias.c
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.


[Bug tree-optimization/61438] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in loop_preheader_edge, at cfgloop.c:1668

2014-06-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61438

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug middle-end/61462] New: ICE in ipa-prop.c:2562 caused by missing edge gimple call stmt

2014-06-10 Thread mliska at suse dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61462

Bug ID: 61462
   Summary: ICE in ipa-prop.c:2562 caused by missing edge gimple
call stmt
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

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

Problem was met during run of gimp with following flags:
'-flto -fdump-ipa-all'.

backtrace:
lto1: internal compiler error: Segmentation fault
0x8321af crash_signal
../../gcc/toplev.c:337
0x6e5297 gimple_location
../../gcc/gimple.h:1499
0x6ebe06 ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*)
../../gcc/ipa-prop.c:2562
0xc923a1 ipcp_discover_new_direct_edges
../../gcc/ipa-cp.c:2373
0xc923a1 create_specialized_node
../../gcc/ipa-cp.c:2821
0xc96b7f decide_whether_version_node
../../gcc/ipa-cp.c:3557
0xc96b7f ipcp_decision_stage
../../gcc/ipa-cp.c:3669
0xc96b7f ipcp_driver
../../gcc/ipa-cp.c:3715
0xc96b7f execute
../../gcc/ipa-cp.c:3807

Problem is that in LTO there's a virtual 'constprop' clone created by ipa-cp.
An edge for this newly created node has e->stmt == NULL.

Introduced in 210657.


[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

2014-06-10 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
The test g++.dg/debug/dwarf2/imported-decl-2.C introduced in r211151 fails on
darwin:

FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++98  scan-assembler-times
ascii "0".*ascii "0".*DIE .0x[0-9a-f]*.
DW_TAG_imported_declaration 1
FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++11  scan-assembler-times
ascii "0".*ascii "0".*DIE .0x[0-9a-f]*.
DW_TAG_imported_declaration 1
FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++1y  scan-assembler-times
ascii "0".*ascii "0".*DIE .0x[0-9a-f]*.
DW_TAG_imported_declaration 1

There is no 'DW_TAG_imported_declaration' emitted in the assembly.


[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7

2014-06-10 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446

--- Comment #4 from Dominique d'Humieres  ---
> Proposed patch at [1].
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00775.html

This patch fixes bootstrap on Core* targets.


[Bug middle-end/61456] [4.9 Regression] Bogus "may be used uninitialized" warning

2014-06-10 Thread tejohnson at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456

--- Comment #10 from Teresa Johnson  ---
On Tue, Jun 10, 2014 at 7:38 AM, rguenth at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
>
> --- Comment #9 from Richard Biener  ---
> (In reply to Teresa Johnson from comment #8)
>> Thanks for the quick fix. Do you know if this fixed the issue I
>> reported in comment #2 (seg fault in a similar test case)?
>
> I didn't check but I guess so.

I just rebuilt with r211411 and confirmed that it fixes that issue as well.

Thanks,
Teresa

>
>> Teresa
>>
>> On Tue, Jun 10, 2014 at 7:11 AM, rguenth at gcc dot gnu.org
>>  wrote:
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
>> >
>> > --- Comment #7 from Richard Biener  ---
>> > Author: rguenth
>> > Date: Tue Jun 10 14:10:57 2014
>> > New Revision: 211411
>> >
>> > URL: http://gcc.gnu.org/viewcvs?rev=211411&root=gcc&view=rev
>> > Log:
>> > 2014-06-10  Richard Biener  
>> >
>> > PR middle-end/61456
>> > * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p):
>> > Do not use the main variant for the type comparison.
>> > (ncr_compar): Likewise.
>> > (nonoverlapping_component_refs_p): Likewise.
>> >
>> > * g++.dg/opt/pr61456.C: New testcase.
>> >
>> > Added:
>> > trunk/gcc/testsuite/g++.dg/opt/pr61456.C
>> > Modified:
>> > trunk/gcc/ChangeLog
>> > trunk/gcc/testsuite/ChangeLog
>> > trunk/gcc/tree-ssa-alias.c
>> >
>> > --
>> > You are receiving this mail because:
>> > You are on the CC list for the bug.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.


[Bug c++/61463] New: g++ does not emit DW_AT_mutable

2014-06-10 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61463

Bug ID: 61463
   Summary: g++ does not emit DW_AT_mutable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

DW_AT_mutable is defined by DWARF but g++ does not seem to emit it.

I tried

struct K
{
  mutable int x;
};

K k;

For "x" I see:

 <2><23>: Abbrev Number: 3 (DW_TAG_member)
<24>   DW_AT_name: x
<26>   DW_AT_decl_file   : 1
<27>   DW_AT_decl_line   : 3
<28>   DW_AT_type: <0x2e>   
<2c>   DW_AT_data_member_location: 0


[Bug libstdc++/61464] New: regex pattern using brackets throws error in constructor

2014-06-10 Thread yuecat0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61464

Bug ID: 61464
   Summary: regex pattern using brackets throws error in
constructor
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuecat0 at gmail dot com

g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

Compiler command:
g++ -std=c++11 test.cpp -Wall -Wextra -o Test

Compiler output:
N/A

Program command:
./Test

Program output:
error_brack


It seems that the standard library implementation of regex that is being used
is flawed.
The regex pattern "([a-z])" does not compile, and instead throws an
std::regex_error with the std::regex_constants::brack code. This same pattern
does compile using the Boost regex library, and I am unaware of any obvious
flaw in its simple structure.


[Bug libstdc++/61464] regex pattern using brackets throws error in constructor

2014-06-10 Thread yuecat0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61464

--- Comment #1 from Yue  ---
I am unable to paste the preprocessed file that causes this issue at the
moment, as it is too large. However, I believe it can be easily reproduced.
If I can find a place to store the file, I will attach it as soon as I am able.


[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

2014-06-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551

--- Comment #13 from Marc Glisse  ---
Created attachment 32915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32915&action=edit
simplify vec_select(vec_concat)

A simpler/safer version of the patch linked in comment #12 (untested). It
optimizes the example in comment #11, but fails to optimize the original
testcase because simplify-rtx operations are only done on single-use operands,
and I don't know where in the RTL optimizers we can apply transformations
without this constraint.


[Bug libstdc++/53631] [C++11] is unimplemented

2014-06-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug libstdc++/53631] [C++11] is unimplemented

2014-06-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631

Jonathan Wakely  changed:

   What|Removed |Added

 CC||yuecat0 at gmail dot com

--- Comment #18 from Jonathan Wakely  ---
*** Bug 61464 has been marked as a duplicate of this bug. ***


[Bug libstdc++/61464] regex pattern using brackets throws error in constructor

2014-06-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61464

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
GCC 4.8.2 doesn't support 

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


[Bug tree-optimization/61289] [4.9 Regression] Bad jump threading generates infinite loop

2014-06-10 Thread ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289

--- Comment #4 from Paul Pluzhnikov  ---
Back-port to gcc-4_9-branch?

Thanks,


[Bug c++/17267] Reuse of template parameter name not diagnosed

2014-06-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17267

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Last reconfirmed|2006-02-26 19:40:00 |2014-6-10
  Known to fail||

--- Comment #3 from Jonathan Wakely  ---
14.6.1 [temp.local]
-6- A template-parameter shall not be redeclared within its scope (including
nested scopes). A template-parameter shall not have the same name as the
template name.


[Bug tree-optimization/61289] [4.9 Regression] Bad jump threading generates infinite loop

2014-06-10 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289

--- Comment #5 from Jeffrey A. Law  ---
yes, I'll backport to the 4.9 branch.  Waiting to see if there's any
follow-ups.


[Bug libstdc++/61390] error in nested template parameter in ext/pb_ds header file

2014-06-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61390

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Jun 10 18:09:18 2014
New Revision: 211421

URL: http://gcc.gnu.org/viewcvs?rev=211421&root=gcc&view=rev
Log:
PR libstdc++/61390
* include/ext/pb_ds/detail/bin_search_tree_/traits.hpp
(bin_search_tree_traits): Do not redeclare template-parameters.
* testsuite/util/testsuite_iterators.h (test_container): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/traits.hpp
trunk/libstdc++-v3/testsuite/util/testsuite_iterators.h


[Bug c++/61465] New: Bogus parameter set but not used warning in constructor initialization list

2014-06-10 Thread fanael4 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61465

Bug ID: 61465
   Summary: Bogus parameter set but not used warning in
constructor initialization list
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fanael4 at gmail dot com

When compiling the following code with C++11 and -Wunused-but-set-parameter on

struct Foo {
  Foo(void* x) : y{static_cast(x)} {}
  char* y;
};

GCC (tested on 4.7.0 and 4.9.1) incorrectly complains:

x.cpp:2:13: warning: parameter 'x' set but not used
[-Wunused-but-set-parameter]

Which is clear nonsense, as the parameter is used. If the initialization list
is changed to use parentheses, or the static_cast is removed and y's type is
changed, the warning goes away.


[Bug ada/61466] New: Array index check optimized away

2014-06-10 Thread simon at pushface dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61466

Bug ID: 61466
   Summary: Array index check optimized away
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org

Created attachment 32916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32916&action=edit
Source code (package spec/body, main procedure)

In the attached code, the index check in procedure Violate on the “Output: out
Arr” parameter is present with -O0 but is omitted with higher levels. This is
clearly visible with -gnatG:

-O0:

  L_1 : for j in input'first .. input'last loop
 B_2 : declare
[constraint_error when
  not (integer(j) in modifier'first .. modifier'last)
  "index check failed"]
product : constant integer := modifier (j);
 begin
[constraint_error when
  not (integer(j) in output'first .. output'last)
  "index check failed"]
output (j) := product / 2;
 end B_2;
  end loop L_1;

-O1:

  L_1 : for j in input'first .. input'last loop
 B_2 : declare
[constraint_error when
  not (integer(j) in modifier'first .. modifier'last)
  "index check failed"]
product : constant integer := modifier (j);
 begin
output (j) := product / 2;
 end B_2;
  end loop L_1;

The bug is present at least in GCC 4.6 on Debian and GCC 4.7 .. 4.9 on Mac OS
X, also in GNAT GPL 2012 .. 2014.

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

2014-06-10 Thread simon at pushface dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

--- Comment #1 from simon at pushface dot org ---
Same problem with “gnatchop -h” (which, in this case, exits via an exception):

[...]
exception
   when Types.Terminate_Program =>
  null;

end Gnatchop;

[Bug libstdc++/29988] More stl_tree.h enhancements: improving operator=

2014-06-10 Thread fdumont at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29988

François Dumont  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0

--- Comment #1 from François Dumont  ---
I am working on a patch to reuse nodes. Not only for the copy assignment but
also for C++11 move assignment and assignment from initialization list.

[Bug c/53131] -Wlogical-op: ready for prime time in -Wall ?

2014-06-10 Thread P at draigBrady dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131
Bug 53131 depends on bug 43772, which changed state.

Bug 43772 Summary: Errant -Wlogical-op warning when testing limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772

   What|Removed |Added

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


[Bug c/43772] Errant -Wlogical-op warning when testing limits

2014-06-10 Thread P at draigBrady dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772

Pádraig Brady  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.2
 Resolution|--- |FIXED
  Known to fail||4.6.3

--- Comment #23 from Pádraig Brady  ---
This is fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187194

To see where it was first released we can quickly see the tags at:
  https://github.com/mirrors/gcc/commit/686369e8
Which indicates this was fixed as part of the 4.8.0 release.

I've confirmed it's OK in gcc 4.8.2

[Bug fortran/45187] ICE with CRAY pointer in module

2014-06-10 Thread billy.baker at cox dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187

--- Comment #6 from Billy Baker  ---
Thank you. Glad it was a simple change.