[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2012-02-29 
08:12:15 UTC ---
Author: jakub
Date: Wed Feb 29 08:12:04 2012
New Revision: 184652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184652
Log:
PR bootstrap/52397
* df.h (struct df_d): Adjust comment that hard_regs_live_count
doesn't count DEBUG_INSN refs.
* df-scan.c (df_ref_create_structure): Don't set DF_HARD_REG_LIVE
for DEBUG_INSN refs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c
trunk/gcc/df.h

[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Jakub Jelinek  2012-02-29 
08:15:56 UTC ---
Fixed.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-02-29 
08:50:33 UTC ---
Post scriptum:

* For
read (*, '(i18)') i
  the value -2147483648 is accepted
  But only if one has compiled the main program with -fno-range-check.

  Cf. libgfortran/io/read.c's read_decimal function.

* For
read (*, *) i
  the value -2147483648 is always rejected, independent of that flag.

  Cf. libgfortran/io/list_read.c's convert_integer function.


Expected:

* A list-directed read gives the same result as a read with an edit descriptor.

* The value is always accepted - even without -fno-range-check.
  This flag is completely nontransparent (with regards to the run-time
library),
  it only works if the main program is compiled with that flag, and not even
  the documentation of the flag mentions that the run-time library is affected.

  See: -fno-range-check at
  http://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

  Admittedly, it is mentioned at
  http://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html

[Bug fortran/52426] ICE for c_loc with array constructor

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 CC||fxcoudert at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||sparc-linux-gnu
  Component|c   |target
  Known to work||4.5.3, 4.7.0
   Target Milestone|--- |4.6.4
Summary|ICE when compiling file |[4.6 Regression] ICE when
   |from audacious on debian|compiling file from
   |sparc   |audacious on debian sparc
  Known to fail||4.6.2

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2012-02-29 
09:13:19 UTC ---
At this point we'd need a testcase that regressed from a previous GCC release
and mark this bug as a regression.  The patch looks nearly obvious.

[Bug c/52423] [4.6 Regression] ICE in build_unary_op, at c-typeck.c:3786

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
  Component|regression  |c
Version|4.7.0   |4.6.3
   Target Milestone|--- |4.6.4
 Ever Confirmed|0   |1
  Known to fail||4.6.0

--- Comment #1 from Richard Guenther  2012-02-29 
09:15:18 UTC ---
Confirmed.

[Bug tree-optimization/52429] New: [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[Bernhard.Rosenkranzer at linaro dot org]

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

 Bug #: 52429
   Summary: [4.7 Regression] ICE in
separate_decls_in_region_debug, at tree-parloops.c:914
with -ftree-parallelize-loops
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bernhard.rosenkran...@linaro.org


Created attachment 26778
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26778
Test case (Not yet reduced)

[bero@localhost imx6-4.7]$
/opt/android-toolchain-4.7/bin/arm-linux-androideabi-g++ -c -g -O
-ftree-parallelize-loops=4 -o test.o separate_decls_in_region_debug.i
In file included from frameworks/base/include/utils/KeyedVector.h:24:0,
 from frameworks/base/opengl/libagl/TextureObjectManager.h:27,
 from
frameworks/base/opengl/libagl/TextureObjectManager.cpp:20:
frameworks/base/include/utils/SortedVector.h: In member function 'void
android::SortedVector::do_construct(void*, size_t) const [with TYPE =
android::key_value_pair_t
>; size_t = unsigned int]':
frameworks/base/include/utils/SortedVector.h:244:6: internal compiler error: in
separate_decls_in_region_debug, at tree-parloops.c:914

Current 4.6 branch is ok

[Bug c/46596] misbehavior when mixing always_inline and alias attributes in the same compilation unit

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 CC||jyasskin at gcc dot gnu.org

--- Comment #4 from Jeffrey Yasskin  2012-02-29 
09:41:05 UTC ---
glibc runs into the "sorry, unimplemented" part of the issue, with
delta-reduced code like:

$ cat test.i
typedef __builtin_va_list __gnuc_va_list;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void syslog (int __pri, const char *__fmt, ...) {
};
typedef __gnuc_va_list va_list;
void __syslog(int pri, const char *fmt, ...) {
}
extern __typeof (__syslog) syslog __attribute__ ((alias ("__syslog")));
void __vsyslog_chk(int pri, int flag, const char *fmt, va_list ap) {
  if (pri & ~(0x07|0x03f8)) {
syslog(3|0x02|0x20|0x01,
   "syslog: unknown facility/priority: %x", pri);
  }
}
$ gcc -c -O2 -Winline test.i
test.i: In function ‘__vsyslog_chk’:
test.i:7:28: sorry, unimplemented: inlining failed in call to ‘syslog’:
function body not available
test.i:10:11: sorry, unimplemented: called from here

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 


I haven't yet built a gcc from head to make sure the behavior is there without
Ubuntu's patches. The glibc problem was described at
http://plash.beasts.org/wiki/GlibcBuildIssues#head-b9149fbab065967691cf1bade23d84325c05e9b0
and reported at http://sourceware.org/bugzilla/show_bug.cgi?id=10375, but it
looks like a gcc problem to me.

[Bug tree-optimization/52430] New: [4.4 Regression] firefox miscompilation

[jakub at gcc dot gnu.org]

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

 Bug #: 52430
   Summary: [4.4 Regression] firefox miscompilation
Classification: Unclassified
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: hubi...@gcc.gnu.org, jamb...@gcc.gnu.org


The following file is miscompiled on x86_64-linux with

-quiet -fPIC  -fno-rtti -pedantic -fno-exceptions -fstack-protector --param
ssp-buffer-size=4 -m64 -mtune=generic -fpermissive -fno-exceptions
-fno-strict-aliasing -fshort-wchar -ffunction-sections -fdata-sections -Os
-freorder-blocks -fomit-frame-pointer -fpreprocessed dombindings.ii

It was "fixed" or fixed for real, not clear, by a huge
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147852
commit which I think is unlikely backportable, at least not in full.

The problem seems to be in IPA-CP/IPA-* decisions, the growStorageBy method is
called in several places in this TU with constant 1, so IPA-CP decides to clone
things, but in the end clones just calculateNewCapacity (with implied
lengthInc=1), but doesn't clone growStorageBy, eventhough the call to
calculateNewCapacity from it call the clone that assumes lengthInc is 1.
For that TU this isn't a problem, but growStorageBy is public linkonce
function,
and when mixing it with other TUs that call growStorageBy with other
parameters, if this one wins, they ignore their last parameter and grow just by
1 instead of the desired amount.
but ends up actually cloning just

[Bug tree-optimization/52430] [4.4 Regression] firefox miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-02-29 
09:47:17 UTC ---
Created attachment 26779
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26779
dombindings.ii.bz2

[Bug target/49939] [avr] Skip 2-word instructions if applicable

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2012-02-29 
09:50:24 UTC ---
Author: gjl
Date: Wed Feb 29 09:50:19 2012
New Revision: 184656

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184656
Log:
PR target/49939
* config/avr/avr.h (ASM_SPEC): Add -mno-skip-bug if we know that
the device does not have the skip-bug.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.h

[Bug libfortran/52431] New: Pass Fortran logical to C function

[only_for_nouse at gmx dot de]

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

 Bug #: 52431
   Summary: Pass Fortran logical to C function
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: only_for_no...@gmx.de


Created attachment 26780
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26780
Tar file containing a Fortran program, the C function and a small Makefile.

If passing a Fortran LOGICAL(C_BOOL) as argument to an interoperable C routine,
I always get this variable to be true in the C routine, independent of the
value passed.

Untar the attached file (it contains the Fortran and the C source files and a
Makefile) and run the Makefile. Running the resulting program with 
./pass_logical 
gives an output of
The value of the boolean argument passed is true.
The value of the boolean argument passed is true.

The second call should give a value of false.
gfortran -v gives:

COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/somepath/gcc/4.6.2/@sys/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/somepath/gcc/4.6.2/amd64_sles11
--with-mpc=/somepath/gcc/4.6.1/amd64_sles11/opt/deps
--with-mpfr=/somepath/gcc/4.6.1/amd64_sles11/opt/deps
--with-gmp=/somepath/gcc/4.6.1/amd64_sles11/opt/deps
--with-ppl=/somepath/gcc/4.6.1/amd64_sles11/opt/deps
--with-cloog=/somepath/gcc/4.6.1/amd64_sles11/opt/deps
Thread model: posix
gcc version 4.6.2 (GCC)

[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Richard Guenther  2012-02-29 
10:06:16 UTC ---
Fixed.

[Bug libfortran/52431] Pass Fortran logical to C function

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-02-29 
10:06:14 UTC ---
I think you forgot the value attribute like:
   logical(C_BOOL), value :: inbool

[Bug tree-optimization/52430] [4.4 Regression] firefox miscompilation

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.7

[Bug libfortran/52431] Pass Fortran logical to C function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-02-29 
10:10:09 UTC ---
Your code is wrong.  You need either the value attribute on the Fortran side or
change the C side to take a pointer.

[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2012-02-29 
10:06:00 UTC ---
Author: rguenth
Date: Wed Feb 29 10:05:55 2012
New Revision: 184657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184657
Log:
2012-02-29  Richard Guenther  

PR testsuite/52297
* gcc.dg/lto/trans-mem-1_0.c: Remove.
* gcc.dg/lto/trans-mem-1_1.c: Likewise.
* gcc.dg/lto/trans-mem-2_0.c: Likewise.
* gcc.dg/lto/trans-mem-2_1.c: Likewise.
* gcc.dg/lto/trans-mem-4_0.c: Likewise.
* gcc.dg/lto/trans-mem-4_1.c: Likewise.

Removed:
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-2_1.c
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-4_0.c
trunk/gcc/testsuite/gcc.dg/lto/trans-mem-4_1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||arm-linux-androideabi
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2012-02-29 
10:13:10 UTC ---
Works on x86_64 with -m32.

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-02-29 
11:09:55 UTC ---
Reducing.

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #7 from Georg-Johann Lay  2012-02-29 
11:30:14 UTC ---
(In reply to comment #6)
> Author: aoliva
> Date: Sat Feb 25 12:09:41 2012
> New Revision: 184572
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184572
> Log:
> PR debug/52001
> * alias.c (refs_newer_value_cb, refs_newer_value_p): New.
> (get_addr): Walk canonical value's locs.  Avoid returning VALUEs
> and locs that reference values newer than the non-canonical value
> at hand.  Return the canonical value as a worst case.
> (memrefs_conflict_p): Walk canonical value's locs.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/alias.c

This caused PR52417.

With alias.c at r184571 the compiler does not enter infinite loop.

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[Bernhard.Rosenkranzer at linaro dot org]

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

--- Comment #3 from Bernhard Rosenkränzer  2012-02-29 11:35:34 UTC ---
Created attachment 26781
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26781
(Mostly) reduced version of the testcase

Attaching reduced version

[Bug target/52412] another unnecessary register move on arm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #1 from Ramana Radhakrishnan  2012-02-29 
11:41:00 UTC ---
Confirmed - looks like 4.6 gets this right.

ramana

[Bug rtl-optimization/52396] Gcc failed to hoist loop invariant GOT load out of loop

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  2012-02-29 
11:43:31 UTC ---
We manage to hoist this at O2 but not at Os in 4.7 while 4.6 appears to work
fine.

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 Ever Confirmed|0   |1

--- Comment #4 from Jakub Jelinek  2012-02-29 
11:45:31 UTC ---
More reduced:

// PR tree-optimization/52429
// { dg-do compile }
// { dg-options "-O -g -ftree-parallelize-loops=4" }

struct B
{
  B () : b (__null) {}
  int *b;
};
void *
operator new (__SIZE_TYPE__, void *p)
{
  return p;
}
void
foo (B *x, unsigned y)
{
  while (y--)
new (x) B;
}

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2012-02-29 
12:09:19 UTC ---
The question is why we call delete_unreachable_blocks from
tree_function_versioning at all.  We do not bother updating the
callgraph anywhere else.

Honza, you added that beast?

[Bug c++/52432] New: [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[redi at gcc dot gnu.org]

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

 Bug #: 52432
   Summary: [C++11] -fdump-tree-gimple causes ICE: Error reporting
routines re-entered.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Created attachment 26782
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26782
testcase from PR 52427

Trunk snapshot from 20120225 gets an ICE when using -fdump-tree-gimple for the
testcase from PR 52427 

g++ main.cc -fdump-tree-gimple  -std=c++0x 

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Without -fdump-tree-gimple it compiles without error

[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)

[evstupac at gmail dot com]

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

--- Comment #2 from Stupachenko Evgeny  2012-02-29 
12:32:20 UTC ---
The difference of 2 dumps from

Arm: gcc -O3 -mfpu=neon test.c -S -ftree-vectorizer-verbose=12
X86: gcc -O3 -m32 -msse3 test.c -S -ftree-vectorizer-verbose=12

Starts at:

For Arm (can use vec_load_lanes):

6: === vect_make_slp_decision === 
6: === vect_detect_hybrid_slp ===
6: === vect_analyze_loop_operations ===
6: examining phi: in_35 = PHI 

……

6: can use vec_load_lanes 
6: vect_model_load_cost: unaligned supported by hardware. 
6: vect_model_load_cost: inside_cost = 2, outside_cost = 0 .

For x86 (no array mode for V16QI[3]):

6: === vect_make_slp_decision === 
6: === vect_detect_hybrid_slp === 
6: === vect_analyze_loop_operations === 
6: examining phi: in_35 = PHI  

.……

6: no array mode for V16QI[3] 
6: the size of the group of strided accesses is not a power of 2 
6: not vectorized: relevant stmt not supported: r_8 = *in_35; 

As I mentioned before, there is an ability for x86 to handle this (Arm can
shuffle than loads, x86 can use pshufb).

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #40 from Marc Glisse  2012-02-29 
12:32:10 UTC ---
I haven't seen it mentioned in the discussion here, but in C++11, the
definition of is_modulo was clarified as:

"True if the type is modulo. A type is modulo if, for any operation involving
+, -, or * on values of that type whose result would fall outside the range
[min(),max()], the value returned differs from the true value by an integer
multiple of max() - min() + 1."

Do people have objections to switching numeric_limits::is_modulo to
false (setting it to true when -fwrapv is used can still be discussed
afterwards)?

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2012-02-29 
12:41:15 UTC ---
I can reproduce the ICE with a cross to sparc64-linux and -fPIC -g -O2
-std=gnu99 -pthread -S -m32 -mcpu=v8.

The ICE stopped occurring on trunk with r171154:
http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00576.html
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01114.html

However that's merely a minor IRA cost tweak with no SPARC-specific bits, so I
suspect the problem is elsewhere.

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Jakub Jelinek  2012-02-29 
12:42:38 UTC ---
Created attachment 26783
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26783
gcc47-pr52429.patch

Untested fix.

[Bug libstdc++/52433] New: [C++11] debug mode iterators need move constructors

[redi at gcc dot gnu.org]

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

 Bug #: 52433
   Summary: [C++11] debug mode iterators need move constructors
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


#define _GLIBCXX_DEBUG
#include 

struct X {
X() = default;
X(const X&) = default;
X(X&&) = default;
std::vector::iterator i;
};

X f()
{
X x;
return x;
}

t.cc: In function 'X f()':
t.cc:14:12: error: use of deleted function 'X::X(X&&)'
t.cc:7:5: note: 'X::X(X&&)' is implicitly deleted because the default
definition would be ill-formed:
t.cc:7:5: error: non-static data member 'X::i' does not have a move constructor
or trivial copy constructor


Untested patch:

--- include/debug/safe_iterator.h.orig  2012-02-29 12:42:45.876490264 +
+++ include/debug/safe_iterator.h   2012-02-29 12:44:57.535918988 +
@@ -169,6 +169,19 @@
  ._M_iterator(__x, "other"));
   }

+  /// @post @p __x is singular and unattached
+  _Safe_iterator(_Safe_iterator&& __x)
+  {
+   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+   // DR 408. Is vector > forbidden?
+   _GLIBCXX_DEBUG_VERIFY(!__x._M_singular()
+ || __x._M_current == _Iterator(),
+ _M_message(__msg_init_copy_singular)
+ ._M_iterator(*this, "this")
+ ._M_iterator(__x, "other"));
+swap(*this, __x);
+  }
+
   /**
*  @brief Converting constructor from a mutable iterator to a
*  constant iterator.

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[evrinoma at gmail dot com]

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

--- Comment #7 from evrinoma at gmail dot com 2012-02-29 12:53:01 UTC ---
gdb) disassemble 0x0053e800,+32
Dump of assembler code from 0x53e800 to 0x53e820:
   0x0053e800 :movdqu -0x40(%rcx),%xmm0
   0x0053e805 :prefetcht0 0x190(%rcx)
   0x0053e80c :mov%rcx,%r10
=> 0x0053e80f :prefetchw 0x1d0(%rdi)
   0x0053e816 :add$0x4,%esi
   0x0053e819 :movaps %xmm0,(%rdi)
   0x0053e81c :movdqu -0x30(%rcx),%xmm0
End of assembler dump.
(gdb)

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[C++11] debug mode  |[C++11] debug mode
   |iterators need move |iterators need to move
   |constructors|

--- Comment #1 from Jonathan Wakely  2012-02-29 
12:58:04 UTC ---
Also needs a move-assignment operator:

#define _GLIBCXX_DEBUG
#include 

struct X {
X() = default;
X(const X&) = default;
X(X&&) = default;
X& operator=(X&&) = default;
std::vector::iterator i;
};

X f()
{
X x;
x = X();
return x;
}

[Bug c++/52432] [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-02-29 
12:58:41 UTC ---
I think it's only matter of this (untested so far):

Index: pt.c
===
--- pt.c(revision 184643)
+++ pt.c(working copy)
@@ -13918,7 +13918,8 @@
   }
 if (TREE_CODE (function) == IDENTIFIER_NODE)
   {
-unqualified_name_lookup_error (function);
+if (complain & tf_warning_or_error)
+  unqualified_name_lookup_error (function);
 release_tree_vector (call_args);
 return error_mark_node;
   }

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-02-29 
13:01:25 UTC ---
Also untested, and sub-optimal (swapping would be better than copying):

  /**
   * @brief Move assignment.
   * @post @p __x is singular and unattached
   */
  _Safe_iterator&
  operator=(_Safe_iterator&& __x)
  {
_Safe_iterator __tmp(std::move(__x));
*this = __tmp;
return *this;
  }

[Bug fortran/52387] I/O output of write after nonadvancing read

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2012-02-29 
13:02:21 UTC ---
I think it get's even messier with the following, simpler looking code, which
consists of four variants (without read/with nonadvanced read -- and with
advanced/nonadvanced write):


  OPEN (10, FILE='XXX', status='replace')
  WRITE(10, '(a)') 'ABCDEFGHIJKL'
  WRITE(10, '(a)') '1234567890ab'
  close (10)

  OPEN (10, FILE='XXX', position='REWIND', status='old', &
action='readwrite') ! or 'write'
!  READ(10, '(tr4)', advance='no') ! << add optionally
  WRITE (10, '(A)', ADVANCE='NO') 'mnop' ! << optional advance == 'yes'
  call FLUSH (10)
  call system ('cat XXX; echo "<"')
  close(10)
  call system ('cat XXX; echo "<"')
end

[With "call flush"->"flush", "system"->"execute_command_line", it should be
F2008 standard conforming.]


-

With the Cray/Open64/Pathscale compiler, one gets for instance the following:

Without READ:
mnopEFGHIJKL
1234567890ab
<
mnop
<

And with READ (and also with advance='yes') [that's Bobs example, presumably
with the output he expects]:
ABCDmnopIJKL
1234567890ab
<
ABCDmnopIJKL
<

However, without READ and advance='yes' for WRITE, one gets:
MNOP
FGHIJKL
1234567890ab
<
MNOP
<


-

By contrast, gfortran has for WRITE:
MNOP<
MNOP
<

And for READ:
ABCDMNOP<
ABCDMNOP
<

That's for advance='no'. With advance='yes', each line ends with a line break.

[Bug bootstrap/43878] Building a cross gcc fails due to a bug in the build process

[fgn123 at freenet dot de]

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

--- Comment #2 from Frank  2012-02-29 13:02:49 UTC ---
On 03.02.2012 18:56, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43878
>
> --- Comment #1 from Andrew Pinski  2012-02-03 
> 22:56:06 UTC ---
> The trick is to use --with-newlib as the stage1 compiler.
>

 Thanks a lot for the answer, I had almost forgotten about this issue
myself since I posted it a 
while ago.

 So I guess it cannot be considered a bug ?


 Frank

[Bug c++/52432] [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2012-02-29 
13:06:51 UTC ---
tf_error actually. Fixes the testcase, I'm going to regtest it.

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from William J. Schmidt  2012-02-29 
13:06:40 UTC ---
Author: wschmidt
Date: Wed Feb 29 13:06:28 2012
New Revision: 184662

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184662
Log:
2012-02-29  Bill Schmidt  

PR tree-optimization/52424
* tree-ssa-dom.c (dom_opt_leave_block): Push a marker before
calling dom_thread_across_edge.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from William J. Schmidt  2012-02-29 
13:08:15 UTC ---
Fixed.

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson  2012-02-29 
13:18:52 UTC ---
(In reply to comment #7)
> gdb) disassemble 0x0053e800,+32
> Dump of assembler code from 0x53e800 to 0x53e820:
>0x0053e800 :movdqu -0x40(%rcx),%xmm0
>0x0053e805 :prefetcht0 0x190(%rcx)
>0x0053e80c :mov%rcx,%r10
> => 0x0053e80f :prefetchw 0x1d0(%rdi)
>0x0053e816 :add$0x4,%esi
>0x0053e819 :movaps %xmm0,(%rdi)
>0x0053e81c :movdqu -0x30(%rcx),%xmm0
> End of assembler dump.
> (gdb)

prefetchw is an AMD 3dnow! instruction, I'm not surprised it SIGILLs on your
Intel Netburst/P4 based machine.

Please ensure you're not using any compilation flags that imply the presence of
an AMD processor.

[Bug target/52419] Wrong expansion of misaligned vector store

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-02-29
 Resolution|DUPLICATE   |
 Ever Confirmed|0   |1

--- Comment #2 from Martin Jambor  2012-02-29 
13:19:56 UTC ---
Well, it turns out that even with Richi's patch the exact same
testcase fails at -O1 and higher.  Thus, reopening.

[Bug target/52419] Wrong expansion of misaligned vector store

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #3 from Richard Guenther  2012-02-29 
13:28:00 UTC ---
Confirmed.

foo:
.LFB0:
.cfi_startproc
pxor%xmm1, %xmm1
movhps  .LC0(%rip), %xmm1
movdqu  %xmm1, (%rdi)
ret

it looks like 

(insn 6 5 7 (set (reg:DI 61)
(const_int 5 [0x5])) t.c:23 -1
 (nil))

(insn 7 6 8 (set (reg:DI 62)
(vec_select:DI (reg:V2DI 60)
(parallel [
(const_int 0 [0])
]))) t.c:23 -1
 (nil))

(insn 8 7 9 (set (reg:V2DI 60)
(vec_concat:V2DI (reg:DI 62)
(reg:DI 61))) t.c:23 -1
 (nil))

(insn 9 8 0 (set (mem:V16QI (reg/v/f:DI 59 [ p ]) [0 *p_1(D)+0 S16 A8])
(unspec:V16QI [
(subreg:V16QI (reg:V2DI 60) 0)
] UNSPEC_MOVU)) t.c:23 -1
 (nil))

which of course does not work as ref:V2DI 60 is unsed uninitialized in insn 7.

[Bug libfortran/52434] New: Insufficient number of digits in floating point formatting

[jb at gcc dot gnu.org]

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

 Bug #: 52434
   Summary: Insufficient number of digits in floating point
formatting
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


Currently when formatting floating point numbers (that is, edit descriptors F,
E, EN, ES, G) we first convert the internal value to decimal using snprintf
with a fixed amount of digits, currently 41/24 significant digits depending on
whether quad precision is available. Apart from this being a performance
problem (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199#c13 ), in some
cases more digits can be useful. E.g. dyadic fractions can be exactly
represented:

! See 
!  
http://www.exploringbinary.com/print-precision-of-dyadic-fractions-varies-by-language/
 
program dyadic
  implicit none
  real(8) :: d
  d = 0.000542101086242752217003726400434970855712890625_8* &
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.000542101086242752217003726400434970855712890625_8*&
0.00088817841970012523233890533447265625_8
  print '(F0.1074)', d

  d = 0.99988897769753748434595763683319091796875_8
  print '(F0.53)', d
end program dyadic

Currently this program outputs

.0004940656458412465441765687928682213723650600
.99988897769753748434595763683

The exact output is:

0.000494065645841246544176568792868221372365059802614324764425585682500675507270208751865299836361635992379796564695445717730926656710355939796398774796010781878126300713190311404527845817167848982103688718636056998730723050006387409153564984387312473397273169615140031715385398074126238565591171026658556686768187039560310624931945271591492455329305456544401127480129705419319894090804165633245247571478690147267801593552386115501348035264934720193790268107107491703332226844753335720832431936092382893458368060106011506169809753078342277318329247904982524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993664809941164205702637090279242767544565229087538682506419718265533447265625
0.99988897769753748434595763683319091796875

The solution is to both this problem and the performance issue in PR 38199#c13
is to figure out the correct number of digits needed before calling snprintf.

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[evrinoma at gmail dot com]

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

--- Comment #9 from evrinoma at gmail dot com 2012-02-29 13:33:36 UTC ---
okey

i tried build astrisk on OpenSuse 12.1
with gcc

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.6/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.6
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.6.2 (SUSE Linux) 

The program successful build and program successful start without any errors

[Bug libfortran/52434] Insufficient number of digits in floating point formatting

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #1 from Janne Blomqvist  2012-02-29 13:34:27 
UTC ---
I'm working on a patch, so this is mostly a placeholder PR..

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[evrinoma at gmail dot com]

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

--- Comment #10 from evrinoma at gmail dot com 2012-02-29 13:37:09 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > gdb) disassemble 0x0053e800,+32
> > Dump of assembler code from 0x53e800 to 0x53e820:
> >0x0053e800 :movdqu -0x40(%rcx),%xmm0
> >0x0053e805 :prefetcht0 0x190(%rcx)
> >0x0053e80c :mov%rcx,%r10
> > => 0x0053e80f :prefetchw 0x1d0(%rdi)
> >0x0053e816 :add$0x4,%esi
> >0x0053e819 :movaps %xmm0,(%rdi)
> >0x0053e81c :movdqu -0x30(%rcx),%xmm0
> > End of assembler dump.
> > (gdb)
> 
> prefetchw is an AMD 3dnow! instruction, I'm not surprised it SIGILLs on your
> Intel Netburst/P4 based machine.
> 
> Please ensure you're not using any compilation flags that imply the presence 
> of
> an AMD processor.

i saw this
I begin tracing asterisk code

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #41 from Gabriel Dos Reis  2012-02-29 
13:36:59 UTC ---
(In reply to comment #40)
> I haven't seen it mentioned in the discussion here, but in C++11, the
> definition of is_modulo was clarified as:
> 
> "True if the type is modulo. A type is modulo if, for any operation involving
> +, -, or * on values of that type whose result would fall outside the range
> [min(),max()], the value returned differs from the true value by an integer
> multiple of max() - min() + 1."
> 
> Do people have objections to switching numeric_limits::is_modulo to
> false (setting it to true when -fwrapv is used can still be discussed
> afterwards)?


I agree with this.  Thanks, Marc.

[Bug c++/52432] [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-02-29 
13:41:24 UTC ---
It's a bit more tricky, because if we only do that we have a diagnostic quality
regression for decltyp32.C: many error messages are recursively produces
instead of one. The fact is, unqualified_name_lookup_error doesn't just emit
errors, also includes a mechanism preventing such long chains of errors.

[Bug target/52419] Wrong expansion of misaligned vector store

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-02-29 
13:46:01 UTC ---
We are not prepared to handle bitsize != GET_MODE_BITSIZE in expand_assignment
for the movmisalign case.  The following fixes it

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 184656)
+++ gcc/expr.c  (working copy)
@@ -4687,7 +4687,13 @@ expand_assignment (tree to, tree from, b
  != CODE_FOR_nothing))
{
  misalignp = true;
- to_rtx = gen_reg_rtx (mode);
+ /* If we only partly store to the misaligned memory region
+perform a read-modify-write cycle.  Otherwise use a scratch
+register for the 'read' part.  */
+ if (bitsize != GET_MODE_BITSIZE (mode))
+   to_rtx = expand_normal (tem);
+ else
+   to_rtx = gen_reg_rtx (mode);
}
   else
{

of course we then generate

foo:
.LFB0:
.cfi_startproc
movdqu  (%rdi), %xmm0
movhps  .LC0(%rip), %xmm0
movdqu  %xmm0, (%rdi)
ret

which is rather sub-optimal.  Not sure who would be supposed to fix that.
OTOH we could as well simply avoid going the movmisalign paths when
the word is not accessed in full.  But that's harder because we'd somehow
have to circumvent the expand_normal case to fall into the movmisalign
trap.

[Bug c++/52432] [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-02-29 
13:51:03 UTC ---
Admittedly, though, the error which we currently produce for decltype32 isn't
optimal, ie:

decltype32.C: In substitution of ‘template decltype (make_array(il))
make_array(const T&) [with T = int]’:
decltype32.C:11:23:   required from here
decltype32.C:5:6: error: ‘make_array’ was not declared in this scope
decltype32.C:5:6: note: suggested alternative:
decltype32.C:5:6: note:   ‘make_array’
decltype32.C: In function ‘int main()’:
decltype32.C:11:23: error: no matching function for call to ‘make_array(int)’
decltype32.C:11:23: note: candidate is:
decltype32.C:5:6: note: template decltype (make_array(il))
make_array(const T&)
decltype32.C:5:6: note:   substitution of deduced template arguments resulted
in errors seen above

Granted, we don't recurse, but saying that 'make_array' was not declared and
then suggesting 'make_array', ehm ;)

[Bug target/52419] Wrong expansion of misaligned vector store

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-02-29 
13:52:05 UTC ---
Failed to match this instruction:
(set (reg:DI 62)
(vec_select:DI (subreg:V2DI (unspec:V16QI [
(mem:V16QI (reg/v/f:DI 59 [ p ]) [0 *p_1(D)+0 S16 A8])
] UNSPEC_MOVU) 0)
(parallel [
(const_int 0 [0])
])))

could at least be recognized.

[Bug target/52435] New: ICE in arm_select_dominance_cc_mode, at config/arm/arm.c:10625

[doko at gcc dot gnu.org]

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

 Bug #: 52435
   Summary: ICE in arm_select_dominance_cc_mode, at
config/arm/arm.c:10625
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


Created attachment 26784
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26784
test case

seen with 4.5 and 4.6 with -O1. Other optimization levels don't show the ICE.

$ gfortran -c -O1 -fpermissive -Wfatal-errors -w fbasics_gss-min.f
fbasics_gss-min.f: In function 'deval':
fbasics_gss-min.f:39:0: internal compiler error: in
arm_select_dominance_cc_mode, at config/arm/arm.c:11474
Please submit a full bug report,
with preprocessed source if appropriate.

trunk 20120107 has a different ICE:
$ /usr/lib/gcc-snapshot/bin/gfortran -c -O1 -fpermissive -Wfatal-errors -w
fbasics_gss-min.f
fbasics_gss-min.f:139:0: internal compiler error: vector VEC(tree,base) index
domain error, in ipa_get_indirect_edge_target at ipa-cp.c:1115
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/52432] [C++11] -fdump-tree-gimple causes ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-02-29 
14:13:44 UTC ---
Grunt, the mechanism part of unqualified_name_lookup_error isn't actually used
for decltype32.C: something else is happening which manages to avoid the
recursion in the error_messages when unqualified_name_lookup_error is called
unconditionally. Looking into it.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-29
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-02-29 
14:20:16 UTC ---
Mine.

[Bug middle-end/52436] New: BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[rguenth at gcc dot gnu.org]

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

 Bug #: 52436
   Summary: BIT_FIELD_REF > should be canonicalized for
non-bitfield accesses
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


typedef long long __m128i __attribute__ ((__vector_size__ (16),
  __may_alias__));
typedef struct
{
  __m128i b;
} s_1a;
typedef s_1a s_1m __attribute__((aligned(1)));
void
foo (s_1m *p)
{
  p->b[1] = 5;
}

Produces in .optimized

foo (struct s_1m * p)
{
:
  BIT_FIELD_REF b, 64, 64> = 5;
  return;

}

we should have canoncialized (aka fold_stmt'ed) the LHS to

  MEM <(__m128i *)p_1(D), 8> = 5;

[Bug target/52419] Wrong expansion of misaligned vector store

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-29 
14:19:44 UTC ---
Created attachment 26785
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26785
alternative

This patch avoids expand_expr on the MEM_REF's base twice, by moving the mem
var computation earlier.

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  2012-02-29 
14:33:02 UTC ---
(In reply to comment #0)
> 
> +  /// @post @p __x is singular and unattached
> +  _Safe_iterator(_Safe_iterator&& __x)
> +  {
> +   // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +   // DR 408. Is vector > forbidden?
> +   _GLIBCXX_DEBUG_VERIFY(!__x._M_singular()
> + || __x._M_current == _Iterator(),
> + _M_message(__msg_init_copy_singular)
> + ._M_iterator(*this, "this")
> + ._M_iterator(__x, "other"));
> +swap(*this, __x);

Doh, that will recursively call the move constructor.

We could do:

  /// @post @p __x is singular and unattached
  _Safe_iterator(_Safe_iterator&& __x)
  {
*this = __x;
_Safe_iterator __singular;
__x = __singular;
  }

but it would be more efficient to implement a swap() member and use that for
both move construction and move-assignment

[Bug c++/52427] [C++11] problem with defaulted copy constructor and -O

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
Summary|problem with defaulted copy |[C++11] problem with
   |constructor and -O  |defaulted copy constructor
   ||and -O
 Ever Confirmed|0   |1
  Known to fail||4.5.2, 4.6.2, 4.7.0

--- Comment #1 from Jonathan Wakely  2012-02-29 
14:38:47 UTC ---
It gets the wrong value on the 17th iteration, when check_advance() is called,
so you can make it fail sooner by change s/16/3/ in hex_iterator::operator++
and the initializer for pre_foo

[Bug middle-end/52419] Wrong expansion of misaligned vector store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|target  |middle-end
   Target Milestone|--- |4.7.0

[Bug middle-end/52419] Wrong expansion of misaligned vector store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #26785|0   |1
is obsolete||
 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Jakub Jelinek  2012-02-29 
14:53:58 UTC ---
Created attachment 26786
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26786
gcc47-pr52419.patch

Updated patch.

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka  2012-02-29 15:01:31 
UTC ---
> The question is why we call delete_unreachable_blocks from
> tree_function_versioning at all.  We do not bother updating the
> callgraph anywhere else.
> 
> Honza, you added that beast?

Well, after clonning we alter CFG and we need to update SSA for which we need
to update dominators and those needs unreachable blocks gone.  I will look into
this.

Honza

[Bug c/46596] misbehavior when mixing always_inline and alias attributes in the same compilation unit

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  2012-02-29 15:07:18 UTC 
---
> glibc runs into the "sorry, unimplemented" part of the issue, with
> delta-reduced code like:
> 
> $ cat test.i
> typedef __builtin_va_list __gnuc_va_list;
> extern __inline __attribute__ ((__always_inline__)) __attribute__
> ((__artificial__)) void syslog (int __pri, const char *__fmt, ...) {
> };
> typedef __gnuc_va_list va_list;
> void __syslog(int pri, const char *fmt, ...) {
> }
> extern __typeof (__syslog) syslog __attribute__ ((alias ("__syslog")));

The problem here seems to be that typeof copies always inline attribute.
GCC before version 4.7 do not see through aliases and thus it has always
inline function that is alias but it can not see the body.  So the message
is correct.

GCC 4.7 newly understands alaises, but this was major change of the internal
representation and can not be backported.  For older GCC, i think only
workaround
is to call __syslog instead of syslog or drop the idea of using always iline
here.  Extern inlines will be inlined anyway.

Honza

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |

--- Comment #14 from Jan Hubicka  2012-02-29 
15:15:46 UTC ---
mine.

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther  2012-02-29 
15:17:33 UTC ---
(In reply to comment #13)
> > The question is why we call delete_unreachable_blocks from
> > tree_function_versioning at all.  We do not bother updating the
> > callgraph anywhere else.
> > 
> > Honza, you added that beast?
> 
> Well, after clonning we alter CFG and we need to update SSA for which we need
> to update dominators and those needs unreachable blocks gone.  I will look 
> into
> this.

Ok - but why bother updating the callgraph?

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[hubicka at ucw dot cz]

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

--- Comment #16 from Jan Hubicka  2012-02-29 15:24:18 
UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737
> 
> --- Comment #15 from Richard Guenther  2012-02-29 
> 15:17:33 UTC ---
> (In reply to comment #13)
> > > The question is why we call delete_unreachable_blocks from
> > > tree_function_versioning at all.  We do not bother updating the
> > > callgraph anywhere else.
> > > 
> > > Honza, you added that beast?
> > 
> > Well, after clonning we alter CFG and we need to update SSA for which we 
> > need
> > to update dominators and those needs unreachable blocks gone.  I will look 
> > into
> > this.
> 
> Ok - but why bother updating the callgraph?

Because the edges still hold important information about inlining and
redirecting, so we can not rebuild callgraph because the info would be lost.
Ignoring the update would result in ill formed callgraph with missing/stale
edges that is probably way to hell, too. So I opted to write code to keep it up
to date.

This is all part of the materialization clones: we do have virtual clones of
single function, each with different parameters and different redirection of
it. With materialization we need to build the bodies in one step, update the
call according to edge redirection in following step and finally inline before
doing the local optimization. Callgrpah needs to stay intact over the whole
process. (and as we discussed, we may want to make it intact even longer ;)

Honza

[Bug tree-optimization/52430] [4.4 Regression] firefox miscompilation

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-29
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Martin Jambor  2012-02-29 
15:26:30 UTC ---
Mine, the problem is that ipcp_need_redirect_p does not redirect back
the problematic call because n_cloning_candidates == 0.  That seems
bogus, I'm investigating why it happens.

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-29
 Ever Confirmed|0   |1

--- Comment #4 from Paolo Carlini  2012-02-29 
15:35:05 UTC ---
Thanks for handling this. Yesterday was looking into the debug-mode bits of the
vector swap issue and noticed something quite weird going on ;)

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Mikael Pettersson  2012-02-29 
15:36:42 UTC ---
The ICE first appeared in r164552, Bernd Schmidt's first PR44373 aka head
merging patch, then disappeared when r164552 was reverted, then reappeared in
r167779 when the updated PR44374 patch was committed.  Adding Bernd to CC list.

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |

[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3

[w6ws at earthlink dot net]

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

--- Comment #6 from Walter Spector  2012-02-29 
15:58:10 UTC ---
Tobias,

If you are interested, I tried the patch you posted on the email list to a
freshly checked out trunk.  After building the compiler, I tried the following
small test case:

module mpi_interface
  implicit none

  interface mpi_send
subroutine MPI_Send (buf, count, datatype, dest, tag, comm, ierr)
  type(*), intent(in) :: buf(:)
  integer, intent(in) :: count
  integer, intent(in) :: datatype
  integer, intent(in) :: dest
  integer, intent(in) :: tag
  integer, intent(in) :: comm
  integer, intent(out):: ierr
end subroutine
  end interface

end module

The compiler gave the following error:

mpi_interface.F90:16.10:

end module
  1
Internal Error at (1):
gfc_code2string(): Bad code

If I change the 'buf(:)' to 'buf(*)' I get the same error.

Hope this helps,

Walter

[Bug c/46596] misbehavior when mixing always_inline and alias attributes in the same compilation unit

[vapier at gentoo dot org]

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

Mike Frysinger  changed:

   What|Removed |Added

 CC||toolchain at gentoo dot org
   See Also||http://sourceware.org/bugzi
   ||lla/show_bug.cgi?id=10375

--- Comment #6 from Mike Frysinger  2012-02-29 
16:13:44 UTC ---
(In reply to comment #4)

yes, the source of this bug was the glibc code which i reduced even further
into the testcase posted originally

(In reply to comment #5)

if gcc-4.7 works fine with the proposed code, then i'm fine with that.  we
already have workarounds in place for those.

[Bug c/52437] New: internal compiler error: in spill_failure, at reload1.c:2120

[regehr at cs dot utah.edu]

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

 Bug #: 52437
   Summary: internal compiler error: in spill_failure, at
reload1.c:2120
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@gamow 0]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r184628-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r184628-install
--program-prefix=r184628- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20120228 (experimental) (GCC) 

[regehr@gamow 0]$ current-gcc small.c -c -O3

small.c: In function 'fn1':
small.c:13:1: error: unable to find a register to spill in class 'FLOAT_REGS'
small.c:13:1: error: this is the insn:
(insn 10 33 12 2 (set (reg:V4SI 76 [ vect_var_.17 ])
(vec_merge:V4SI (vec_duplicate:V4SI (const_int 1 [0x1]))
(reg:V4SI 76 [ vect_var_.17 ])
(const_int 1 [0x1]))) small.c:10 1393 {vec_setv4si_0}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 1 [0x1])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)))
small.c:13:1: internal compiler error: in spill_failure, at reload1.c:2120
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[regehr@gamow 0]$ cat small.c
int **f, g, i, j;

void fn1 () {
  for (;;) {
j = (fn2 (), 0) | 1;
i = 0;
for (; i <= 3; i += 1) {
  g = 1;
  for (; g >= 0; g -= 1)
0 == (f = 0) & (j &= 0xB);
}
  }
}

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-02-29 
16:37:43 UTC ---
The problem exists in all active branches and isn't a regression, so I'll
implement a swap asap but it isn't urgent for 4.7.0

[Bug tree-optimization/52430] [4.4 Regression] firefox miscompilation

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2012-02-29 
16:45:04 UTC ---
Created attachment 26787
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26787
Proposed untested fix

n_cloning_candidates is zero because ipcp_initialize_node_lattices
thinks that growStorageBy does not need to be preserved because it
only checks node->needed, which is false.  In 4.5, we use
cgraph_only_called_directly_p for this purpose which also tests
node->local.externally_visible, which is what the attached patch,
currently under bootstrap and testing, does too.

With the patch at and -Os, we do not clone calculateNewCapacity and
the problem therefore does not occur.

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-02-29 
17:01:44 UTC ---
Sure, sure, likewise for vector swap ;)

[Bug target/52268] tls support should be added for darwin11

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2012-02-29 
17:18:19 UTC ---
Also in clang 3.0, I see test/CodeGen/darwin-thread-specifier.c which
contains...

// RUN: %clang_cc1 -triple x86_64-apple-macosx10.7.0 -emit-llvm -o - %s |
FileCheck %s
// CHECK: @b = thread_local global i32 5, align 4
__thread int b = 5;

whereas their test/CodeGen/thread-specifier.c has...

// RUN: %clang_cc1 -triple i686-pc-linux-gnu -emit-llvm -o - %s | FileCheck %s

// CHECK: @b = external thread_local global
// CHECK: @d.e = internal thread_local global
// CHECK: @d.f = internal thread_local global
// CHECK: @a = thread_local global
__thread int a;
extern __thread int b;
int c() { return *&b; }
int d() {
  __thread static int e;
  __thread static union {float a; int b;} f = {.b = 1};
  return 0;
}

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-29 
17:44:01 UTC ---
Author: jakub
Date: Wed Feb 29 17:43:56 2012
New Revision: 184665

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184665
Log:
PR tree-optimization/52429
* tree-parloops.c (separate_decls_in_region_debug): Return early
if var is LABEL_DECL.

* gcc.dg/torture/pr52429.c: New test.
* g++.dg/opt/pr52429.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr52429.C
trunk/gcc/testsuite/gcc.dg/torture/pr52429.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug middle-end/52419] Wrong expansion of misaligned vector store

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-02-29 
17:46:08 UTC ---
Author: jakub
Date: Wed Feb 29 17:45:55 2012
New Revision: 184666

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184666
Log:
PR middle-end/52419
* expr.c (expand_assignment): If doing misaligned store that doesn't
cover all mode bits, perform a RMW cycle.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr52419.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52429] [4.7 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:914 with -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-02-29 
17:52:18 UTC ---
Fixed.

[Bug middle-end/52419] Wrong expansion of misaligned vector store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  2012-02-29 
17:52:41 UTC ---
Fixed.

[Bug target/52407] [4.6 Regression] sse2 simd uint32_t and int64_t and stack variable initialization

[pcpa at mandriva dot com.br]

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

Paulo César Pereira de Andrade  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Paulo César Pereira de Andrade  2012-02-29 17:54:34 UTC ---
(In reply to comment #7)
> Fixed on trunk.  I'll backport it for 4.6.4 as it is latent on the branches.

Thanks. I reported the problem because I thought it could
hit somewhere else and I have some code that way, that was
working since gcc 4.4, but the proper syntax to initialize
the local variable should be, in the sample test case:
vl_t w = {x,x};
what should make it easier for the compiler to understand
what is being done.

[Bug other/52438] New: Some files still GPLv2

[steven at gcc dot gnu.org]

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

 Bug #: 52438
   Summary: Some files still GPLv2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


This is for trunk at r184666.

Probably should be removed (?):
* gcc/COPYING

* Only referenced in sourcebuild.texi:
gcc/doc/include/gpl.texi

FSF not (only) copyright holder (so can't change license?):
* gcc/ada/s-osinte-kfreebsd-gnu.ads
* gcc/ada/s-osinte-rtems.adb
* gcc/ada/s-taspri-lynxos.ads
* gcc/ada/s-tpopsp-rtems.adb

No good reason to be GPLv2:
* gcc/config/mn10300/mn10300-modes.def
* gcc/config/v850/v850-modes.def

[Bug fortran/52439] New: Calculation of natural log

[dtovson at hotmail dot com]

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

 Bug #: 52439
   Summary: Calculation of natural log
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dtov...@hotmail.com


Created attachment 26788
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26788
simple fortran calculation of the natural logs mentioned in the description.
Among other files in the zip file, I included a batch file, executable and
output files.

using gfortran (4.7.0):
calculation of DLOG(0.01)  = -4.60517020833983359295871196081862
calculation of DLOG(100.0) =  4.60517018598809180218722758581862

Numbers should match except for the sign, the value for DLOG(0.01) also appears
outside a tolerance I expect to find.

using another a calculation routine with another compiler
calculation of DLOG(0.01)  = -4.605170185988091368035982909369
calculation of DLOG(100.0) =  4.605170185988091368035982909369

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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

--- Comment #17 from Mikael Pettersson  2012-02-29 
19:13:12 UTC ---
(In reply to comment #16)
> Created attachment 26757 [details]
> make fold_rtx handle prev_insn_cc0 == NULL
> 
> The effect of Richard Guenther's r180192 patch to tree-eh.c is that "g >= 0.0"
> (or its gimple equivalent) is recognized as potentially trapping, which causes
> the cc0 setter and user to be put in separate BBs.  That's usually a no-no, 
> but
> in the case of EH I'm not sure it can be avoided.  Then as fold_rtx processes
> the cc0 user at the start of the second BB, prev_insn_cc0 is NULL causing
> equiv_constant to crash.
> 
> With the attached patch fold_rtx simply doesn't try to fold the current rtx
> when prev_insn_cc0 is NULL.  A build of 4.7-20120225 as a cross to m68k-linux
> with java enabled succeeded with this patch applied, and it handled Andreas'
> c++ test case too.  I'm currently attempting a native bootstrap with both java
> and ada enabled.

The native bootstrap succeeded.

[Bug ada/51483] [4.7 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson  2012-02-29 
19:18:37 UTC ---
(In reply to comment #9)
> applying my tentative
> patch did allow a successful build of a gcc-4.7 cross to m68k w/ ada, so I'll
> try a native bootstrap with it soonish.

Native bootstrap of 4.7-20120225 plus my proposed fix for this PR, the base
m68k-linux Ada support patch from PR48835, and the proposed fix for the cc0 bug
in PR49847, with Ada enabled, did succeed.

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2012-02-29 
19:43:38 UTC ---
Created attachment 26789
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26789
reduced test case

[Bug fortran/52439] Calculation of natural log

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-02-29
 CC||kargl at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org 2012-02-29 19:51:59 UTC ---
What happens if you use double precision literal constants?
Is 0.01 exactly representable in a binary floating point 
format.

[Bug target/52437] [4.7 Regression] internal compiler error: in spill_failure, at reload1.c:2120

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-29
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
Summary|internal compiler error: in |[4.7 Regression] internal
   |spill_failure, at   |compiler error: in
   |reload1.c:2120  |spill_failure, at
   ||reload1.c:2120
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-02-29 
19:53:20 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178728
Looks like a bug in the vec_set_0 pattern, it isn't prepared to handle
integer immediates that can match general_operand.

[Bug fortran/52439] Calculation of natural log

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-02-29 
20:02:04 UTC ---
100 is exactly representable in float but 0.001 is not.

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from William J. Schmidt  2012-02-29 
20:26:33 UTC ---
Author: wschmidt
Date: Wed Feb 29 20:26:29 2012
New Revision: 184670

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184670
Log:
2012-02-29  Bill Schmidt  

PR tree-optimization/52424
* tree-ssa-dom.c (dom_opt_leave_block): Push a marker before
calling dom_thread_across_edge.


Modified:
branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_5-branch/gcc/tree-ssa-dom.c

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from William J. Schmidt  2012-02-29 
20:27:45 UTC ---
Author: wschmidt
Date: Wed Feb 29 20:27:41 2012
New Revision: 184671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184671
Log:
2012-02-29  Bill Schmidt  

PR tree-optimization/52424
* tree-ssa-dom.c (dom_opt_leave_block): Push a marker before
calling dom_thread_across_edge.


Modified:
branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_6-branch/gcc/tree-ssa-dom.c

[Bug c++/52440] New: [C++11] Wrong template argument deduction/substitution failures

[ai.azuma at gmail dot com]

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

 Bug #: 52440
   Summary: [C++11] Wrong template argument deduction/substitution
failures
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com


Created attachment 26790
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26790
Output of -v option and preprocessed file

I can't find anything to prevent the following code from compiling;

/
template
struct V
{
  typedef void type;
};

template
struct X
{
  template
  static constexpr bool always_true()
  {
return true;
  };

  template()>::type>
  X(U &&) {}// Line 18
};

int main()
{
  X x(42); // Line 23
}
/

However, GCC complains about deduction/substitution failure;

main.cpp: In function 'int main()':
main.cpp:23:14: error: no matching function for call to 'X::X(int)'
main.cpp:23:14: note: candidates are:
main.cpp:18:3: note: template X::X(U&&)
main.cpp:18:3: note:   template argument deduction/substitution failed:
main.cpp:8:8: note: constexpr X::X(const X&)
main.cpp:8:8: note:   no known conversion for argument 1 from 'int' to 'const
X&'
main.cpp:8:8: note: constexpr X::X(X&&)
main.cpp:8:8: note:   no known conversion for argument 1 from 'int' to
'X&&'

The constructor template in line 18 should always succeed in template argument
deduction/substitution and be used for the invocation in Line 23.

My guess is that this is a bug of GCC.

[Bug target/52437] [4.7 Regression] internal compiler error: in spill_failure, at reload1.c:2120

[ubizjak at gmail dot com]

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

--- Comment #2 from Uros Bizjak  2012-02-29 20:32:06 
UTC ---
This patch adds missing alternative, and also disparages alternatives that end
with excess register->mem moves.

Index: sse.md
===
--- sse.md  (revision 184630)
+++ sse.md  (working copy)
@@ -3895,13 +3895,13 @@
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "vec_set_0"
   [(set (match_operand:VI4F_128 0 "nonimmediate_operand"
- "=x,x,x ,x,x,x,x  ,x  ,m,m ,m")
+ "=x,x,x ,x,x,x,x  ,x  ,m ,m   ,m")
(vec_merge:VI4F_128
  (vec_duplicate:VI4F_128
(match_operand: 2 "general_operand"
- " x,m,*r,m,x,x,*rm,*rm,x,fF,*r"))
+ " x,m,*r,m,x,x,*rm,*rm,!x,!*rn,!*fF"))
  (match_operand:VI4F_128 1 "vector_move_operand"
- " C,C,C ,C,0,x,0  ,x  ,0,0 ,0")
+ " C,C,C ,C,0,x,0  ,x  ,0 ,0   ,0")
  (const_int 1)))]
   "TARGET_SSE"
   "@

[Bug target/52437] [4.7 Regression] internal compiler error: in spill_failure, at reload1.c:2120

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-02-29 
20:37:49 UTC ---
I've tried:

@@ -3899,7 +3899,7 @@
 (vec_merge:VI4F_128
   (vec_duplicate:VI4F_128
 (match_operand: 2 "general_operand"
-  " x,m,*r,m,x,x,*rm,*rm,x,fF,*r"))
+  " x,m,*r,m,x,x,*rm,*rm,x,fF,*re"))
   (match_operand:VI4F_128 1 "vector_move_operand"
   " C,C,C ,C,0,x,0  ,x  ,0,0 ,0")
   (const_int 1)))]

and that worked too.  If you want to swap the m/fF/0 alternative with m/*r/0
alternative (extended with additional e or n, which one is right?), then
you should also swap
(eq_attr "alternative" "9")
  (const_string "fmov")
(eq_attr "alternative" "10")
  (const_string "imov")

[Bug target/52437] [4.7 Regression] internal compiler error: in spill_failure, at reload1.c:2120

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-02-29 
20:41:48 UTC ---
movsi uses re constraint, not rn, so I'd think we should use re.

[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2012-02-29 
20:47:34 UTC ---
I think this is related to PR 45685.

[Bug target/52437] [4.7 Regression] internal compiler error: in spill_failure, at reload1.c:2120

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2012-02-29 21:00:26 
UTC ---
(In reply to comment #4)
> movsi uses re constraint, not rn, so I'd think we should use re.

re also includes symbols and labels and whatnot (please see
x86_64_immediate_operand predicate). We are interested only in plain 32bit
immediates here that will produce mov $1, (%rsp).

Please also add ! decoration to the last three alternatives, to avoid

mov $1, %eax
mov %eax, (%rsp)
...

The patch is pre-approved with these changes.

[Bug fortran/52387] I/O output of write after nonadvancing read

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-02-29 
21:12:46 UTC ---
It gets even messier with STREAM I/O. For a compiler comparison w/o further
comments, see
https://groups.google.com/d/msg/comp.lang.fortran/aUBQsYBto2c/d_noVS80FV4J (and
for an older version, see also J3 thread).