[Bug c/11751] wrong evaluation order of an expression

2014-04-08 Thread elizbathjames at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751

Elizbath Martin  changed:

   What|Removed |Added

 CC||elizbathjames at gmail dot com

--- Comment #87 from Elizbath Martin  ---
For the good expansion order make a step by step working Like when go for the
buying of the juicer/blender 
http://zinch.zendesk.com/entries/31114770-Locating-Smoothie-Makers-In-Low-price
customer feedback is the key of the success. So For the right order of the
expansion an expert advice can work better for you.


[Bug libstdc++/50160] vector comparison very slow (no overload)

2014-04-08 Thread elizbathjames at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Elizbath Martin  changed:

   What|Removed |Added

 CC||elizbathjames at gmail dot com

--- Comment #40 from Elizbath Martin  ---
Key factors might be the reason due to which its showing slow behavior. Make a
class of it and use it for the simple.
https://sourceforge.net/projects/working-of-smoothie-machines/ sometimes they
shows the abnormal behavior their might be list of reason you have to Go for.


[Bug libgcc/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.

2014-04-08 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|go  |libgcc
 Resolution|--- |INVALID
   Assignee|ian at airs dot com|unassigned at gcc dot 
gnu.org

--- Comment #2 from Andrew Pinski  ---
It is better if you just link directly against libatomic.  We already require
that for C11 _Atomic support in some/most cases.

>We followed an approach similar to libgo 

libgo needs to be fixed the same way really.


[Bug c/59073] [4.9 Regression] ICE with missing increment in OpenMP for-loop

2014-04-08 Thread asolokha at gmx dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59073

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
Cannot reproduce it w/ 4.9.0 20140406.


[Bug go/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.

2014-04-08 Thread gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790

Gary Funck  changed:

   What|Removed |Added

  Attachment #32569|0   |1
is obsolete||

--- Comment #1 from Gary Funck  ---
Created attachment 32570
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32570&action=edit
libatomic cpuinfo patch

Test for edx when checking bit_CMPXCHG8B.


[Bug go/60790] New: libatomic convenience library selects IFUNC implementation before obtaining cpu info.

2014-04-08 Thread gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790

Bug ID: 60790
   Summary: libatomic convenience library selects IFUNC
implementation before obtaining cpu info.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: gary at intrepid dot com
CC: nenad at intrepid dot com, PHHargrove at lbl dot gov,
rth at gcc dot gnu.org

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

We ran into this issue recently while implementing atomic memory support for
GNU UPC.  We followed an approach similar to libgo -- we included
libatomic_convenience.a into libgupc.a.  This lets libgupc access GCC's
__atomic support without requiring the user to link explicitly with libatomic.

While debugging the UPC AMO library on a modern X86-64 platform, we noticed
that the locked implementation of compare-exchange-16 was being used in spite
of the fact of that the CPU supports the CMPX16 operation directly.

We determined that the IFUNC selector function was being called before the
constructor function in init.c had run.  Thus the libat_feat1_ecx variable was
zero.  Because the feature bit wasn't set, the selector function chose the CAS
function which requires explicit locks.  Interestingly,
__atomic_is_lock_free(16, NULL) returns true, as expected on this platform
because it is called after the init_cpuid() constructor is called.

One way to fix this issue is to re-work the logic that queries the CPU feature
register value, so that it explicitly initializes the value if it is zero.  The
assumption here is that __get_cpuid() will always return a non-zero value in
the ECX feature register.  A patch that implements this approach is attached.


[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter

2014-04-08 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115

Paolo Carlini  changed:

   What|Removed |Added

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

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


[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter

2014-04-08 Thread paolo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Apr  9 00:09:28 2014
New Revision: 209230

URL: http://gcc.gnu.org/viewcvs?rev=209230&root=gcc&view=rev
Log:
/cp
2014-04-08  Paolo Carlini  

PR c++/59115
* pt.c (process_template_parm): For an invalid non-type parameter
only set TREE_TYPE to error_mark_node.
(push_inline_template_parms_recursive, comp_template_parms,
redeclare_class_template, coerce_template_template_parm,
coerce_template_template_parms, unify): Use error_operand_p.

/testsuite
2014-04-08  Paolo Carlini  

PR c++/59115
* g++.dg/template/crash119.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/crash119.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


[Bug fortran/60781] cannot match namelist object name

2014-04-08 Thread sgk at troutmask dot apl.washington.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781

--- Comment #9 from Steve Kargl  ---
> 
> Is this what you meant by the 'curly quotes'?
> 

No.  Your input file contains curly quotes.  I've
changed the curly quotes to # show you where the
problem lies.

  met_file = #met_04270_62_65.txt#

Compare the quoting for vegh_file and met_file.  You need
to use ASCII character 39.  Looks like your input file is
using extended ASCII characters 145 and 146.  gfortran is
expected ASCII not extended ASCII.


[Bug fortran/60781] cannot match namelist object name

2014-04-08 Thread lauraelcomeau at yahoo dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781

--- Comment #8 from Laura C  ---
I've tried changing the Input.f90 code to 

character(len=70) :: &
  dem_file='',  &! Elevation file name
  met_file='',  &! Driving data file name
  vegf_file='', &! Vegetation fraction file name
  vegh_file='', &! Vegetation height file name
  wind_file='', &! Wind distribution file name
  RunID=''   ! Run identifier

i.e adding the ='' into the code, but I still get the same namelist error.
Is this what you meant by the 'curly quotes'?

Laura


[Bug fortran/60781] cannot match namelist object name

2014-04-08 Thread lauraelcomeau at yahoo dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781

--- Comment #7 from Laura C  ---
I've tried changing the Input.f90 code to 

character(len=70) :: &
  dem_file='',  &! Elevation file name
  met_file='',  &! Driving data file name
  vegf_file='', &! Vegetation fraction file name
  vegh_file='', &! Vegetation height file name
  wind_file='', &! Wind distribution file name
  RunID=''   ! Run identifier

i.e adding the ='' into the code, but I still get the same namelist error.
Is this what you meant by the 'curly quotes'?

Laura


[Bug ada/60411] ADA bootstrap failure on ARM

2014-04-08 Thread gnugcc at marino dot st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #12 from John Marino  ---
I am also seeing these errors:

s-intman.adb:263:32: "SA_NODEFER" is not visible
s-intman.adb:263:32: non-visible declaration at s-linux.ads:110
s-intman.adb:263:45: "SA_RESTART" is not visible
s-intman.adb:263:45: non-visible declaration at s-linux.ads:109


[Bug ada/60411] ADA bootstrap failure on ARM

2014-04-08 Thread gnugcc at marino dot st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

John Marino  changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #11 from John Marino  ---
Eric,
Thanks for these commits.  However, I'm still unable to build
arm-aux-linux-androideabi cross-compiler target after 209227.

This is the current error:
s-osinte.ads:593:07: component "sa_flags" overlaps "sa_mask" at line 592

This happens when a-dynpri.adb is being compiled.  s-osinte.ads is
s-osinte-android.ads of course.

I think this is a direct consequence of #include  at sigtramp.h

s-ointe-android.ads, lines 590-594:
   for struct_sigaction use record
  sa_handler at Linux.sa_handler_pos range 0 .. Standard'Address_Size - 1;
  sa_maskat Linux.sa_mask_posrange 0 .. 1023;
  sa_flags   at Linux.sa_flags_pos   range 0 .. Standard'Address_Size - 1;
   end record;

asm/signal.h (NDK, API 15):
typedef unsigned long sigset_t;
struct sigaction {
 union {
 __sighandler_t _sa_handler;
 void (*_sa_sigaction)(int, struct siginfo *, void *);
 } _u;
 sigset_t sa_mask;
 unsigned long sa_flags;
 void (*sa_restorer)(void);
};

So it does seem that struct_sigaction record isn't correct after all.
John


[Bug ada/60411] ADA bootstrap failure on ARM

2014-04-08 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Apr  8 20:35:14 2014
New Revision: 209227

URL: http://gcc.gnu.org/viewcvs?rev=209227&root=gcc&view=rev
Log:
PR ada/60411
* sigtramp.h: Add Android support.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/sigtramp.h


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #19 from Jakub Jelinek  ---
Fixed.


[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11

2014-04-08 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.5 to 4.9 (trunk). Compiling the following reduced tests

program energy  
  implicit none ! all dble  
  integer(kind=4)::ns  ! size of spatial lattice
  integer(kind=4)::i,j,k,l
  integer(kind=4),allocatable::back(:,:) ! works up to 20,10
  integer(kind=4)::di,index
  doubleprecision,allocatable::sumffi(:)
  doubleprecision,allocatable::f(:,:,:,:) ! the dimensionless field
  go to 123
  do di = 0, ns/2 
 sumffi(di) = sumffi(di) + f(i,j,k,l)*f(back(i,di),j,k,l)
  end do
123 
contains
  function T(i,j,k,l,iu,ju,ku,lu,id,jd,kd,ld) ! only what depends on ijkl
doubleprecision::T
integer(kind=4)::i,j,k,l,iu,id,ju,jd,ku,kd,lu,ld
T = f(i,j,k,l)*( f(i,j,k,l) - f(iu,j,k,l) - f(id,j,k,l) )
  end function T
end program energy

gives and ICE with 4.5, the error

pr60774_red.f90:13.3:

123 
   1
Warning: Ignoring statement label in empty statement at (1)
pr60774_red.f90:9.11:

  go to 123
   1
Error: Label 123 referenced at (1) is never defined

with 4.6 and 4.7, and

pr60774_red.f90:13.3:

123 
   1
Warning: Ignoring statement label in empty statement at (1)


Error: Label 1119913824 referenced at (1) is never defined

with 4.8 and 4.9 (and an ICE with my working tree!-).


[Bug libstdc++/60789] New: [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)

2014-04-08 Thread david.abdurachmanov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789

Bug ID: 60789
   Summary: [4.9 Regression] Missing -lm while checking for math
functions (e.g., atan2f)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Math functions tests are failing with GCC 4.9.0 (trunk, r209221), while working
fine at least up to 4.8.1.

Tested on x86_64 (Scientific Linux 6.5) and aarch64 (Fedora 19).

Looking at compile time, seems that `-lm` was lost.

This caused a number of _GLIBCXX_HAVE_* not being defined for math functions in
`c++config.h`, thus causes functions like `atan2f` to call `(float)atan2(x,
y)`.

# Fragment from ./x86_64-unknown-linux-gnu/libstdc++-v3/config.log, GCC
4.8.1, checking for `atan2f`.

configure:22347: checking for atan2f declaration
configure:22372: 
/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc
-shared-libgcc
-B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc
-nostdinc++
-L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src
-L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include
   -c -fno-builtin -D_GNU_SOURCE  conftest.cpp >&5
configure:22372: $? = 0
configure:22388: result: yes
configure:22394: checking for atan2f
configure:22394:
/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc
-B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include
   -o conftest -g -O2   conftest.c  -lm >&5
conftest.c:161:6: warning: conflicting types for built-in function 'atan2f'
[enabled by default]
 char atan2f ();
  ^
configure:22394: $? = 0
configure:22394: result: yes

# Same from GCC 4.9.0

configure:22559: checking for atan2f declaration
configure:22584:
/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc/xgcc
-shared-libgcc
-B/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc
-nostdinc++
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/sys-include
   -c -fno-builtin -D_GN

[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt

2014-04-08 Thread linux at carewolf dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788

--- Comment #3 from Allan Jensen  ---
Sorry for the confusion. I thought Intel had added it from Ivy Bridge, but it
was Haswell.


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread rsandifo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

--- Comment #18 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Apr  8 17:50:45 2014
New Revision: 209223

URL: http://gcc.gnu.org/viewcvs?rev=209223&root=gcc&view=rev
Log:
gcc/
PR target/60763
* config/rs6000/vsx.md (vsx_xscvdpspn_scalar): Change input to DImode.
* config/rs6000/rs6000.md (reload_vsx_from_gprsf): Update accordingly.
Use gen_rtx_REG rather than simplify_gen_subreg for op0_di.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vsx.md


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread rsandifo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

--- Comment #17 from rsandifo at gcc dot gnu.org  
---
I'm just saying this for the record, and also to justify why I think
the other use of simplify_gen_subreg is correct.

(In reply to Michael Meissner from comment #14)
> When you are doing a subreg type operation, before reload, you must NOT use 
> the
> register number directly.  This is the dangerous part that was mentioned.

David was quoting me with the dangerous thing, so for what it's worth,
I meant that it would be dangerous to have a version of simplify_gen_subreg
that ignored CANNOT_CHANGE_MODE_CLASS.  And as long as simplify_gen_subreg
honours CANNOT_CHANGE_MODE_CLASS, a DImode subreg of an SFmode FPR is going
to return a subreg rather than a plain reg.

I definitely agree that using gen_rtx_REG before reload is dangerous
too of course.  I just wanted to clarify what I meant.

> Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the
> appropriate solution.

Agreed,

> If you are doing splits after reload, and are dealing with whole registers, 
> the
> preferred solution is to create a new REG with the appropriate register 
> number.
> In particular, gen_highpart and gen_lowpart must not be used after reload.
> However, up until the patch to add more checking, simplify_gen_subreg could be
> used after reload.

FWIW, I think gen_lowpart, gen_highpart and simplify_gen_subreg are always
OK if what you are doing is changing the mode of a value.  They are supposed
to handle both hard and pseudo registers.  So I think the other use of
simplify_gen_subreg in this pattern is OK (and gen_lowpart would be have
been OK too).  Using gen_rtx_REG wouldn't be wrong as such, but it would
lose things like ORIGINAL_REGNO.

The difference here is that we have a DImode temporary value and an SFmode
result that both need the same hard register.  The DImode value is written
and read only in DImode and the result is written only in SFmode, so there's
no real mode change.  That's the kind of case where gen_rtx_REG is needed.

> Out of force of habit, I've tended to use simplify_gen_subreg when doing
> splitting, no matter whether it is before or after reload.  I thought with
> 'simplify' in the name, it would do the right thing after reload, but 
> evidently
> it does not.

Well, I suppose it depends on what the expectations are.  If the target
forbids a particular mode change for a particular hard register,
simplify_gen_subreg will return a subreg rather than a reg.  IMO that's
the right thing to do, since it keeps the information that you have
a mode change that can't be reduced to a plain reg.  Returning null
would be another option (maybe better) but would probably have a big
impact.

So I think the problem in this case was that we were modelling the reuse
of the destination register as a mode change when it wasn't really,
and the mode change in question was one that the target normally tries
to prevent.


[Bug sanitizer/60745] Many ICEs running libstdc++ testsuite with ubsan, maybe due to PCH

2014-04-08 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60745

Marek Polacek  changed:

   What|Removed |Added

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

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


[Bug sanitizer/60745] Many ICEs running libstdc++ testsuite with ubsan, maybe due to PCH

2014-04-08 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60745

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Apr  8 17:23:26 2014
New Revision: 209222

URL: http://gcc.gnu.org/viewcvs?rev=209222&root=gcc&view=rev
Log:
PR sanitizer/60745
* c-ubsan.c: Include asan.h.
(ubsan_instrument_return): Call initialize_sanitizer_builtins.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ubsan.c


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread dje at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

--- Comment #16 from David Edelsohn  ---
Comment on attachment 32568
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32568
Patch with changelog and comment.

Okay. Thanks for the clarification.


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread rsandifo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

  Attachment #32557|0   |1
is obsolete||

--- Comment #15 from rsandifo at gcc dot gnu.org  
---
Created attachment 32568
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32568&action=edit
Patch with changelog and comment.

Here's a version of the patch with a comment explaining the gen_rtx_REG.


[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt

2014-04-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
LZCNT is encoded as F3 BSR:

   0:f3 0f bd c0  lzcnt  %eax,%eax
   4:0f bd c0 bsr%eax,%eax

Since your processor doesn't support LZCNT, F3 prefix is ignored
and f3 0f bd c0 is treated as BSR.  Before you use LZCNT, you need
to check if your processor support it or not.


[Bug c/51088] undefined label with statement expression and cond expression

2014-04-08 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51088

--- Comment #5 from Marek Polacek  ---
Patch to give an error if taking an address of a label defined in ({}):
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00381.html


[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform

2014-04-08 Thread murali.marimekala at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459

Murali  changed:

   What|Removed |Added

 CC||murali.marimekala at gmail dot 
com

--- Comment #5 from Murali  ---
Hi Ramana,

I am working with Raghu and looking into the same crash issue.

Thanks for your suggestions till now. Due to some constraints , we cant move to
a new toolchain. We are looking forward to fix this issue in ARM9 toolchain
4.2.1.

Though we got a fix for this issue online, we need your expertise to port it to
our toolchain.

When we were searching for inputs, we came across following article.
https://sourceware.org/ml/libc-ports/2011-03/msg00045.html

In this article,  Ryosei Takagi was facing the same issue (at exact location)
and has provided a fix for it in __longjump.S.

This particular __longjump.S is not available in toolchain 4.2.1. I searched
for relevant code and couldnt find it. 

Since we are not much familiar with this toolchain code, its taking more time
than expected to understand and port the code. So, need your valuable advise to
find the relevant location to port this fix.

If you need additional information, please let me know. 

Thank you,
Murali


[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt

2014-04-08 Thread linux at carewolf dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788

--- Comment #1 from Allan Jensen  ---
Sorry. The optimization has nothing to do with it, it just causes the constant
expressions used for testing to be evaluated at compile time.

The real issue is that the lzcnt instruction does not return the number of
leading zeroes, but the bitwidth minus the number of leading zeroes. So the
mapping of _builtin_clz to lzcnt is simply naïve and incorrect.

[Bug target/60788] New: Miscompilation of __builtin_clz with -mlzcnt

2014-04-08 Thread linux at carewolf dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788

Bug ID: 60788
   Summary: Miscompilation of __builtin_clz with -mlzcnt
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com

Created attachment 32567
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32567&action=edit
Test case

If you compile the attached program with -O0 and -mlzcnt on x86, it will
produce wrong results. As long as optimization is greater than 0 or the lzcnt
instruction is not available, it will produce correct results.

Somehow log2 is returned for __builtin_clz instead of leading zero count. It
almost looks like a wrong optimization except it only happens without
optimizations.

$ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O1 -g -mlzcnt -o lzcnt_tst
$ ./lzcnt_tst 
nextPowerOfTwo(0) = 0
nextPowerOfTwo(1) = 1
nextPowerOfTwo(2) = 2
nextPowerOfTwo(17) = 32
$ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O0 -g -mlzcnt -o lzcnt_tst
$ ./lzcnt_tst 
nextPowerOfTwo(0) = 0
nextPowerOfTwo(1) = 1
nextPowerOfTwo(2) = 1
nextPowerOfTwo(17) = 268435456
$ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O0 -o lzcnt_tst
$ ./lzcnt_tst 
nextPowerOfTwo(0) = 0
nextPowerOfTwo(1) = 1
nextPowerOfTwo(2) = 2
nextPowerOfTwo(17) = 32


[Bug libstdc++/60037] SIGFPE in std::generate_canonical

2014-04-08 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

--- Comment #4 from Jonathan Wakely  ---
clang's ubsan finds two errors

/home/jwakely/src/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3478:
runtime error: value 4.29497e+09 is outside the range of representable values
of type 'unsigned int'
/home/jwakely/src/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480:20:
runtime error: division by zero


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread meissner at linux dot vnet.ibm.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

--- Comment #14 from Michael Meissner  ---
On Tue, Apr 08, 2014 at 03:21:13PM +, dje at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
> 
> --- Comment #13 from David Edelsohn  ---
> Gentlemen, I really do not understand this discussion.
> 
> I used the term "crude" and receive a response that it is not crude, but it is
> dangerous. WTF? Why is anyone trying to "sell" the patch when I repeatedly 
> have
> said that I do not disagree with it in principle? I only am trying to ensure
> that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000
> does not.
> 
> I see multiple responses trying to convince me of a patch with which I already
> agree and no one writing a one line comment.

When you are doing a subreg type operation, before reload, you must NOT use the
register number directly.  This is the dangerous part that was mentioned.
Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the
appropriate solution.

If you are doing splits after reload, and are dealing with whole registers, the
preferred solution is to create a new REG with the appropriate register number.
In particular, gen_highpart and gen_lowpart must not be used after reload.
However, up until the patch to add more checking, simplify_gen_subreg could be
used after reload.

The alpha, arm, i386, ia64, iq2000, m32k, m68k, mips, msp430, pa, pdp11,
picochip, rl78, rs6000, s390, sh, sparc, spu, and xtensa all generate a call to
gen_rtx_REG using REGNO of an operand to change types.

Out of force of habit, I've tended to use simplify_gen_subreg when doing
splitting, no matter whether it is before or after reload.  I thought with
'simplify' in the name, it would do the right thing after reload, but evidently
it does not.


[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

2014-04-08 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

--- Comment #9 from Martin Jambor  ---
(In reply to Richard Biener from comment #5)
> 4.8 prints
> 
> t.ii: In function ‘void _Z3fooi.constprop.0()’:
> t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
>  z[i] = i;
> ^

I think that we can perhaps get closest to that with something like:

pp_string (pp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (t)));

which prints 

zz.C: In function ‘_Z3fooi.constprop.0’:

by using DECL_NAME instead of DECL_ASSEMBLER_NAME we can get
avoid mangling:

zz.C: In function ‘foo.constprop’:

> 
> does former_clone_of apply recursively? 

I believe that (at least currently) former_clone_of will always be the
original front-end declaration, i.e. the same as DECL_ABSTRACT_ORIGIN,
despite that...

> Thus can we have a clone of a clone?

...yes, the infrastructure allows that, although currently only such
clones are inline clones and thus not posing this problem.

> Is there a way to "pretty-print" the kind of clone?  That is, say
>  for a ipa-cp clone with parameter foo replaced by 1?

Hm, it would require changes elsewhere to do for aggregate
replacements (we'd need to remember the old decl and we remember only
offsets, not expressions), for scalar replacements it is already
apparently quite possible:

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 454feb5..bb8db31 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "pointer-set.h"
 #include "c-family/c-objc.h"
 #include "ubsan.h"
+#include "cgraph.h"

 #include // For placement-new.

@@ -1144,7 +1145,35 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
   /* Fall through.  */

 case FUNCTION_DECL:
-  if (! DECL_LANG_SPECIFIC (t))
+  if (DECL_ABSTRACT_ORIGIN (t))
+   {
+ dump_decl (pp, DECL_ABSTRACT_ORIGIN (t), flags);
+ 
+ cgraph_node *node = cgraph_get_node (t);
+ if (node && node->clone.tree_map)
+   {
+ struct ipa_replace_map *rmap;
+ unsigned i;
+ bool first = true;
+ pp_string (pp, M_(" clone.tree_map, i, rmap)
+   {
+ if (first)
+   first = false;
+ else 
+   pp_string (pp, (", "));
+
+ dump_expr (pp, rmap->new_tree, flags);
+ pp_string (pp, M_(" for "));
+ dump_expr (pp, rmap->old_tree, flags);
+   }
+ pp_string (pp, ">");
+   }
+ else
+   pp_string (pp, M_(" "));
+   }
+  else if (! DECL_LANG_SPECIFIC (t))
pp_string (pp, M_(""));
   else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);

gives:

zz.C: In function ‘void foo(int) ’:

[Bug middle-end/58101] Wrong out-of-bounds warning under -Os

2014-04-08 Thread dichlofos-mv at yandex dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58101

Mikhail Veltishchev  changed:

   What|Removed |Added

 CC||dichlofos-mv at yandex dot ru

--- Comment #4 from Mikhail Veltishchev  ---
Luis, why do you state that "rcu_num_levels is never larger than 1", this
cannot be proved as this variable is not const and can change its value (e.g.
in another thread).


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread dje at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

--- Comment #13 from David Edelsohn  ---
Gentlemen, I really do not understand this discussion.

I used the term "crude" and receive a response that it is not crude, but it is
dangerous. WTF? Why is anyone trying to "sell" the patch when I repeatedly have
said that I do not disagree with it in principle? I only am trying to ensure
that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000
does not.

I see multiple responses trying to convince me of a patch with which I already
agree and no one writing a one line comment.


[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c

2014-04-08 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed, thanks.


[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

2014-04-08 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
This has been fixed by the r208926 fix (PR60697), the backtrace is the same as
well.

CCing Vlad whether we want to just add the testcase to the testsuite and close,
or close without testcase, or whether this PR was just a different bug that
just went latent with that fix.


[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c

2014-04-08 Thread krebbel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Apr  8 14:18:46 2014
New Revision: 209221

URL: http://gcc.gnu.org/viewcvs?rev=209221&root=gcc&view=rev
Log:
2014-04-08  Andreas Krebbel  

PR rtl-optimization/60776
* gcc.dg/builtin-bswap-6.c: Use -mbranch-cost=0 for s390.
* gcc.dg/builtin-bswap-7.c: Likewise.
* gcc.dg/builtin-bswap-6a.c: New testcase.
* gcc.dg/builtin-bswap-7a.c: New testcase.

Revert
2014-04-04  Andreas Krebbel  

* gcc.dg/builtin-bswap-6.c: Adjust return value to disable GCC
optimization.
* gcc.dg/builtin-bswap-7.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-bswap-6a.c
trunk/gcc/testsuite/gcc.dg/builtin-bswap-7a.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-bswap-6.c
trunk/gcc/testsuite/gcc.dg/builtin-bswap-7.c


[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953

2014-04-08 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-08
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
This is what creduce came up with:

template  void destroy (T *);
template  struct ArrayFill
{
  ArrayFill (FI, FI &p2) : tgt_start_ (), tgt_end_ (p2) {}
  template  void m_fn1 (Val &, int &)
  {
while (tgt_cur_ != tgt_end_)
  ++tgt_cur_;
  }
  ~ArrayFill () throw()
  {
if (tgt_cur_ != tgt_end_)
  while (tgt_cur_ != tgt_start_)
{
  --tgt_cur_;
  destroy (&*tgt_cur_);
}
  }
  const FI tgt_start_, tgt_end_;
  FI tgt_cur_;
};

template 
inline FI uninitialized_fill (FI &p1, FI &p2, Val &p3, int &p4)
{
  ArrayFill a (p1, p2);
  a.m_fn1 (p3, p4);
}

template  struct A
{
  typedef int *pointer;
  typedef int &const_reference;
  template  int m_fn1 (const A &p1)
  {
return cur_ == p1.cur_;
  }
  const_reference operator*() {}
  void operator++()
  {
if (last_)
  cur_ = first_;
  }
  void operator--() { --cur_; }
  pointer cur_;
  pointer first_;
  pointer last_;
};

template 
inline int operator==(A &p1, const A &p2)
{
  return p1.m_fn1 (p2);
}

template 
inline int operator!=(A &p1, const A &p2)
{
  return !(p1 == p2);
}

struct B
{
  typedef A::const_reference const_reference;
};
class C
{
public:
  typedef B::const_reference const_reference;
  int *p_ma_;
  struct MapCreator
  {
~MapCreator ();
  };
  struct MultiNodeCreator
  {
MultiNodeCreator (A::pointer *, A::pointer *, int &p3)
: ma_ (p3)
{
}
~MultiNodeCreator () throw();
void m_fn1 ();
int &ma_;
  };
  void m_fn1 (A::pointer *, A::pointer *, int &)
  {
MultiNodeCreator b (0, 0, *p_ma_);
b.m_fn1 ();
  }
  C::MapCreator initialize_map__new_map;
  int &m_fn2_p3;
  void m_fn2 (int, int)
  {
m_fn1 (0, 0, m_fn2_p3);
this->finish_.cur_ = this->finish_.first_;
  }
  C (int &);
  A start_;
  A finish_;
};

class G : C
{
  void m_fn3 (const_reference p1, const int &)
  {
this->m_fn2 (0, 0);
uninitialized_fill (this->start_, this->finish_, p1, *this->p_ma_);
  }
public:
  G (int, const_reference p2, int &p3) : C (p3) { m_fn3 (p2, 0); }
  void m_fn4 (const_reference p1) { G (0, p1, *this->p_ma_); }
};

class F
{
  void m_fn1 (int &);
  G m_jobs;
};
void F::m_fn1 (int &p1) { m_jobs.m_fn4 (p1); }


[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

2014-04-08 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #5)
> which isn't perfect either.  Is there a way for the C++ FE to get at the
> original function decl that was cloned?  Like with
> 
> Index: gcc/cp/error.c
> ===
> --- gcc/cp/error.c  (revision 209210)
> +++ gcc/cp/error.c  (working copy)
> @@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
>  #include "pointer-set.h"
>  #include "c-family/c-objc.h"
>  #include "ubsan.h"
> +#include "cgraph.h"
>  
>  #include // For placement-new.
>  
> @@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree
>  
>  case FUNCTION_DECL:
>if (! DECL_LANG_SPECIFIC (t))
> -   pp_string (pp, M_(""));
> +   {
> + cgraph_node *node;
> + if ((node = cgraph_get_node (t))
> + && node->former_clone_of)
> +   {
> + dump_decl (pp, node->former_clone_of, flags);
> + pp_string (pp, M_(" "));
> +   }
> + else
> +   pp_string (pp, M_(""));
> +   }
>else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
> dump_global_iord (pp, t);
>else
> 

Wouldn't it be better for the middle end to provide its own diagnostic_starter
function, which in turn calls the FE one and override
current_function_declaration around the call to the FE one by the original
function?

This will also allow in the future the middle-end to override other stuff that
it doesn't want the FE to deal with.

[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787

--- Comment #1 from Richard Biener  ---
Maybe latent on 4.8/4.9, different inlining happens there.


[Bug middle-end/60787] New: [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787

Bug ID: 60787
   Summary: [4.7 Regression] ICE in expand_builtin_eh_common, at
except.c:1953
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: EH, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

Created attachment 32566
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32566&action=edit
autoreduced testcase

> g++ -S -O bug-872323_bug.3.3.3.3.cpp
bug-872323_bug.3.3.3.3.cpp: In member function ‘void
JobMultiWaiter::add(JobHandle&)’:
bug-872323_bug.3.3.3.3.cpp:229:6: internal compiler error: in
expand_builtin_eh_common, at except.c:1953
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.6.4, 4.8.0, 4.9.0
Version|4.9.0   |4.7.3
   Target Milestone|--- |4.7.4
  Known to fail||4.7.0, 4.7.3


[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

2014-04-08 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #5)
> 
> does former_clone_of apply recursively?  Thus can we have a clone of a clone?
> Is there a way to "pretty-print" the kind of clone?  That is, say
>  for a ipa-cp clone with parameter foo replaced by 1?

Why would you want to do that? At least for diagnostics to the users (not debug
dumps), that the function is a clone is an internal implementation detail.

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

2014-04-08 Thread matthijs at stdin dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300

--- Comment #3 from Matthijs Kooijman  ---
Hmm, I don't think the gcc sources support that. AFAICT, they attempt to just
find the shortest approach, without caring for speed. For example, look at
avr.c, around line 1265, where it says:

  / Use shortest method /

  emit_insn (get_sequence_length (sp_plus_insns)
 < get_sequence_length (fp_plus_insns)
 ? sp_plus_insns
 : fp_plus_insns);

https://github.com/mirrors/gcc/blob/c2e306f5efb32b7eed856a1844487cff09aa86ac/gcc/config/avr/avr.c#L1265-L1270


[Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var2 = 42949673 00;"

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var2 = 42949673 00;"

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Apr  8 12:57:07 2014
New Revision: 209216

URL: http://gcc.gnu.org/viewcvs?rev=209216&root=gcc&view=rev
Log:
2014-04-08  Richard Biener  

PR middle-end/60706
* tree-pretty-print.c (pp_double_int): For HWI32 hosts with
a 64bit widest int print double-int similar to on HWI64 hosts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-pretty-print.c


[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-04-08 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

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

Alternate fix, the issue on the non-fdata-sections testcase is that we have
(note 226 225 227 (var_location rx (plus:SI (plus:SI (reg:SI 3 r3 [orig:192
ivtmp.37 ] [192])
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))
(const:SI (minus:SI (const_int 323 [0x143])
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
NOTE_INSN_VAR_LOCATION)

which hasn't been simplified into %r3+323.  I think this patch is the right
thing to do, but it is probably too risky for 4.9 now, too many targets do too
weird things, especially for -fpic.  Perhaps if we had a flag (global for 4.9)
we are in var-tracking pass (guess current_pass && strcmp (current_pass->name,
"vartrack") == 0 would be way too ugly), it might be safe to do that only for
var-tracking and for 5.0 enable it unconditionally.


[Bug c++/60786] New: In C++11 an explicit instantiation with an unqualified name must be in the right namespace

2014-04-08 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60786

Bug ID: 60786
   Summary: In C++11 an explicit instantiation with an unqualified
name must be in the right namespace
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

This should not be accepted in C++11 mode:

namespace A {
  template struct B { };
}

using A::B;
template class B;


[temp.explicit] p3:
"An explicit instantiation shall appear in an enclosing namespace of its
template. If the name declared in the explicit instantiation is an unqualified
name, the explicit instantiation shall appear in the namespace where its
template is declared or, if that namespace is inline (7.3.1), any namespace
from its enclosing namespace set."

This is a change from C++03:

"A definition of a class template or class member template shall be in scope at
the point of the explicit instantiation of the class template or class member
template."


[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #6 from Richard Biener  ---
Looks quite some usability regression to me, compared to 4.8.  Making P1.


[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

--- Comment #5 from Richard Biener  ---
4.8 prints

t.ii: In function ‘void _Z3fooi.constprop.0()’:
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
 z[i] = i;
^

which isn't perfect either.  Is there a way for the C++ FE to get at the
original function decl that was cloned?  Like with

Index: gcc/cp/error.c
===
--- gcc/cp/error.c  (revision 209210)
+++ gcc/cp/error.c  (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
 #include "pointer-set.h"
 #include "c-family/c-objc.h"
 #include "ubsan.h"
+#include "cgraph.h"

 #include // For placement-new.

@@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree

 case FUNCTION_DECL:
   if (! DECL_LANG_SPECIFIC (t))
-   pp_string (pp, M_(""));
+   {
+ cgraph_node *node;
+ if ((node = cgraph_get_node (t))
+ && node->former_clone_of)
+   {
+ dump_decl (pp, node->former_clone_of, flags);
+ pp_string (pp, M_(" "));
+   }
+ else
+   pp_string (pp, M_(""));
+   }
   else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
   else

which prints

t.ii: In function 'void foo(int) ':
t.ii:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
 z[i] = i;
 ^
t.ii:13:3: note: containing loop
   for (int i = 0; i < s; i++)
   ^
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
 z[i] = i;
^

does former_clone_of apply recursively?  Thus can we have a clone of a clone?
Is there a way to "pretty-print" the kind of clone?  That is, say
 for a ipa-cp clone with parameter foo replaced by 1?

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-04-08 Thread ramana at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

--- Comment #12 from Ramana Radhakrishnan  ---
Created attachment 32564
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32564&action=edit
patch...

Fix so far tested just on the reduced and the full testcase. No issues. Now
bootstrapping and regression testing on armhf.

regards
Ramana


[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2014-03-31 00:00:00 |2014-04-08
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
Works for me with a cross to arm-linux-gnueabi and -O -mhard-float
-march=armv7-a -mthumb -mfpu=vfpv3-d16 (not sure if that replicates gnueabihf).
 Also works
with a cross to arm-linux-gnueabihf for me:

rguenther@murzim:/abuild/rguenther/obj-arm-g/gcc> ./f951 -quiet t.f90 -O 
rguenther@murzim:/abuild/rguenther/obj-arm-g/gcc> ./gfortran -v
Using built-in specs.
COLLECT_GCC=./gfortran
Target: arm-suse-linux-gnueabihf
Configured with: /space/rguenther/src/svn/trunk/configure
--target=arm-suse-linux-gnueabihf --enable-languages=c,c++,lto,fortran
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
Thread model: posix
gcc version 4.9.0 20140408 (experimental) (GCC) 

thus, fixed?


[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-04-08 Thread ramana at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

--- Comment #11 from Ramana Radhakrishnan  ---
I haven't had enough time to work on this one but in the interest of getting
this sorted for 4.9, I'm handling this as suggested by Jakub in the backend
under targetm.const_not_ok_for_debug_p and disallowing anything that is minus
(..) (sym_ref) except for minus (sym_ref) (sym_ref) where the
DECL_SECTION_NAMEs are identical including null.

Hopefully that will sort out the problem for 4.9 but we still need this
investigated properly for later.

ramana


[Bug fortran/60500] [4.7/4.8/4.9 Regression] Spurious warning on derived type initialization

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60500

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4


[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

2014-04-08 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
I've now commited the patch to XFAIL the testcase for Solaris 9/SPARC/-O0/as.

  Rainer


[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Apr  8 10:59:40 2014
New Revision: 209214

URL: http://gcc.gnu.org/viewcvs?rev=209214&root=gcc&view=rev
Log:
2014-04-08  Richard Biener  

PR tree-optimization/60785
* graphite-sese-to-poly.c (rewrite_phi_out_of_ssa): Treat
default defs properly.

* gcc.dg/graphite/pr60785.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr60785.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-sese-to-poly.c
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

2014-04-08 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602

--- Comment #4 from Rainer Orth  ---
Author: ro
Date: Tue Apr  8 10:56:04 2014
New Revision: 209213

URL: http://gcc.gnu.org/viewcvs?rev=209213&root=gcc&view=rev
Log:
XFAIL gcc.c-torture/compile/pr28865.c on Solaris 9/SPARC (PR target/60602)

PR target/60602
* gcc.c-torture/compile/pr28865.c: XFAIL on sparc*-*-solaris2.9*
with as at -O0.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr28865.c


[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

2014-04-08 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
(In reply to David Edelsohn from comment #10)
> I'm not questioning the analysis, I'm questioning the solution. Directly
> generating a register and jamming in the REGNO in this pattern seems sort of
> crude.
> 
> gen_rtx_REG (DImode, REGNO (op0));

I think this idiom is very commonly used in other backends for this purpose,
and is simple enough not to need any kind of extra wrapper.
Just look e.g. at
grep gen_rtx_REG' '.*REGNO gcc/config/i386/*.md

Perhaps a one line comment would be useful, but other than that the #c7 patch
looks just fine to me.


[Bug fortran/60781] cannot match namelist object name

2014-04-08 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781

--- Comment #6 from Dominique d'Humieres  ---
Curly quotes in

  met_file = ‘met_04270_62_65.txt’

The following code

implicit none

character(len=70) :: &
  dem_file='',  &! Elevation file name
  met_file='',  &! Driving data file name
  vegf_file='', &! Vegetation fraction file name
  vegh_file='', &! Vegetation height file name
  wind_file='', &! Wind distribution file name
  RunID=''   ! Run identifier

integer :: & 
  Nsmax,Nsoil,noff,   &
  d, &! Discretized wind direction (1 = NE, 2 = E, ..., 8 = N)
  i,j,   &! Grid indices
  is,js, &! Grid location of met station
  dayout(12),monthout(12)

real :: &
  dt,lat,windir,zT,zU, &
  sx,sy, &! Coordinates of met station (m)
  Waws,  &! Wind speed at met station
  xlo,ylo,   &! Grid SW corner coordinates (m)
  xhi,yhi ! Grid NE corner coordinates (m)

real, allocatable :: &
  dzdx(:,:), &! Partial derivative
  dzdy(:,:)   ! Partial derivative

namelist /grids/ dem_file,vegf_file,vegh_file,wind_file,Nsmax,Nsoil,sx,sy
namelist /drive/ dt,lat,met_file,noff,windir,zT,zU
namelist /output/ RunID,dayout,monthout

read(5, grids)
read(5, drive)
read(5, output)

print *, dem_file,vegf_file,vegh_file,wind_file,Nsmax,Nsoil,sx,sy
print *, dt,lat,met_file,noff,windir,zT,zU
print *, RunID,dayout,monthout

end

reads the namelist once the curly quotes have replaced with '.

[Bug libstdc++/60594] std::function of a type with a declared (but not defined) return type fails to compile

2014-04-08 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594

--- Comment #6 from Jonathan Wakely  ---
(In reply to Mitsuru Kariya from comment #5)
> FYI, the BUG2 above is compiled successfully by gcc 4.7.3.

Yes, but std::function in 4.7.3 fails other, more important tests.


[Bug lto/60779] -fcx-fortran-rules ignored when using -flto

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779

--- Comment #4 from Richard Biener  ---
Note this applies to the case where you don't specify any -fcx-* flag on the
linker command-line (or on any of the input TUs, but merging conflicting
flags there doesn't work).


[Bug fortran/60781] cannot match namelist object name

2014-04-08 Thread lauraelcomeau at yahoo dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781

--- Comment #5 from Laura C  ---

Yes, I type ./JIM_exe

[Bug ada/60411] ADA bootstrap failure on ARM

2014-04-08 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #9 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Apr  8 09:03:42 2014
New Revision: 209211

URL: http://gcc.gnu.org/viewcvs?rev=209211&root=gcc&view=rev
Log:
PR ada/60411
* sigtramp-armdroid.c: New file.

Added:
trunk/gcc/ada/sigtramp-armdroid.c
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in


[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785

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  ---
I have a patch.


[Bug target/60778] shift not folded into shift on x86-64

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60778

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  A bit difficult since

(insn 7 6 8 2 (parallel [
(set (reg:DI 89 [ D.1754 ])
(ashiftrt:DI (reg/v:DI 86 [ x ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) t.i:3 532 {*ashrdi3_1}
 (nil))
(insn 8 7 9 2 (set (reg:DF 90)
(mem:DF (plus:DI (mult:DI (reg:DI 89 [ D.1754 ])
(const_int 8 [0x8]))
(reg/f:DI 88)) [2 mem S8 A64])) t.i:3 128 {*movdf_internal}
 (nil))

don't combine well (and:DI is not valid inside the MEM), but a
define-insn-and-split may be able to handle this.


[Bug lto/60779] -fcx-fortran-rules ignored when using -flto

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, missed-optimization
 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2014-04-08
  Component|c++ |lto
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Well, LTO unconditionally sets flag_complex_method to 2 currently.  It does not
yet conservatively merge TU choices and complex lowering happens too late.

Thus, confirmed and mine.


[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear

2014-04-08 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-08
  Component|other   |tree-optimization
   Target Milestone|--- |4.9.0
Summary|ICE in gsi_for_stmt w/ -O2  |[4.9 Regression] ICE in
   |-ftree-loop-linear  |gsi_for_stmt w/ -O2
   ||-ftree-loop-linear
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I'll have a look.


[Bug ada/60411] ADA bootstrap failure on ARM

2014-04-08 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Apr  8 08:23:56 2014
New Revision: 209210

URL: http://gcc.gnu.org/viewcvs?rev=209210&root=gcc&view=rev
Log:
PR ada/60411
* gcc-interface/Makefile.in (arm% linux-android): Switch to EHABI.
* s-linux-android.ads: New file.
* s-intman-android.adb: Likewise.

Added:
trunk/gcc/ada/s-intman-android.adb
trunk/gcc/ada/s-linux-android.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2014-04-08 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #208 from Markus Trippelsdorf  ---
Both issues from Comment 201 were fixed by:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00338.html