[Bug c++/57107] New: tree check fail in unlink_stmt_vdef

[dcb314 at hotmail dot com]

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



 Bug #: 57107

   Summary: tree check fail in unlink_stmt_vdef

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dcb...@hotmail.com





I just tried to compile the package luminance-hdr-2.3.0-6

on gcc-4.9 trunk dated 20130428 on an AMD x86_64 box.



The compiler said



/home/dcb/rpmbuild/BUILD/luminance-hdr-2.3.0/src/Fileformat/pngwriter.cpp:205:1:

internal compiler error: tree check: expected ssa_name, have var_decl in

unlink_stmt_vdef, at tree-ssa-operands.c:1322

 }

 ^

0xc8c92a tree_check_failed(tree_node const*, char const*, int, char const*,

...)

../../src/trunk/gcc/tree.c:8972

0xbc0db7 tree_check

../../src/trunk/gcc/tree.h:3690

0xbc0db7 unlink_stmt_vdef(gimple_statement_d*)

../../src/trunk/gcc/tree-ssa-operands.c:1322

0xae2919 optimize_clobbers

../../src/trunk/gcc/tree-eh.c:3298

0xae681b cleanup_empty_eh

../../src/trunk/gcc/tree-eh.c:4227

0xae681b cleanup_all_empty_eh

../../src/trunk/gcc/tree-eh.c:4355

0xae681b execute_cleanup_eh_1

../../src/trunk/gcc/tree-eh.c:4384

0xae681b execute_cleanup_eh

../../src/trunk/gcc/tree-eh.c:4409

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Preprocessed source code attached. Flag -O2 required.

[Bug rtl-optimization/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.1

[Bug rtl-optimization/57105] [4.9 Regression] ICE: in add_insn_before_nobb, at emit-rtl.c:3883 with -Os -fselective-scheduling2 -g

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

[Bug c++/57107] tree check fail in unlink_stmt_vdef

[dcb314 at hotmail dot com]

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



--- Comment #1 from David Binderman  2013-04-29 
08:08:34 UTC ---

Created attachment 29969

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29969

gzipped C++ source code

[Bug middle-end/57103] [4.8/4.9 Regression] ICE: verify_gimple failed: location references block not in block tree with -ftree-parallelize-loops=4

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-29

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.8.1

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-29 
08:08:36 UTC ---

I will have a looksee.

[Bug c++/57102] [4.9 Regression] ICE: SIGSEGV in fndecl_declared_return_type with -fcompare-debug

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

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

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 CC||rguenth at gcc dot gnu.org,

   ||stevenb.gcc at gmail dot

   ||com

   Target Milestone|--- |4.8.1

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-29 
08:12:18 UTC ---

Well, you cannot reliably dump graphs at each point in the pass pipeline

in case there are unreachable blocks in the CFG ...



I also routinely hit ICEs in the graph dumping when dumping broken loop

trees (for debugging).



I think we eventually want a custom CFG collecting routine in graph.c

that is not prone to such issues (but just gives up and appends the

rest of the BBs unsorted).

[Bug middle-end/57089] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-29

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.9.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-29 
08:12:44 UTC ---

I'll have a look.

[Bug tree-optimization/57083] [4.8/4.9 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Jakub Jelinek  2013-04-29 
08:34:32 UTC ---

Author: jakub

Date: Mon Apr 29 07:55:09 2013

New Revision: 198388



URL: http://gcc.gnu.org/viewcvs?rev=198388&root=gcc&view=rev

Log:

PR tree-optimization/57083

* tree-vrp.c (extract_range_from_binary_expr_1): For LSHIFT_EXPR with

non-singleton shift count range, zero extend low_bound for uns case.



* gcc.dg/torture/pr57083.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr57083.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vrp.c



Author: jakub

Date: Mon Apr 29 07:57:02 2013

New Revision: 198389



URL: http://gcc.gnu.org/viewcvs?rev=198389&root=gcc&view=rev

Log:

PR tree-optimization/57083

* tree-vrp.c (extract_range_from_binary_expr_1): For LSHIFT_EXPR with

non-singleton shift count range, zero extend low_bound for uns case.



* gcc.dg/torture/pr57083.c: New test.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57083.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/gcc/tree-vrp.c

[Bug middle-end/57073] __builtin_powif (-1.0, k) should be optimized to "1.0 - 2.0 * (K%2)"

[burnus at gcc dot gnu.org]

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



--- Comment #5 from Tobias Burnus  2013-04-29 
08:40:59 UTC ---

(In reply to comment #4)

> patch that fails



The Fortran patch of the attachments looks fine, except for:



+  one = gfc_copy_expr (op1);

+  gfc_free_expr (op1);

+  gfc_free_expr (op2);

+  *e = *one;



I would simply use "op1" directly instead of copying it and then freeing the

original expression. Otherwise, I am okay with that patch (with a test case).



 * * *



For the middle-end patch: Richard things that the problem is probably in the

COND_EXPR re-gimplification - which means the problem is elsewhere.

[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 AssignedTo|hubicka at gcc dot gnu.org  |ubizjak at gmail dot com



--- Comment #6 from Uros Bizjak  2013-04-29 08:47:20 
UTC ---

I have a patch in testing that splits TARGET_INTER_UNIT_MOVES to moves to and

from vector registers.

[Bug c++/57107] tree check fail in unlink_stmt_vdef

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #2 from Markus Trippelsdorf  
2013-04-29 09:00:33 UTC ---

Reduced:



class A {

public:

  template  struct rebind {

typedef A other;

  };

  ~A() {}

};

template  struct __alloc_traits {

  template  struct rebind {

typedef typename _Alloc::template rebind<_Tp>::other other;

  };

};

template  struct B {

  typedef typename __alloc_traits<_Alloc>::template rebind<_Tp>::other

  _Tp_alloc_type;

  struct C : _Tp_alloc_type {

C(_Tp_alloc_type) : _Tp_alloc_type() {}

  };

  typedef _Alloc allocator_type;

  B(int, const allocator_type &p2) : _M_impl(p2) {}

  C _M_impl;

};

template  class D : B<_Tp, _Alloc> {

  typedef B<_Tp, _Alloc> _Base;

public:

  typedef _Tp value_type;

  typedef _Alloc allocator_type;

  D(const value_type &p1, const allocator_type &p2 = allocator_type())

  : _Base(0, p2) {

_M_fill_initialize(p1);

  }

  void _M_fill_initialize(const value_type &);

};

void _setjmp();

void writeQImageToPng() {

  _setjmp();

  D(0);

}

[Bug tree-optimization/57081] [4.9 Regression] Segmentation fault in simple_iv (tree-scalar-evolution.c:3151)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Biener  2013-04-29 
09:09:28 UTC ---

Author: rguenth

Date: Mon Apr 29 09:09:08 2013

New Revision: 198392



URL: http://gcc.gnu.org/viewcvs?rev=198392&root=gcc&view=rev

Log:

2013-04-29  Richard Biener  



PR tree-optimization/57081

* loop-init.c: Include tree-flow.h.

(loop_optimizer_finalize): Free number of iteration estimates.

* Makefile.in (loop-init.o): Add $(TREE_FLOW_H) dependency.



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



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr57081.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/Makefile.in

trunk/gcc/loop-init.c

trunk/gcc/testsuite/ChangeLog

[Bug target/57108] New: [4.7/4.8/4.9] SH internal compiler error: in int_mode_for_mode, at stor-layout.c:395

[chrbr at gcc dot gnu.org]

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



 Bug #: 57108

   Summary: [4.7/4.8/4.9] SH internal compiler error: in

int_mode_for_mode, at stor-layout.c:395

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: ch...@gcc.gnu.org

ReportedBy: ch...@gcc.gnu.org

Target: sh-elf





Created attachment 29970

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29970

for -O1

[Bug rtl-optimization/57105] [4.9 Regression] ICE: in add_insn_before_nobb, at emit-rtl.c:3883 with -Os -fselective-scheduling2 -g

[abel at gcc dot gnu.org]

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



--- Comment #1 from Andrey Belevantsev  2013-04-29 
09:18:26 UTC ---

Does the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957#c9 fixes

your issue?

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #20 from Jakub Jelinek  2013-04-29 
09:25:29 UTC ---

Any progress with this?  We'd like to do 4.8.1-rc1 in mid-May, would be nice to

have this resolved till then.

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #7 from Tobias Burnus  2013-04-29 
09:31:53 UTC ---

(In reply to comment #6)

>   external ff, cc

>   call q(ff)

>

> I absolutely *never* use implicit declarations, therefore I'm not sure: Is an

> "external ff" declaration supposed to get implicitly typed as real in comment

> 4?



The program is *valid*; as "ff" is referenced as function, it has to be

implicitly typed, which is "real" according to the implicit typing rules.



I concur that the standard does not very explicitly state this. But the

question (and example of comment 4) exactly matches the interpretation request

F03/0071 (cf. comment 0). J3/WG5 answered it

http://www.j3-fortran.org/doc/standing/links/016.txt - to quote from the answer

to Q2:



"2. The main program program unit is conforming, although the program

would not be if the external procedure FF were not in fact a real

function.  If the reference had been to QR instead of Q, it would

be clear that FF has to be a real function, from the point of view

of the main program scoping unit.  At the call site, the reference

to Q is known to be a reference either to QR or QC (the interface

block for Q is not defective), both of which require a function

actual argument.  FF is known to be either a subroutine or a

function, since it explicitly has the EXTERNAL attribute, and if

it is a function it is known by implicit typing rules to be real.

Because neither specific in the generic allows a subroutine as an

argument, FF must therefore be a function.  Since FF is real, QR

is called.  (The generic cannot have a specific that accepts a

subroutine as an argument, as that would violate the requirements

in 16.2.3.)"

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[burnus at gcc dot gnu.org]

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



--- Comment #8 from Tobias Burnus  2013-04-29 
09:34:58 UTC ---

Author: jb

Date: Mon Apr 29 08:42:00 2013

New Revision: 198390



URL: http://gcc.gnu.org/viewcvs?rev=198390&root=gcc&view=rev

Log:

PR 56981 Improve unbuffered performance on special files.



2013-04-29  Janne Blomqvist  



PR fortran/56981

* io/transfer.c (next_record_w_unf): First fix head marker, then

write tail.

(next_record): Call flush_if_unbuffered.

* io/unix.c (struct unix_stream): Add field unbuffered.

(flush_if_unbuffered): New function.

(fd_to_stream): New argument.

(open_external): Fix fd_to_stream call.

(input_stream): Likewise.

(output_stream): Likewise.

(error_stream): Likewise.

* io/unix.h (flush_if_unbuffered): New prototype.



Modified:

trunk/libgfortran/ChangeLog

trunk/libgfortran/io/transfer.c

trunk/libgfortran/io/unix.c

trunk/libgfortran/io/unix.h

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[burnus at gcc dot gnu.org]

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



--- Comment #9 from Tobias Burnus  2013-04-29 
09:36:04 UTC ---

Follow-up idea regarding the flushing of when the buffer is full to avoid

unnecessary seeks: http://gcc.gnu.org/ml/fortran/2013-04/msg00258.html

[Bug rtl-optimization/57105] [4.9 Regression] ICE: in add_insn_before_nobb, at emit-rtl.c:3883 with -Os -fselective-scheduling2 -g

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #2 from Marek Polacek  2013-04-29 
09:38:16 UTC ---

Yeah, it does.

[Bug c++/57109] New: ice tsubst_copy, at cp/pt.c:12171

[wd11 at leicester dot ac.uk]

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



 Bug #: 57109

   Summary: ice tsubst_copy, at cp/pt.c:12171

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: w...@leicester.ac.uk





gcc 4.9.0



> g++ -v

Using built-in specs.

COLLECT_GCC=/opt/local/bin/g++-mp-4.9

COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.9.0/lto-wrapper

Target: x86_64-apple-darwin12

Configured with: ../gcc-4.9-20130414/configure --prefix=/opt/local

--build=x86_64-apple-darwin12

--enable-languages=c,c++,objc,obj-c++,fortran,java

--libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49

--infodir=/opt/local/share/info --mandir=/opt/local/share/man

--datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local

--with-system-zlib --disable-nls --program-suffix=-mp-4.9

--with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local

--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local

--with-cloog=/opt/local --enable-cloog-backend=isl

--disable-cloog-version-check --enable-stage1-checking --disable-multilib

--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as

--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar

--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts

gcc49 4.9-20130414_0'

Thread model: posix

gcc version 4.9.0 20130414 (experimental) (MacPorts gcc49 4.9-20130414_0)



crashed with ICE (see subject line; on line 1634). Compiler options used:



-std=c++0x -march=native -mfpmath=sse -mpreferred-stack-boundary=4 -ggdb3 -Wall

-Wextra -Winit-self -Wshadow -Woverloaded-virtual -Wno-unknown-pragmas -Winline

-O2 -fPIC -funroll-loops -fforce-addr -fopenmp



triggered by using a local variable from within a lambda expression.



preprocessor output attached.

[Bug rtl-optimization/57105] [4.9 Regression] ICE: in add_insn_before_nobb, at emit-rtl.c:3883 with -Os -fselective-scheduling2 -g

[abel at gcc dot gnu.org]

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



--- Comment #3 from Andrey Belevantsev  2013-04-29 
09:40:11 UTC ---

Fine, I've tested it on ia64 and got an offline approval from Alexander, I'd

need to test on x86-64 and commit then.

[Bug sanitizer/57104] ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2013-04-29 
09:52:31 UTC ---

Confirmed.

[Bug c++/57109] ice tsubst_copy, at cp/pt.c:12171

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-29

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2013-04-29 
09:56:47 UTC ---

No .ii

[Bug libstdc++/57110] New: is the use of "uint_fast32_t" in intentional?

[vincenzo.innocente at cern dot ch]

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



 Bug #: 57110

   Summary: is the use of "uint_fast32_t" in  intentional?

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: vincenzo.innoce...@cern.ch





Trying to understand differences for the mersenne_twister_engine between Linux

and MacOS (both x86_64) I discovered that on Linux uint_fast32_t is 64 bits

while on Mac is 32



this makes

typedef mersenne_twister_engine<

   uint_fast32_t,

   32, 624, 397, 31,

   0x9908b0dfUL, 11,

   0xUL, 7,

   0x9d2c5680UL, 15,

   0xefc6UL, 18, 1812433253UL> mt19937;



different on the two systems.

in particular

_UIntType   _M_x[state_size];

is a vector of ULL on linux and of UI on Mac



is this really intentional?



btw bits/random.h is the only place where uint_fast32_t is actually used in the

whole libstdc++

[Bug c++/57109] ice tsubst_copy, at cp/pt.c:12171

[wd11 at leicester dot ac.uk]

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



--- Comment #2 from wd11 at leicester dot ac.uk 2013-04-29 10:28:13 UTC ---

Created attachment 29971

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29971

file generated via g++ -E  and  gzip



compressed because pre-processor output was too big (2.6Mb).

[Bug libstdc++/57110] is the use of "uint_fast32_t" in intentional?

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Paolo Carlini  2013-04-29 
10:44:18 UTC ---

Obviously, whatever the size of the type on the various targets, it has nothing

to do with  per se (or even v3, because  just wraps

), because, per the Standard, mt19937 *must* use uint_fast32_t

(26.5.5, there are *many* uses of the _fast_ variants)

[Bug fortran/39290] Subroutine/function ambiguity in generics

[mikael at gcc dot gnu.org]

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



--- Comment #8 from Mikael Morin  2013-04-29 
10:59:51 UTC ---

The following excerpt from gfc_compare_interfaces(interface.c) seems to be the

cause of 'qc' being called:



  if (s1->attr.function && s2->attr.function)

{

  /* If both are functions, check result characteristics.  */

  if (!check_result_characteristics (s1, s2, errmsg, err_len))

return 0;

}



s2 is 'ff', and s2->attr.function is false, so we don't check function results,

and the 'qc' interface matches.



There are a quite a few problems it seems:

 1. we rely on s1->attr.function _and_ s2->attr.function being set, which is

obviously not the case with implicit typing.

 2. check_result_characteristics will call gfc_compare_types, so it needs

properly set types (no BT_UNKNOWN).

 3. gfc_search_interface returns the first match, so it doesn't detect multiple

matches (which would reject this case and avoid generating wrong code here).

 4. Implicit typing depends on how the symbol is used, so basically on the

available interfaces, but that itself needs implicit typing being resolved (see

1. and 2.)



Good luck to whoever wants to fix this.

[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Target||x86

URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-04/msg01723.htm

   ||l



--- Comment #7 from Uros Bizjak  2013-04-29 11:10:17 
UTC ---

Patch at [1].



[1] http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01723.html

[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0



--- Comment #8 from Uros Bizjak  2013-04-29 11:11:28 
UTC ---

Author: uros

Date: Mon Apr 29 11:00:10 2013

New Revision: 198401



URL: http://gcc.gnu.org/viewcvs?rev=198401&root=gcc&view=rev

Log:

PR target/54349

* config/i386/i386.h (enum ix86_tune_indices)

:

New, split from X86_TUNE_INTER_UNIT_MOVES.

: Remove.

(TARGET_INTER_UNIT_MOVES_TO_VEC): New define.

(TARGET_INTER_UNIT_MOVES_FROM_VEC): Ditto.

(TARGET_INTER_UNIT_MOVES): Remove.

* config/i386/i386.c (initial_ix86_tune_features): Update.

Disable X86_TUNE_INTER_UNIT_MOVES_FROM_VEC for m_ATHLON_K8 only.

(ix86_expand_convert_uns_didf_sse): Use

TARGET_INTER_UNIT_MOVES_TO_VEC instead of TARGET_INTER_UNIT_MOVES.

(ix86_expand_vector_init_one_nonzero): Ditto.

(ix86_expand_vector_init_interleave): Ditto.

(inline_secondary_memory_needed): Return true for moves from SSE class

registers for !TARGET_INTER_UNIT_MOVES_FROM_VEC targets and for moves

to SSE class registers for !TARGET_INTER_UNIT_MOVES_TO_VEC targets.

* config/i386/constraints.md (Yi, Ym): Depend on

TARGET_INTER_UNIT_MOVES_TO_VEC.

(Yj, Yn): New constraints.

* config/i386/i386.md (*movdi_internal): Change constraints of

operand 1 from Yi to Yj and from Ym to Yn.

(*movsi_internal): Ditto.

(*movdf_internal): Ditto.

(*movsf_internal): Ditto.

(*float2_1): Use

TARGET_INTER_UNIT_MOVES_TO_VEC instead of TARGET_INTER_UNIT_MOVES.

(*float2_1 splitters): Ditto.

(floatdi2_i387_with_xmm): Ditto.

(floatdi2_i387_with_xmm splitters): Ditto.

* config/i386/sse.md (movdi_to_sse): Ditto.

(sse2_stored): Change constraint of operand 1 from Yi to Yj.

Use TARGET_INTER_UNIT_MOVES_FROM_VEC instead of

TARGET_INTER_UNIT_MOVES.

(sse_storeq_rex64): Change constraint of operand 1 from Yi to Yj.

(sse_storeq_rex64 splitter): Use TARGET_INTER_UNIT_MOVES_FROM_VEC

instead of TARGET_INTER_UNIT_MOVES.

* config/i386/mmx.md (*mov_internal): Change constraint of

operand 1 from Yi to Yj and from Ym to Yn.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/constraints.md

trunk/gcc/config/i386/i386.c

trunk/gcc/config/i386/i386.h

trunk/gcc/config/i386/i386.md

trunk/gcc/config/i386/mmx.md

trunk/gcc/config/i386/sse.md

[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #9 from Uros Bizjak  2013-04-29 11:12:31 
UTC ---

Fixed for 4.9.0.

[Bug sanitizer/57104] ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable

[mpolacek at gcc dot gnu.org]

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



--- Comment #2 from Marek Polacek  2013-04-29 
11:14:00 UTC ---

Happens since beginning of tsan; thus http://gcc.gnu.org/r193736

[Bug middle-end/57089] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #2 from Richard Biener  2013-04-29 
11:32:02 UTC ---

Author: rguenth

Date: Mon Apr 29 11:31:33 2013

New Revision: 198409



URL: http://gcc.gnu.org/viewcvs?rev=198409&root=gcc&view=rev

Log:

2013-04-29  Richard Biener  



PR middle-end/57089

* omp-low.c (expand_omp_taskreg): If the parent function had

a broken loop tree make sure to schedule a fixup for the child

as well.

(expand_omp_for_generic): Properly add loops.

(expand_omp_for_static_nochunk): Likewise.

(expand_omp_for_static_chunk): Likewise.

(expand_omp_for): For the degenerate case fixup loops.

(expand_omp_sections): Fix default bb placement in loops.

(expand_omp_atomic_pipeline): Properly add loops.



* gfortran.dg/gomp/pr57089.f90: New testcase.



Added:

trunk/gcc/testsuite/gfortran.dg/gomp/pr57089.f90

Modified:

trunk/gcc/ChangeLog

trunk/gcc/omp-low.c

trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/57110] is the use of "uint_fast32_t" in intentional?

[vincenzo.innocente at cern dot ch]

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



--- Comment #2 from vincenzo Innocente  
2013-04-29 11:47:54 UTC ---

Understood.

The question should than be escalated to the c++ standard committee



In my opinion the use of a 32-bit unsigned int as storage and return type for a

mersenne_twister_engine

with word_size=32 is wrong (besides being unnecessary and inefficient)



in any case std::mt19937 is just a type alias: users can define their own using

uint32_t in case they care of computational efficiency.

[Bug libstdc++/57110] is the use of "uint_fast32_t" in intentional?

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2013-04-29 
11:50:40 UTC ---

Send an email to your colleague Walter Brown @ FNAL, I'm sure he is interested.

[Bug target/57108] [4.7/4.8/4.9] SH internal compiler error: in int_mode_for_mode, at stor-layout.c:395

[chrbr at gcc dot gnu.org]

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



chrbr at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #1 from chrbr at gcc dot gnu.org 2013-04-29 12:15:25 UTC ---

committed on 4.7, 4.8, 4.9 branches @r198411.

[Bug target/57097] [4.8/4.9 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 CC||mpolacek at gcc dot

   ||gnu.org, vmakarov at gcc

   ||dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2013-04-29 
12:24:41 UTC ---

Confirmed.  Started with gcc.gnu.org/r193588

[Bug c++/57111] New: Core dump - invalid pointer detected after std::unique_ptr

[jb.1234abcd at gmail dot com]

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



 Bug #: 57111

   Summary: Core dump - invalid pointer detected after

std::unique_ptr

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jb.1234a...@gmail.com





$ cat uniqueptr.cpp

#include 

#include 



int main () {

  int arr[]={1,2};

  std::unique_ptr up(arr);

  std::cout << up[0];

  return 0;

}

$ g++ -std=c++11 -Wall -o uniqueptr uniqueptr.cpp 

$ ./uniqueptr 

*** glibc detected *** ./uniqueptr: free(): invalid pointer: 0xbfe35788 ***

=== Backtrace: =

/lib/libc.so.6[0x4ce44ff9]

/lib/libstdc++.so.6(_ZdlPv+0x20)[0x4d414500]

/lib/libstdc++.so.6(_ZdaPv+0x1c)[0x4d41455c]

./uniqueptr[0x80489fd]

./uniqueptr[0x8048966]

./uniqueptr[0x8048765]

/lib/libc.so.6(__libc_start_main+0xf5)[0x4cde8865]

./uniqueptr[0x8048611]

=== Memory map: 

08048000-0804a000 r-xp  08:09 1963079/home/jb/prog-c++/uniqueptr

0804a000-0804b000 r--p 1000 08:09 1963079/home/jb/prog-c++/uniqueptr

0804b000-0804c000 rw-p 2000 08:09 1963079/home/jb/prog-c++/uniqueptr

08dbf000-08de rw-p  00:00 0  [heap]

4cdac000-4cdcb000 r-xp  08:09 655817 /usr/lib/ld-2.16.so

4cdcb000-4cdcc000 r--p 0001e000 08:09 655817 /usr/lib/ld-2.16.so

4cdcc000-4cdcd000 rw-p 0001f000 08:09 655817 /usr/lib/ld-2.16.so

4cdcf000-4cf7f000 r-xp  08:09 659071 /usr/lib/libc-2.16.so

4cf7f000-4cf81000 r--p 001b 08:09 659071 /usr/lib/libc-2.16.so

4cf81000-4cf82000 rw-p 001b2000 08:09 659071 /usr/lib/libc-2.16.so

4cf82000-4cf85000 rw-p  00:00 0 

4cfce000-4d00c000 r-xp  08:09 664509 /usr/lib/libm-2.16.so

4d00c000-4d00d000 r--p 0003d000 08:09 664509 /usr/lib/libm-2.16.so

4d00d000-4d00e000 rw-p 0003e000 08:09 664509 /usr/lib/libm-2.16.so

4d01-4d02c000 r-xp  08:09 664696

/usr/lib/libgcc_s-4.7.2-20121109.so.1

4d02c000-4d02d000 r--p 0001b000 08:09 664696

/usr/lib/libgcc_s-4.7.2-20121109.so.1

4d02d000-4d02e000 rw-p 0001c000 08:09 664696

/usr/lib/libgcc_s-4.7.2-20121109.so.1

4d3c9000-4d4a9000 r-xp  08:09 664705 /usr/lib/libstdc++.so.6.0.17

4d4a9000-4d4ad000 r--p 000df000 08:09 664705 /usr/lib/libstdc++.so.6.0.17

4d4ad000-4d4af000 rw-p 000e3000 08:09 664705 /usr/lib/libstdc++.so.6.0.17

4d4af000-4d4b5000 rw-p  00:00 0 

b000-b777a000 rw-p  00:00 0 

b778b000-b778e000 rw-p  00:00 0 

b778e000-b778f000 r-xp  00:00 0  [vdso]

bfe17000-bfe38000 rw-p  00:00 0  [stack]

1Aborted (core dumped)

$ 



Packages:

gcc-c++-4.7.2-8.fc18.i686

glibc-2.16-30.fc18.i686

libstdc++-4.7.2-8.fc18.i686

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2013-04-29 
12:40:50 UTC ---
(In reply to comment #8)
> There are a quite a few problems it seems:
>  1. we rely on s1->attr.function _and_ s2->attr.function being set, which is
> obviously not the case with implicit typing.

I think the simplest fix is to do the following:

If (dummy->attr.function && actual_argument->attr.external
&& !actual_argument->attr.subroutine)
  Implicitly-type-the-actual-argument;

The Fortran standard requires that all external procedures which are used as
actual argument have the "external" attribute. (To distinguish them from
variables.)

And "12.4.3.4.5 Restrictions on generic declarations" ensures that either a
subroutine or a function but never both is used for a given argument:

"Two dummy arguments are distinguishable if
* one is a procedure and the other is a data object,
* they are both data objects or known to be functions, and neither is TKR
compatible with the other,
* one is a function with nonzero rank and the other is not known to be a
function.
[...]"


One just has to ensure that
  external :: sub
  call foo(sub)
doesn't get the function attribute and typed when first checking "one" for a
possible match:
  interface foo
subrouine one(f,y)
  real, external :: f
  integer :: y
end
subroutine two(s)
  external :: s
end
  end interface


BTW: When updating this, one can also implement the new Fortran 2008 feature:
"ALLOCATABLE and POINTER attributes are used in generic resolution.
Procedureness of a dummy argument is used in generic resolution." (I think the
first one is already implemented.) -> F2008, 12.4.3.4.5

[Bug target/57112] New: -march=x86-64 not documented

[glisse at gcc dot gnu.org]

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



 Bug #: 57112

   Summary: -march=x86-64 not documented

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: documentation

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: gli...@gcc.gnu.org

Target: x86_64-linux-gnu





Hello,



for people who have a gcc that was configured with some non-default --with-arch

but who want to build a generic binary, an option like -march=generic would be

useful. It seems that the right spelling is -march=x86-64, but I couldn't find

that documented in invoke.texi.

[Bug tree-optimization/54295] [4.7 Regression] Widening multiply-accumulate operation uses wrong value extension

[jogo at openwrt dot org]

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



Jonas Gorski  changed:



   What|Removed |Added



 CC||jogo at openwrt dot org



--- Comment #9 from Jonas Gorski  2013-04-29 12:56:23 
UTC ---

I want to confirm that this is still an issue in 4.7.3, also applies to at

least mips32 (did not test mips64) and causes miscompilations in the linux

kernel there.

[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Jonathan Wakely  2013-04-29 
12:57:36 UTC ---

That's not how you use unique_ptr.

[Bug tree-optimization/57075] [4.9 Regression] verify_flow_info failed: control flow in the middle of basic block

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #9 from Richard Biener  2013-04-29 
12:58:47 UTC ---

I have a patch.

[Bug target/57112] -march=x86-64 not documented

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-04-29 
12:59:28 UTC ---

Yes, I only learned about it from reading the sources.

[Bug middle-end/57103] [4.8/4.9 Regression] ICE: verify_gimple failed: location references block not in block tree with -ftree-parallelize-loops=4

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #2 from Marek Polacek  2013-04-29 
13:11:12 UTC ---

Started with http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=195147

[Bug target/57098] ICE: in extract_insn, at recog.c:2154 (unrecognizable insn) with -mcmodel=large -msse4 and __builtin_shuffle()

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2013-04-29 
13:13:19 UTC ---

Confirmed.

[Bug c++/57113] New: cannot resolve function in derived class

[gcc at 01 dot crabdance.com]

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



 Bug #: 57113

   Summary: cannot resolve function in derived class

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@01.crabdance.com





Created attachment 29972

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29972

preprocessed source file



source :



class ClassA

{

public:

virtual void meth(int n);

virtual void meth(const char* s, bool q);

};



class ClassB : public ClassA

{

public:

virtual void meth(int n);

};



void ClassA::meth(int n)

{

}



void ClassA::meth(const char* s, bool q)

{

}



void ClassB::meth(int n)

{

}





int main(int argc, char** argv)

{

const char* param = "foobar";

ClassB inst;



inst.meth(param, false);



return 0;

}





"gcc -v" :



Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper

Target: i686-pc-linux-gnu

Configured with: ./gcc-4.8.0/configure --with-gnu-ld --with-pic --prefix=/usr

--with-local-prefix=/usr/local --sysconfdir=/etc --program-suffix=-4.8.0

--disable-nls --with-system-zlib --enable-shared --enable-__cxa_atexit

--enable-threads=posix --enable-tls --with-__thread --enable-cpp

--enable-languages=c,c++ --enable-version-specific-runtime-libs

Thread model: posix

gcc version 4.8.0 (GCC)





"gcc test.cc -save-temps" :



test.cc: In function 'int main(int, char**)':

test.cc:33:27: error: no matching function for call to 'ClassB::meth(const

char*&, bool)'

 inst.meth(param, false);

   ^

test.cc:33:27: note: candidate is:

test.cc:23:6: note: virtual void ClassB::meth(int)

 void ClassB::meth(int n)

  ^

test.cc:23:6: note:   candidate expects 1 argument, 2 provided







maybe this is the correct behaviour, but i'd expect it to work



some typecasting let's us call the function w/o trouble:

((ClassA*)&inst)->meth(param, false);





thank you

[Bug c++/56450] ICE with SFINAE when detecting non-static member variable

[jason at gcc dot gnu.org]

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



--- Comment #5 from Jason Merrill  2013-04-29 
14:03:25 UTC ---

Let's put this into 4.8.1 as well; it's completely safe.

[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr

[jb.1234abcd at gmail dot com]

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



--- Comment #2 from jb  2013-04-29 14:04:38 UTC 
---

(In reply to comment #1)

> That's not how you use unique_ptr.



That's besides the point when you get a dump.

If the proper use of unique_ptr with array is:

unique_ptr up(new int[4]); //array version of unique_ptr

then the compiler should give a warning on "improper use", do not you think ?

[Bug c++/56450] ICE with SFINAE when detecting non-static member variable

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2013-04-29 
14:08:28 UTC ---

Ok.

[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2013-04-29 
14:09:46 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> > That's not how you use unique_ptr.

> 

> That's besides the point when you get a dump.



No, it's entirely the point, you get a coredump because your program has

undefined behaviour when it attempts to delete a stack variable.



> If the proper use of unique_ptr with array is:

> unique_ptr up(new int[4]); //array version of unique_ptr

> then the compiler should give a warning on "improper use", do not you think ?



The compiler can't warn about everything.  Sometimes you just have to meet the

requirements of the API you're using and not to stupid things.

[Bug c++/57113] cannot resolve function in derived class

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Jonathan Wakely  2013-04-29 
14:12:45 UTC ---

(In reply to comment #0)

> maybe this is the correct behaviour, but i'd expect it to work



This is the correct behaviour, search the web for "name hiding"

[Bug middle-end/57103] [4.8/4.9 Regression] ICE: verify_gimple failed: location references block not in block tree with -ftree-parallelize-loops=4

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Biener  2013-04-29 
14:14:46 UTC ---

Author: rguenth

Date: Mon Apr 29 14:12:54 2013

New Revision: 198418



URL: http://gcc.gnu.org/viewcvs?rev=198418&root=gcc&view=rev

Log:

2013-04-29  Richard Biener  



PR middle-end/57103

* tree-cfg.c (move_stmt_op): Fix condition under which to update

TREE_BLOCK.

(move_stmt_r): Remove redundant checking.



* gcc.dg/autopar/pr57103.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/autopar/pr57103.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-cfg.c



Author: rguenth

Date: Mon Apr 29 14:14:05 2013

New Revision: 198419



URL: http://gcc.gnu.org/viewcvs?rev=198419&root=gcc&view=rev

Log:

2013-04-29  Richard Biener  



PR middle-end/57103

* tree-cfg.c (move_stmt_op): Fix condition under which to update

TREE_BLOCK.

(move_stmt_r): Remove redundant checking.



* gcc.dg/autopar/pr57103.c: New testcase.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/autopar/pr57103.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/gcc/tree-cfg.c

[Bug c++/56450] ICE with SFINAE when detecting non-static member variable

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



   Target Milestone|4.9.0   |4.8.1

[Bug web/57114] New: wrong information at http://gcc.gnu.org/onlinedocs/gfortran/RANK.html

[kay.diederi...@uni-konstanz.de]

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



 Bug #: 57114

   Summary: wrong information at

http://gcc.gnu.org/onlinedocs/gfortran/RANK.html

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: web

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: kay.diederi...@uni-konstanz.de





There are are at least two things wrong at in the documentation of gfortran's

RANK intrinsic at http://gcc.gnu.org/onlinedocs/gfortran/RANK.html :



First,

RESULT = RANGE(A) 

should read

RESULT = RANK(A)



and second, the example should have

print *, rank(a), rank(b) ! Prints:  0  2

instead of

print *, rank(a), rank(b) ! Prints:  0  3

[Bug fortran/39290] Subroutine/function ambiguity in generics

[janus at gcc dot gnu.org]

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



--- Comment #10 from janus at gcc dot gnu.org 2013-04-29 14:53:03 UTC ---

(In reply to comment #9)

> BTW: When updating this, one can also implement the new Fortran 2008 feature:

> "ALLOCATABLE and POINTER attributes are used in generic resolution.

> Procedureness of a dummy argument is used in generic resolution." (I think the

> first one is already implemented.) -> F2008, 12.4.3.4.5



cf. PR 45521

[Bug tree-optimization/57075] [4.9 Regression] verify_flow_info failed: control flow in the middle of basic block

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Richard Biener  2013-04-29 
15:06:39 UTC ---

Author: rguenth

Date: Mon Apr 29 15:06:18 2013

New Revision: 198423



URL: http://gcc.gnu.org/viewcvs?rev=198423&root=gcc&view=rev

Log:

2013-04-29  Richard Biener  



PR middle-end/57075

* tree-inline.c (copy_edges_for_bb): Still split the bbs,

even if not adding abnormal edges for calls that can make

abnormal gotos.



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



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr57075.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-inline.c

[Bug target/57098] ICE: in extract_insn, at recog.c:2154 (unrecognizable insn) with -mcmodel=large -msse4 and __builtin_shuffle()

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com

   |gnu.org |

   Target Milestone|--- |4.7.4



--- Comment #2 from Uros Bizjak  2013-04-29 15:26:09 
UTC ---

A bunch of validize_mem calls are missing. Patch in testing:



--cut here--

Index: i386.c

===

--- i386.c  (revision 198401)

+++ i386.c  (working copy)

@@ -20559,7 +20559,7 @@ ix86_expand_vec_perm (rtx operands[])

  vec[i * 2 + 1] = const1_rtx;

}

  vt = gen_rtx_CONST_VECTOR (maskmode, gen_rtvec_v (w, vec));

- vt = force_const_mem (maskmode, vt);

+ vt = validize_mem (force_const_mem (maskmode, vt));

  t1 = expand_simple_binop (maskmode, PLUS, t1, vt, t1, 1,

OPTAB_DIRECT);



@@ -20756,7 +20756,7 @@ ix86_expand_vec_perm (rtx operands[])

   for (i = 0; i < 16; ++i)

vec[i] = GEN_INT (i/e * e);

   vt = gen_rtx_CONST_VECTOR (V16QImode, gen_rtvec_v (16, vec));

-  vt = force_const_mem (V16QImode, vt);

+  vt = validize_mem (force_const_mem (V16QImode, vt));

   if (TARGET_XOP)

emit_insn (gen_xop_pperm (mask, mask, mask, vt));

   else

@@ -20767,7 +20767,7 @@ ix86_expand_vec_perm (rtx operands[])

   for (i = 0; i < 16; ++i)

vec[i] = GEN_INT (i % e);

   vt = gen_rtx_CONST_VECTOR (V16QImode, gen_rtvec_v (16, vec));

-  vt = force_const_mem (V16QImode, vt);

+  vt = validize_mem (force_const_mem (V16QImode, vt));

   emit_insn (gen_addv16qi3 (mask, mask, vt));

 }



--cut here--

[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022

[danglin at gcc dot gnu.org]

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



John David Anglin  changed:



   What|Removed |Added



 CC||amylaar at gcc dot gnu.org

  Component|translation |tree-optimization



--- Comment #1 from John David Anglin  2013-04-29 
15:33:33 UTC ---

Introduced in r197668:



2013-04-10  Joern Rennecke 



PR tree-optimization/55524

* tree-ssa-math-opts.c

(convert_mult_to_fma): Don't use an fms construct

when we don't have an fms operation, but fnma, and it looks

likely that we'll be able to use the latter.

Re: Bug bootstrap/56714

[Kai-Uwe Eckhardt]

The same error appears on NetBSD 6.99.19 because __always_inline
is already defined without the inline keyword in sys/cdefs.h. 
Including the inline keyword in the macro wouldn't work if the macro
is used at the very end of a declaration like in:
inline void foo (const char) __always_inline;

To compile this I just declared 

#define __inline__always_inline  inline __attribute__((always_inline))

and changed every occurence of __always_inline with __inline_always_inline.

Kai-Uwe

[Bug target/56866] [4.7/4.8/4.9 Regression] with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

[winfried.mag...@t-online.de]

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



--- Comment #17 from Winfried Magerl  2013-04-29 
16:08:09 UTC ---

Hi Jakub,



On Fri, Apr 26, 2013 at 09:00:42AM +, jakub at gcc dot gnu.org wrote:

>  

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

>  

> --- Comment #14 from Jakub Jelinek  2013-04-26 
> 09:00:42 UTC --- 

> Created attachment 29944 

>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29944 

> gcc49-pr56866.patch 

>  

> The fix for gcc.c-torture/execute/pr51581* and pr53645.c etc. is quite 
> obvious, 

> we obviously can't use xop_pmacsdqh with unsigned highpart odd 
> multiplication, 

> say for the pr51581-1.c unsigned division by 3U, which is high part 

> multiplication by 0xaaabU, with the result shifted right by 1 at the end. 

> If we compute say 3ULL * 0xaaabULL, we can't use xop_pmacsdqh which 

> computes 

> 3LL * 0xaaabLL instead. 

>  

> That said, there are no vpmacsdqh insns in the sha512 code for -O3 

> -march=bdver2, so it must be something else. 



I've verified that the problem with the sha512 code build with

'-O3 -mxop' is also fixed. I've attached sha512.s.diff with the

diff of the generated assembler-code (gcc-4_8-branch revision 198317

compared with gcc-4_8-branch revision 198422).



Most lines looks like this:



-   vprotq  $-45, %xmm0, %xmm4

-   vprotq  $-3, %xmm0, %xmm3

+   vprotq  $3, %xmm0, %xmm4

+   vprotq  $45, %xmm0, %xmm3



Many thanks for looking at this issue! I will run the complete

gcc-test-suite to see the difference and later on I will check

glibc-testsuite too.



It might be a good idea to look at the other open bugs tagged

with bdver or xop.



regards



winfried

[Bug c++/57107] tree check fail in unlink_stmt_vdef

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 CC||mpolacek at gcc dot

   ||gnu.org, rguenth at gcc dot

   ||gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Marek Polacek  2013-04-29 
16:31:26 UTC ---

Confirmed.  Started with http://gcc.gnu.org/r198096

[Bug lto/57084] 483. xalancbmk run fails with -O2 -flto for i686

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-29

 CC|mjambor at suse dot cz  |jamborm at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Martin Jambor  2013-04-29 
16:34:16 UTC ---

I have reproduced the problem and will investigate, LTOishness of this

problem is rather interesting.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

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



Teresa Johnson  changed:



   What|Removed |Added



 CC||tejohnson at google dot com



--- Comment #7 from Teresa Johnson  2013-04-29 
16:44:10 UTC ---

*** Update on below text: As of r198401 the problem is hidden unless compiling

with -mtune=athlon64 due to some tuning changes. ***



I have another instance of this issue. Trunk is generating move instructions to

implement an inlined memcpy. The move instructions use the MMX registers, but

no EMMS instruction is generated. My testcase then calls a libm function that

uses the FPU, which returns incorrect results. This worked with an older gcc

4.7 based compiler, which didn't use MMX registers.



The compiler was configured for x86_64-unknown-linux-gnu. The testcase was

compiled with -O2.



$ cat test.cc

#include 

#include 

#include 

#include 



namespace {

volatile double dd = 0.080553657784353652;

double dds, ddc;

}



unsigned long long test(float num) {

  if (num < 0) {

num = 0;

  }



  unsigned int i;

  memcpy(&i, &num, sizeof(unsigned int));

  unsigned long long a = i;



  sincos(dd, &dds, &ddc);

  if (isnan(dds) || isnan(ddc))

  {

printf ("Failed\n");

exit (1);

  }

  return a;

}



$ cat test_main.cc

#include 



extern unsigned long long test(float num);

int main()

{

  unsigned long long h = test(1);

  printf ("Passed\n");

}



$ g++ -O2 test*.cc -mtune=athlon64 (See earlier note on why -mtune=athlon64 is

needed here)



$ a.out

Failed

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[dnovillo at google dot com]

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



--- Comment #21 from dnovillo at google dot com  
2013-04-29 16:46:27 UTC ---

On 2013-04-29 11:25 , jakub at gcc dot gnu.org wrote:

> Any progress with this?  We'd like to do 4.8.1-rc1 in mid-May, would be nice 
> to

> have this resolved till then.

>



None at all, sorry.  I will try to work on this after I get back (early 

next week).





Diego.

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

[gretay at gcc dot gnu.org]

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



--- Comment #4 from gretay at gcc dot gnu.org 2013-04-29 16:58:34 UTC ---

Created attachment 29974

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29974

testcase



The attached test case fails for arm-none-eabi on trunk, caused by r198096 (the

fix for PR56982). It seems related to this PR because the control flow edge

after testing the return value of malloc disappears and it is sensitive to the

setjmp() call placement.



Compile with:

/work/apr-builds/r198096/install/bin/arm-none-eabi-gcc -O1 -mcpu=cortex-a15

pr57067.c -o bad.elf

The test case should print PASS, but it prints FAIL.

[Bug target/46250] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -fPIC -mcmodel=large and __thread variable

[hjl.tools at gmail dot com]

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



--- Comment #5 from H.J. Lu  2013-04-29 17:09:22 
UTC ---

TLS ABI only covers the small model.  There is no demand to

extend TLS ABI to support medium/large models.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

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



--- Comment #8 from Uros Bizjak  2013-04-29 17:13:30 
UTC ---

Please try following patch, it fixes the testcase for me (note "!" for ?*y

alternative):



--cut here--

Index: i386.md

===

--- i386.md (revision 198401)

+++ i386.md (working copy)

@@ -3049,10 +3049,10 @@



 (define_insn "*zero_extendsidi2"

   [(set (match_operand:DI 0 "nonimmediate_operand"

-   "=r,?r,?o,r   ,o,?*Ym,?*y,?*Yi,?*x")

+   "=r,?r,?o,r   ,o,?*Ym,?!*y,?*Yi,?*x")

(zero_extend:DI

 (match_operand:SI 1 "x86_64_zext_operand"

-   "0 ,rm,r ,rmWz,0,r   ,m  ,r   ,m")))]

+   "0 ,rm,r ,rmWz,0,r   ,m   ,r   ,m")))]

   ""

 {

   switch (get_attr_type (insn))

--cut here--

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

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



--- Comment #9 from Teresa Johnson  2013-04-29 
17:24:42 UTC ---

It does fix the issue I had in this test case. But theoretically can't

this pattern still generate an MMX reference in some cases? And I see

other instances of the same constraint in i386.md - is there a larger

issue here and how can we prevent this?



Thanks!

Teresa



On Mon, Apr 29, 2013 at 10:13 AM, ubizjak at gmail dot com

 wrote:

>

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

>

> --- Comment #8 from Uros Bizjak  2013-04-29 
> 17:13:30 UTC ---

> Please try following patch, it fixes the testcase for me (note "!" for ?*y

> alternative):

>

> --cut here--

> Index: i386.md

> ===

> --- i386.md (revision 198401)

> +++ i386.md (working copy)

> @@ -3049,10 +3049,10 @@

>

>  (define_insn "*zero_extendsidi2"

>[(set (match_operand:DI 0 "nonimmediate_operand"

> -   "=r,?r,?o,r   ,o,?*Ym,?*y,?*Yi,?*x")

> +   "=r,?r,?o,r   ,o,?*Ym,?!*y,?*Yi,?*x")

> (zero_extend:DI

>  (match_operand:SI 1 "x86_64_zext_operand"

> -   "0 ,rm,r ,rmWz,0,r   ,m  ,r   ,m")))]

> +   "0 ,rm,r ,rmWz,0,r   ,m   ,r   ,m")))]

>""

>  {

>switch (get_attr_type (insn))

> --cut here--

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

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



--- Comment #10 from Uros Bizjak  2013-04-29 17:37:03 
UTC ---

(In reply to comment #9)

> It does fix the issue I had in this test case. But theoretically can't

> this pattern still generate an MMX reference in some cases? And I see

> other instances of the same constraint in i386.md - is there a larger

> issue here and how can we prevent this?



Yes, leaks of MMX registers were quite problematic in the past. A lot of effort

went into insn patterns to balance register allocator to allow MMX registers

when necessary, and to avoid them otherwise. It looks that zero_extendsidi

pattern was skipped in these efforts.



-mno-mmx can be used to prevent MMX regs, but the allocator is quite well tuned

nowadays, so instantiation of %mmX registers when not strictly needed will be

considered a bug.

[Bug fortran/57114] wrong information at http://gcc.gnu.org/onlinedocs/gfortran/RANK.html

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-04-29 
18:05:20 UTC ---

Author: burnus

Date: Mon Apr 29 18:05:00 2013

New Revision: 198429



URL: http://gcc.gnu.org/viewcvs?rev=198429&root=gcc&view=rev

Log:

2013-04-28  Tobias Burnus  



PR fortran/57114

* intrinsic.texi (RANK): Correct syntax description and

expected result.





Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/intrinsic.texi

[Bug fortran/57114] wrong information at http://gcc.gnu.org/onlinedocs/gfortran/RANK.html

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Tobias Burnus  2013-04-29 
18:05:45 UTC ---

FIXED on the trunk (GCC 4.9).



Thanks for the report!

[Bug sanitizer/57104] ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

Version|4.9.0   |4.8.1

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.8.1



--- Comment #3 from Jakub Jelinek  2013-04-29 
19:15:23 UTC ---

Fix: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01752.html

[Bug libgcc/57085] Segmentation Fault when building a c file

[mikpe at it dot uu.se]

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



--- Comment #11 from Mikael Pettersson  2013-04-29 
19:30:35 UTC ---

I can't reproduce the ICE with a cross to arm-linux-androideabi either.

[Bug bootstrap/57077] [4.9 Regression] LTO bootstrap failure with profiledbootstrap

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #1 from H.J. Lu  2013-04-29 19:32:58 
UTC ---

Fixed as of revision 198426.

[Bug gcov-profile/57115] New: Cannot merge separate single counters for function

[asharif at gcc dot gnu.org]

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



 Bug #: 57115

   Summary: Cannot merge separate single counters for function

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: gcov-profile

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: asha...@gcc.gnu.org





Created attachment 29975

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29975

source + .gcda file.



These files are from profiling WebKit.



To reproduce the error, run:



g++ -Werror -pthread -fno-exceptions -fno-strict-aliasing -Wall

-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe

-fPIC -g -fno-strict-aliasing -O2 -fno-ident -fdata-sections

-ffunction-sections -g -Wno-c++0x-compat -fno-rtti -fno-threadsafe-statics

-fvisibility-inlines-hidden -Wsign-compare -fstack-protector-strong

-fprofile-use -fprofile-correction -o EventContext.o EventContext.ii



This was run on a system that defines TARGET_POSIX_IO so there shouldn't be a

problem writing profiles from multiple threads/processes, right?

[Bug fortran/57116] New: ICE for pointer assignment inside SELECT TYPE on UP entity

[Bader at lrz dot de]

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



 Bug #: 57116

   Summary: ICE for pointer assignment inside SELECT TYPE on UP

entity

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ba...@lrz.de





Created attachment 29976

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29976

module and main program as standalone source.



The attached Fortran source produces the following error message with gfortran

4.8.0:



rtti_pointerassign_02_pos.f90: In function `extract':

rtti_pointerassign_02_pos.f90:13:0: internal compiler error: Segmentation fault

extract => this(ic:)

 ^

0x87e07f crash_signal

../../gcc-4.8.0/gcc/toplev.c:332

0x5d2db2 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)

../../gcc-4.8.0/gcc/fortran/trans-expr.c:6555

0x5a7896 trans_code

../../gcc-4.8.0/gcc/fortran/trans.c:1439

0x5f0e28 gfc_trans_block_construct(gfc_code*)

../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1342

0x5a76b7 trans_code

../../gcc-4.8.0/gcc/fortran/trans.c:1527

0x5f25fd gfc_trans_integer_select

../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1990

0x5f25fd gfc_trans_select(gfc_code*)

../../gcc-4.8.0/gcc/fortran/trans-stmt.c:2484

0x5a76c7 trans_code

../../gcc-4.8.0/gcc/fortran/trans.c:1543

0x5f0e28 gfc_trans_block_construct(gfc_code*)

../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1342

0x5a76b7 trans_code

../../gcc-4.8.0/gcc/fortran/trans.c:1527

0x5c4be2 gfc_generate_function_code(gfc_namespace*)

../../gcc-4.8.0/gcc/fortran/trans-decl.c:5397

0x5a8091 gfc_generate_module_code(gfc_namespace*)

../../gcc-4.8.0/gcc/fortran/trans.c:1755

0x56862b translate_all_program_units

../../gcc-4.8.0/gcc/fortran/parse.c:4455

0x56862b gfc_parse_file()

../../gcc-4.8.0/gcc/fortran/parse.c:4682

0x5a3c25 gfc_be_parse_file

../../gcc-4.8.0/gcc/fortran/f95-lang.c:189

[Bug fortran/57117] New: ICE for sourced allocation of a UP entity that uses the transpose intrinsic

[Bader at lrz dot de]

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



 Bug #: 57117

   Summary: ICE for sourced allocation of a UP entity that uses

the transpose intrinsic

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ba...@lrz.de





Created attachment 29977

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29977

module and main program as standalone source.



The attached source code causes a segfault in gfortran at compile time: 



intrinsics_02_pos.f90:61:0: internal compiler error: Segmentation fault

   allocate(y(3,3), source=transpose(x))

0x87e07f crash_signal 

../../gcc-4.8.0/gcc/toplev.c:332

0x5ad22b gfc_conv_scalarized_array_ref

../../gcc-4.8.0/gcc/fortran/trans-array.c:3037

0x5adb89 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*, locus*)

../../gcc-4.8.0/gcc/fortran/trans-array.c:3172

0x5d0cdf gfc_conv_variable

../../gcc-4.8.0/gcc/fortran/trans-expr.c:1809

0x5cddaa gfc_conv_expr(gfc_se*, gfc_expr*)

../../gcc-4.8.0/gcc/fortran/trans-expr.c:6266

0x5e158c gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)

../../gcc-4.8.0/gcc/fortran/trans-intrinsic.c:6697

0x5cd832 gfc_conv_function_expr

../../gcc-4.8.0/gcc/fortran/trans-expr.c:5547

0x5cdd1a gfc_conv_expr(gfc_se*, gfc_expr*)

../../gcc-4.8.0/gcc/fortran/trans-expr.c:6258

0x5d1d05 gfc_conv_expr_reference(gfc_se*, gfc_expr*)

../../gcc-4.8.0/gcc/fortran/trans-expr.c:6387

0x5f30be gfc_trans_allocate(gfc_code*)

../../gcc-4.8.0/gcc/fortran/trans-stmt.c:4911

0x5a7647 trans_code

../../gcc-4.8.0/gcc/fortran/trans.c:1577

0x5c4be2 gfc_generate_function_code(gfc_namespace*)

../../gcc-4.8.0/gcc/fortran/trans-decl.c:5397

0x568880 translate_all_program_units

../../gcc-4.8.0/gcc/fortran/parse.c:4468

0x568880 gfc_parse_file()

../../gcc-4.8.0/gcc/fortran/parse.c:4682

0x5a3c25 gfc_be_parse_file

../../gcc-4.8.0/gcc/fortran/f95-lang.c:189

[Bug gcov-profile/57115] Cannot merge separate single counters for function

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-04-29 
20:16:36 UTC ---

Profiling is still not thread safe.

[Bug target/57118] New: g++.dg/debug/* tests fail on MIPS due to micromips checkin, scan-assembler pattern needs update

[sje at gcc dot gnu.org]

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



 Bug #: 57118

   Summary: g++.dg/debug/* tests fail on MIPS due to micromips

checkin, scan-assembler pattern needs update

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: s...@gcc.gnu.org

CC: c...@codesourcery.com

Target: mips*-*-*





The micromips checkin changed the assembler output for MIPS by adding a '.set

nomicromips' psuedo-instruction to the instruction stream.  This is causing the

following tests to fail.  I think the fix is to update the scan pattern for

mips in gcc/testsuite/lib/scanasm.exp.  It looks for mips16/nomips16 but does

not check for micromips/nomicromips.



Tests that fail:



FAIL: g++.dg/debug/dwarf2/lineno-simple1.C -std=gnu++11  scan-assembler

\\t\\.loc [0-9]+ 13 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\tmain\\n\\t\\.type\\tmain,

@function\\nmain:\\n

FAIL: g++.dg/debug/dwarf2/lineno-simple1.C -std=gnu++11  scan-assembler

\\t\\.loc [0-9]+ 4 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN1CC[12]Ev\\n\\t\\.type\\t_ZN1CC[12]Ev,

@function\\n_ZN1CC[12]Ev:\\n

FAIL: g++.dg/debug/dwarf2/lineno-simple1.C -std=gnu++11  scan-assembler

\\t\\.loc [0-9]+ 7 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN1C3fooEv\\n\\t\\.type\\t_ZN1C3fooEv,

@function\\n_ZN1C3fooEv:\\n

FAIL: g++.dg/debug/dwarf2/lineno-simple1.C -std=gnu++98  scan-assembler

\\t\\.loc [0-9]+ 13 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\tmain\\n\\t\\.type\\tmain,

@function\\nmain:\\n

FAIL: g++.dg/debug/dwarf2/lineno-simple1.C -std=gnu++98  scan-assembler

\\t\\.loc [0-9]+ 4 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN1CC[12]Ev\\n\\t\\.type\\t_ZN1CC[12]Ev,

@function\\n_ZN1CC[12]Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr44641.C -std=gnu++11  scan-assembler \\t\\.loc

[0-9]+ 22 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN12MisplacedDbgI4FullEC[12]Ev\\n\\t\\.type\\t_ZN12MisplacedDbgI4FullEC[12]Ev,

@function\\n_ZN12MisplacedDbgI4FullEC[12]Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr44641.C -std=gnu++11  scan-assembler \\t\\.loc

[0-9]+ 22 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN12MisplacedDbgI4FullED0Ev\\n\\t\\.type\\t_ZN12MisplacedDbgI4FullED0Ev,

@function\\n_ZN12MisplacedDbgI4FullED0Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr44641.C -std=gnu++11  scan-assembler \\t\\.loc

[0-9]+ 29 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN12MisplacedDbgIP3ArgEC[12]Ev\\n\\t\\.type\\t_ZN12MisplacedDbgIP3ArgEC[12]Ev,

@function\\n_ZN12MisplacedDbgIP3ArgEC[12]Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr44641.C -std=gnu++98  scan-assembler \\t\\.loc

[0-9]+ 35 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN12MisplacedDbgI3ArgEC[12]Ev\\n\\t\\.type\\t_ZN12MisplacedDbgI3ArgEC[12]Ev,

@function\\n_ZN12MisplacedDbgI3ArgEC[12]Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr44641.C -std=gnu++98  scan-assembler \\t\\.loc

[0-9]+ 35 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN12MisplacedDbgI3ArgED0Ev\\n\\t\\.type\\t_ZN12MisplacedDbgI3ArgED0Ev,

@function\\n_ZN12MisplacedDbgI3ArgED0Ev:\\n

FAIL: g++.dg/debug/dwarf2/pr46527.C -std=gnu++11  scan-assembler \\t\\.loc

[0-9]+ 12 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN6StructIdE13defined_laterEv\\n\\t\\.type\\t_ZN6StructIdE13defined_laterEv,

@function\\n_ZN6StructIdE13defined_laterEv:\\n

FAIL: g++.dg/debug/dwarf2/pr46527.C -std=gnu++98  scan-assembler \\t\\.loc

[0-9]+ 12 0(

[^\\n]*)?\\n(\\t.cfi_startproc[^\\t]*\\n)*\\t\\.set\\t(no)?mips16\\n\\t\\.ent\\t_ZN6StructIdE13defined_laterEv\\n\\t\\.type\\t_ZN6StructIdE13defined_laterEv,

@function\\n_ZN6StructIdE13defined_laterEv:\\n

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

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



--- Comment #12 from synergye at codefi dot re 2013-04-29 21:13:10 UTC ---

(In reply to comment #11)

> I can't reproduce the ICE with a cross to arm-linux-androideabi either.



Strange. I've had others test and reproduce it as well. This seems to actually

be a trunk regression seeing as it doesn't affect the 4.8 branch at all.

[Bug fortran/57117] ICE for sourced allocation of a UP entity that uses the transpose intrinsic

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2013-04-29 
21:34:28 UTC ---

Confirmed. If I comment out the block



  call construct(x, 1)



  allocate(y(3,3), source=transpose(x))

  select type (y)

  type is(ti)

 if (y(3,1)%i /= 7) ok(5) = .false.

  class default

 ok(6) = .false.

  end select

  deallocate(y)  <--- it should be deallocate(x, y) otherwise call construct(x,

2) complains



then I get the following ICE



pr57117_db.f90: In function 'intr_02':

pr57117_db.f90:86:0: internal compiler error: in gfc_conv_procedure_call, at

fortran/trans-expr.c:4888

   allocate(z(9), source=reshape(x, (/ 9 /)))

[Bug fortran/57116] ICE for pointer assignment inside SELECT TYPE on UP entity

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2013-04-29 
21:54:39 UTC ---

Confirmed. The test passes if I define explicitly the bounds, i.e.,



  subroutine extract(this, v, ic)

class(*), target :: this(:)

real, pointer :: v(:)

integer :: ic, m, n

n = ubound(this,1)

m = n-ic+1

select type (this)

type is (real)

   v(1:m) => this(ic:n)

class is (foo)

   v(1:m) => this(ic:n)%v

end select

  end subroutine extract

[Bug fortran/56937] Unnecessarily temporary with array-vector assignments

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-29

 Ever Confirmed|0   |1



--- Comment #6 from Dominique d'Humieres  2013-04-29 
22:26:20 UTC ---

Apparently there is no dependency analysis for array-vector assignments. The

following test create a temporary that is not needed



integer :: r(10), idx(4), jdx(4)

r = [(i+10,i=1,10)]

idx = [1, 2, 3, 4]

jdx = [6, 7, 8, 9]

r(idx) = r(jdx)

print *, r

end



r(idx) = r(jdx)

 1

Warning: Creating array temporary at (1)

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[ppluzhnikov at google dot com]

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



--- Comment #27 from Paul Pluzhnikov  2013-04-29 
23:18:29 UTC ---

Here is a reduced test case in which g++ (GCC) 4.9.0 20130426 (experimental)

produces infinite loop with -O2 due to aggressive loop optimization, but

doesn't warn (making the bug in user code hard to find).



g++ -O2 test.cc -Wall && ./a.out

Segmentation fault



g++ -O2 test.cc -Wall -fno-aggressive-loop-optimizations && ./a.out && echo ok

ok





struct Puzzle

{

  int r[9];

  int ignored[18];

} p;



int a, b;

int main()

{

  int c = 0;

  for (b = 0; b < 27; b++)

{

  if (p.r[b] == 0)

c |= p.r[a];

  if (c != 0)

return c;

}

  return c;

}

[Bug libstdc++/57119] New: libstdc++-6.dll missed in default gcc 4.8 build

[dongsheng.song at gmail dot com]

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



 Bug #: 57119

   Summary: libstdc++-6.dll missed in default gcc 4.8 build

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dongsheng.s...@gmail.com





In gcc 4.7, both static and shared libstdc++ build:



i686-w64-mingw32/lib/libstdc++.a

x86_64-w64-mingw32/lib/libstdc++.a



i686-w64-mingw32/lib/libstdc++-6.dll

x86_64-w64-mingw32/lib/libstdc++-6.dll



But in gcc 4.8, no shared libstdc++ build anymore, only got static build:

lib/libstdc++.a

[Bug c/57120] New: Plain C link with libgcc_s_sjlj-1.dll which not needed

[dongsheng.song at gmail dot com]

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

 Bug #: 57120
   Summary: Plain C link with libgcc_s_sjlj-1.dll which not needed
Classification: Unclassified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dongsheng.s...@gmail.com


Here is example:

$ cat t-w32.c
long long do_div(long long a, long long b)
{
  return a/b;
}

i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
i686-w64-mingw32-objdump -x t-w32.dll  | grep "DLL Name"

gcc 4.8:
DLL Name: libgcc_s_sjlj-1.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

gcc 4.7:
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

Then I investigate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll,
I found t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:

i686-w64-mingw32-objdump -x t-w32.dll  | less

DLL Name: libgcc_s_sjlj-1.dll
vma:  Hint/Ord Member-Name Bound-To
c200   41  __divdi3
c20c  119  __udivdi3
c218  121  __umoddi3

I think this is a regress, isn't it ?


I found in gcc/config/i386/mingw32.h:

/* Include in the mingw32 libraries with libgcc */
#ifdef ENABLE_SHARED_LIBGCC
#define SHARED_LIBGCC_SPEC " \
 %{static|static-libgcc:-lgcc -lgcc_eh} \
 %{!static: \
   %{!static-libgcc: \
 %{!shared: \
   %{!shared-libgcc:-lgcc -lgcc_eh} \
   %{shared-libgcc:-lgcc_s -lgcc} \
  } \
 %{shared:-lgcc_s -lgcc} \
} \
  } "
#else
#define SHARED_LIBGCC_SPEC " -lgcc "
#endif

If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not use such
symbols like __divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.

Because both lib/libgcc_s.a (libgcc_s_sjlj-1.dll）and
lib/gcc/i686-w64-mingw32/4.8.1/libgcc.a
export these symbols:

___divdi3
___moddi3
___moddi3
...

I think this change is hastily, should be rollback, or make
libgcc_s${LIBGCC_EH_EXTN}-1.dll
DO NOT export extra symbols which not owned their self.

[Bug target/57098] ICE: in extract_insn, at recog.c:2154 (unrecognizable insn) with -mcmodel=large -msse4 and __builtin_shuffle()

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-04/msg01749.htm

   ||l



--- Comment #3 from Uros Bizjak  2013-04-30 05:34:39 
UTC ---

Author: uros

Date: Mon Apr 29 18:20:58 2013

New Revision: 198430



URL: http://gcc.gnu.org/viewcvs?rev=198430&root=gcc&view=rev

Log:

PR target/57098

* config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.



testsuite/ChangeLog:



PR target/57098

* gcc.target/i386/pr57098.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr57098.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.c

trunk/gcc/testsuite/ChangeLog



Author: uros

Date: Mon Apr 29 22:16:04 2013

New Revision: 198434



URL: http://gcc.gnu.org/viewcvs?rev=198434&root=gcc&view=rev

Log:

Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y

alternative.

(*zero_extendsidi2): Ditto.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.



testsuite/ChangeLog:



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* gcc.target/i386/pr44578.c: New test.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* gcc.target/i386/pr57098.c: New test.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr44578.c

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57098.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/config/i386/i386.c

branches/gcc-4_8-branch/gcc/config/i386/i386.md

branches/gcc-4_8-branch/gcc/config/i386/sse.md

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog



Author: uros

Date: Tue Apr 30 05:30:20 2013

New Revision: 198439



URL: http://gcc.gnu.org/viewcvs?rev=198439&root=gcc&view=rev

Log:

Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y

alternative.

(*zero_extendsidi2): Ditto.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.



testsuite/ChangeLog:



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* gcc.target/i386/pr44578.c: New test.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* gcc.target/i386/pr57098.c: New test.





Added:

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr44578.c

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr57098.c

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/i386/i386.c

branches/gcc-4_7-branch/gcc/config/i386/i386.md

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/57098] ICE: in extract_insn, at recog.c:2154 (unrecognizable insn) with -mcmodel=large -msse4 and __builtin_shuffle()

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Uros Bizjak  2013-04-30 05:35:34 
UTC ---

Fixed everywhere.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-04/msg01756.htm

   ||l

 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com

   |gnu.org |

   Target Milestone|--- |4.7.4



--- Comment #11 from Uros Bizjak  2013-04-30 05:38:48 
UTC ---

Author: uros

Date: Mon Apr 29 20:16:48 2013

New Revision: 198433



URL: http://gcc.gnu.org/viewcvs?rev=198433&root=gcc&view=rev

Log:

PR target/44578

* config/i386/i386.md (*zero_extendsidi2): Add "!" to m->?*y

alternative.



testsuite/ChangeLog:



PR target/44578

* gcc.target/i386/pr44578.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr44578.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.md

trunk/gcc/testsuite/ChangeLog



Author: uros

Date: Mon Apr 29 22:16:04 2013

New Revision: 198434



URL: http://gcc.gnu.org/viewcvs?rev=198434&root=gcc&view=rev

Log:

Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y

alternative.

(*zero_extendsidi2): Ditto.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.



testsuite/ChangeLog:



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* gcc.target/i386/pr44578.c: New test.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* gcc.target/i386/pr57098.c: New test.



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr44578.c

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57098.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/config/i386/i386.c

branches/gcc-4_8-branch/gcc/config/i386/i386.md

branches/gcc-4_8-branch/gcc/config/i386/sse.md

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog



Author: uros

Date: Tue Apr 30 05:30:20 2013

New Revision: 198439



URL: http://gcc.gnu.org/viewcvs?rev=198439&root=gcc&view=rev

Log:

Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y

alternative.

(*zero_extendsidi2): Ditto.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.



testsuite/ChangeLog:



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/44578

* gcc.target/i386/pr44578.c: New test.



Backport from mainline

2013-04-29  Uros Bizjak  



PR target/57098

* gcc.target/i386/pr57098.c: New test.





Added:

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr44578.c

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr57098.c

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/i386/i386.c

branches/gcc-4_7-branch/gcc/config/i386/i386.md

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

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



--- Comment #12 from Teresa Johnson  2013-04-30 
05:43:06 UTC ---

On Mon, Apr 29, 2013 at 10:37 AM, ubizjak at gmail dot com

 wrote:

>

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

>

> --- Comment #10 from Uros Bizjak  2013-04-29 
> 17:37:03 UTC ---

> (In reply to comment #9)

>> It does fix the issue I had in this test case. But theoretically can't

>> this pattern still generate an MMX reference in some cases? And I see

>> other instances of the same constraint in i386.md - is there a larger

>> issue here and how can we prevent this?

>

> Yes, leaks of MMX registers were quite problematic in the past. A lot of 
> effort

> went into insn patterns to balance register allocator to allow MMX registers

> when necessary, and to avoid them otherwise. It looks that zero_extendsidi

> pattern was skipped in these efforts.



Thanks for the quick fix!



>

> -mno-mmx can be used to prevent MMX regs, but the allocator is quite well 
> tuned

> nowadays, so instantiation of %mmX registers when not strictly needed will be

> considered a bug.



I found that due to the header file structure I cannot use -mno-mmx in

certain cases - i.e. when including the STL  header file

and compiling with c++11. Is this a known issue/limitation?



(after adding "#include " to the top of my test.cc test case):



$ /usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/bin/g++

-O test.cc -g -S -std=c++11 -mno-mmx

In file included from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/xmmintrin.h:35:0,

 from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/x86intrin.h:34,

 from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/bits/opt_random.h:33,

 from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/random:51,

 from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/bits/stl_algo.h:65,

 from

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/algorithm:62,

 from test.cc:6:

/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/mmintrin.h:31:3:

error: #error "MMX instruction set not enabled"

 # error "MMX instruction set not enabled"

   ^



Thanks,

Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

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



--- Comment #13 from Uros Bizjak  2013-04-30 05:53:42 
UTC ---

(In reply to comment #12)



> I found that due to the header file structure I cannot use -mno-mmx in

> certain cases - i.e. when including the STL  header file

> and compiling with c++11. Is this a known issue/limitation?



This is known non-issue; intrinsics require MMX instruction set enabled, this

is the reason why so much effort was put into this problem.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #14 from Uros Bizjak  2013-04-30 06:07:17 
UTC ---

The original problem was fixed in 4.5.



The issue with global MMX registers (Comment #3) won't be fixed - it is user

error, please see Comment #5 for the explanation. Also, according to MMX ABI,

it is user responsibility to call _mm_empty at the end of MMX intrinsics

sequence to "empty the multimedia state".



The problem from Comment #7 is fixed in 4.7.4, 4.8.1 and 4.9.0.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #28 from Jakub Jelinek  2013-04-30 
06:07:23 UTC ---

The warning is only printed if the loop has a single exit and known constant

iteration count without the undefined behavior analysis, and when the warning

is printed, we don't apply the aggressive analysis anyway.



It is hard to warn in all cases, but what exactly would be the cases anyway,

the amount of surprise on undefined behavior varies a lot.



The point of the warning was to warn about the easy cases, for the rest applies

what we write in bugs.html - if a suspicious program behaviour goes away with

-fno-aggressive-loop-optimizations, most likely it is a fault of the compiled

code, not the compiler.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #29 from Jakub Jelinek  2013-04-30 
06:45:54 UTC ---

If you want another testcase which doesn't warn and is optimized based on the

assumption that undefined behavior doesn't occur, then say:

http://blog.regehr.org/archives/918#comment-8646

contains:

int a[4];



__attribute__((noinline, noclone)) int

foo (int x)

{

  int i, r = 0, n = x & 31;

  for (i = 0; i < n; i++)

r += a[i];

  return r;

}



int

main ()

{

  int x = 255;

  __asm volatile ("" : "+r" (x));

  return foo (x);

}



But in both the testcases warning is questionable, in your testcase, if p.r[0]

is non-zero and any of p.r[1] through p.r[8] is zero, then no undefined

behaviour is triggered and the program is valid, and gcc doesn't break it in

any way.

Similarly with the my testcase above and foo being called with x where the low

5 bits are 0 to 4, again, valid in that case (ignore main and the value 255

being hidden from the compiler there).

What would you like to warn about?  That if the loop is invoked with variables

and data that result in undefined behaviour that the behaviour will be

undefined?

The difference between where we know is there the compiler knows that whenever

you enter the loop construct, you will hit the undefined behavior (unless say

one of the called functions in the body throws or exits), so the level of false

positives is low.

[Bug rtl-optimization/56999] [4.8 Regression] LRA caused miscompilation of xulrunner

[evangelos at foutrelis dot com]

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



Evangelos Foutras  changed:



   What|Removed |Added



 CC||evangelos at foutrelis dot

   ||com



--- Comment #8 from Evangelos Foutras  
2013-04-30 06:57:39 UTC ---

r198082 applied on top of gcc-4.8-20130425 fixes the segfaults we were seeing

with Firefox 20 on Arch Linux. (The segfaults were reproducible only on i686

but not on x86_64.)



I assume this will get committed to the 4.8 branch soon?