[Bug testsuite/53028] add dg-pedantic

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-04-19 
07:03:30 UTC ---
grep -F "pedantic-errors" testsuite/gcc.dg/*.c

Most of those testcases are duplicated or triplicated.

Another alternative could be if -pedantic warnings always were associated to an
option, then dg-warning tried to match that option. That would avoid having to
add three testcases.

[Bug target/53038] New: cfi_restore for cr before cr is actually restored

[amodra at gmail dot com]

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

 Bug #: 53038
   Summary: cfi_restore for cr before cr is actually restored
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


void s_c (void)
{
  char a[33];
  __asm __volatile ("#%0" : "=m" (a) : : "cr2");
}

compiled with -m32 -O2 -g gives this epilogue

lwz 12,76(1)
addi 1,1,80
.cfi_restore 70
.cfi_def_cfa_offset 0
mtcrf 32,12
blr

[Bug target/53038] cfi_restore for cr before cr is actually restored

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Target||powerpc-linux
  Known to fail||4.5.5, 4.6.4, 4.7.1, 4.8.0

--- Comment #1 from Alan Modra  2012-04-19 07:32:30 
UTC ---
Earlier compilers without shrink-wrap on by default need
-fasynchronous-unwind-tables to get the epilogue cfi_restores.

[Bug fortran/53035] Internal Compiler Error

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-04-19 
07:35:31 UTC ---
(In reply to comment #0)
> I have attached a compressed archive that should allow you to reproduce an
> Internal Compiler Error.

I assume you forgot to attach the file - at least no file is attached.


> automake
> autoconf
> ./configure
> make

That looks like a rather large program. Thus some remarks.

First, comments and attached files to bug reports are publicly visible "for
ever"; thus, ensure that the license of the program permits the attachment.

Secondly, most of the time, programs can be reduces to a few lines of code.
That not only avoids license issues but is usually a prerequisite to be able to
find the compiler bug. Thus, we are always happy if bug reporters reduce the
test case themselves. (For the Fortran front ends - as a special service - we
might also do it ourselves - developers of other parts of GCC don't.)

Thirdly, the server admins are happy if the Bugzilla database doesn't contain
too many big attachments. (Thus, you could consider hosting the tar file
elsewhere.)


To reduce the test case, you could try Delta as described at
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction  It would be also
interesting to know whether it only fails with certain flags (like "-O3") or
always.


In any case, without a test case, it is very difficult to solve bugs ...

* * *

Regrading the ICE:

  f951: internal compiler error: in lhd_set_decl_assembler_name, at
  langhooks.c:158

the failing ASSERT is:

  /* The language-independent code should never use the
 DECL_ASSEMBLER_NAME for lots of DECLs.  Only FUNCTION_DECLs and
 VAR_DECLs for variables with static storage duration need a real
 DECL_ASSEMBLER_NAME.  */
  gcc_assert (TREE_CODE (decl) == FUNCTION_DECL
  || (TREE_CODE (decl) == VAR_DECL
  && (TREE_STATIC (decl)
  || DECL_EXTERNAL (decl)
  || TREE_PUBLIC (decl;

[Bug c++/53039] New: [C++11]including breaks std::is_convertible with template-pack expansion

[mitchnull+gcc at gmail dot com]

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

 Bug #: 53039
   Summary: [C++11]including  breaks
std::is_convertible with template-pack expansion
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mitchnull+...@gmail.com


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

#include  in the following code causes compile failure. Without the
include, it compiles fine:

#include 
#include  // without this include, it compiles

template 
struct Bools {
static const bool value = true;
};

template 
struct Types {
template ::value...>::value,
 bool>::type = false>
int foo(Us&&...) {
return sizeof...(Us);
}
};

int main() {
Types t;
return t.foo(1, 1);
}


Output:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper 
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120324/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.8.0 20120407 (experimental) [trunk revision 186212] (Debian
20120407-1)

$ /usr/lib/gcc-snapshot/bin/g++ -std=c++11 functional_bug.cpp
functional_bug.cpp: In instantiation of 'struct Types':
functional_bug.cpp:21:21:   required from here
functional_bug.cpp:15:9: error: wrong number of template arguments (3, should
be 2)
In file included from functional_bug.cpp:1:0:
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.8.0/../../../../include/c++/4.8.0/type_traits:1264:12:
error: provided for 'template struct
std::is_convertible'
functional_bug.cpp: In function 'int main()':
functional_bug.cpp:22:14: error: 'struct Types' has no member named
'foo'

[Bug c++/53039] [C++11]including breaks std::is_convertible with template-pack expansion

[mitchnull+gcc at gmail dot com]

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

--- Comment #1 from Radics Péter  2012-04-19 
07:59:06 UTC ---
Created attachment 27186
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27186
4.8.0 output

test run by sam of #c++ on freenode

[Bug c++/53039] [C++11]including breaks std::is_convertible with template-pack expansion

[mitchnull+gcc at gmail dot com]

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

--- Comment #2 from Radics Péter  2012-04-19 
08:00:00 UTC ---
Created attachment 27187
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27187
4.7.0 output

test run on arch linux

[Bug debug/45088] pointer type information lost in debuginfo

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||pluto at agmk dot net

--- Comment #10 from Pawel Sikora  2012-04-19 08:07:28 
UTC ---
what about 4.7 branch?

[Bug libgcj/52579] [4.8 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function

[jojelino at gmail dot com]

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

--- Comment #1 from gee  2012-04-19 08:23:39 UTC ---
i came into conclusion that we need to separate ffi_closure_raw_THISCALL from
ffi_closure_raw_SYSV(not using such as jmp .stubraw), because
ffi_closure_raw_THISCALL is not transparent by CFI so that
_Unwind_RaiseException would not fail with _urc_end_of_stack, modifing CFI of
ffi_closure_raw_THISCALL so that thiscall closure of ffi_closure_raw_THISCALL
would not be shown by reading CFI

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2012-04-19 
08:40:53 UTC ---
> One approach is to provide masks.opt to provide those masks without
> switch.  masks.opt should be used when long-double-switch.opt isn't
> used.

How ugly.  Please do something in opth-gen.awk instead, or revert the patch.

[Bug c++/53039] [C++11]including breaks std::is_convertible with template-pack expansion

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-19
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-04-19 
08:41:54 UTC ---
Very strange. Confirmed.

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2012-04-19 
08:51:57 UTC ---
Author: rguenth
Date: Thu Apr 19 08:51:50 2012
New Revision: 186585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186585
Log:
2012-04-19  Richard Guenther  

PR rtl-optimization/44688
* loop-iv.c (determine_max_iter): Only return max_iter.
(iv_number_of_iterations): Also use the recorded loop bound
on the maximum number of iterations.
* loop-unroll.c (decide_unroll_runtime_iterations): Use
max_iter to avoid unrolling loops that do not roll.
(decide_unroll_stupid): Likewise.

* gcc.dg/var-expand1.c: Increase array size to make unrolling
possibly profitable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-iv.c
trunk/gcc/loop-unroll.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/var-expand1.c

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-04-19 
08:53:37 UTC ---
There are still other prologue/epilogue loops that would need similar handling
on their generation.  The vectorizer needs to be re-organized to better
separate those loop versions again.

[Bug target/52790] Problems using x86_64-w64-mingw-w32-gfortran with mcmodel=large and medium

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-19
  Component|fortran |target
 CC||jb at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Janne Blomqvist  2012-04-19 08:58:21 
UTC ---
Switching component to target, as the Fortran frontend has nothing to do with
this.

[Bug c++/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

[Bug bootstrap/53030] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug middle-end/53031] [4.8 Regression] gcc.dg/tree-ssa/vrp54.c scan-tree-dump-not vrp1 "link_error"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-19
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-19 
09:01:57 UTC ---
That's mine - I missed in testing.  Caused by

The adjust_range_with_scev hunk in

2012-04-18  Richard Guenther  

* cfgloop.h (estimate_numbers_of_iterations_loop): Remove
use_undefined_p parameter.
* tree-flow.h (estimate_numbers_of_iterations): Likewise.
* tree-ssa-loop-niter.c (estimate_numbers_of_iterations_loop):
Likewise.
(estimate_numbers_of_iterations): Likewise.
(estimated_loop_iterations): Adjust.
(max_loop_iterations): Likewise.
(scev_probably_wraps_p): Likewise.
* tree-ssa-loop.c (tree_ssa_loop_bounds): Likewise.
* tree-vrp.c (adjust_range_with_scev): Use max_stmt_executions,
not max_loop_iterations.
(execute_vrp): Remove explicit number of iterations estimation.

[Bug fortran/53035] Internal Compiler Error

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-19
 Ever Confirmed|0   |1

[Bug c/52283] "error: case label does not reduce to an integer constant" for constant folded cast expr

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from chrbr at gcc dot gnu.org 2012-04-19 09:15:46 UTC ---
Fixed at rev #186586

[Bug middle-end/52831] extract_bit_field_1: issue when str_rtx unsafe from target

[aurelien.buhrig.gcc at gmail dot com]

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

Aurelien Buhrig  changed:

   What|Removed |Added

Version|4.8.0   |4.6.3

--- Comment #2 from Aurelien Buhrig  
2012-04-19 09:18:24 UTC ---
Need more information about the bug?
Any comment about the provided patch?

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[olegendo at gcc dot gnu.org]

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

--- Comment #28 from Oleg Endo  2012-04-19 
09:29:41 UTC ---
The prophecy in comment #3 finally came true (again) while I was testing the
patch for PR 52941 ;)
The problem is that when reload tries to swap regs from/to stack, it will try
to use the QI/HI displacement addressing patterns to access the stack (which is
good).  However, if the following insn has an R0 clobber (such as the atomic
sequences) reload will bail out instead of introducing another R0 <-> Rn move
after the QI/HI load/store in order to satisfy the displacement addressing
constraints.
I'm now trying to work around this by adding special insn_and_split patterns
for the reload phase and removing the displacement addressing special cases in
sh_secondary_reload

[Bug c/37985] [4.5/4.6/4.7/4.8 Regression] unsigned char shift lacks "statement with no effect" warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Manuel López-Ibáñez  2012-04-19 
10:27:39 UTC ---
Re-fixed by 


r186586 | chrbr | 2012-04-19 11:06:53 +0200 (Thu, 19 Apr 2012) | 1 line

Fix #52283 error: case label does not reduce to an integer constant

[Bug c++/53039] [4.7/4.8 Regression] including breaks std::is_convertible with template-pack expansion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|mitchnull+gcc at gmail dot  |hjl.tools at gmail dot com
   |com |
Summary|[C++11]including|[4.7/4.8 Regression]
   | breaks |including 
   |std::is_convertible with|breaks std::is_convertible
   |template-pack expansion |with template-pack
   ||expansion

--- Comment #4 from Paolo Carlini  2012-04-19 
10:45:53 UTC ---
Looks like a regression. I wonder if isn't some sort of weird side-effect of
the fix for PR48322: we should at least compare pre and post Rev 181547. Then
do a binary search. 

HJ, can you help with the search? (mind the -std=c++11)

[Bug target/53040] New: nested functions may trash floating point registers

[amodra at gmail dot com]

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

 Bug #: 53040
   Summary: nested functions may trash floating point registers
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


compile with -m32 -Os -fno-inline
void ws_f (void)
{
  char b[10];
  void ns_f (void)
  {
char a[33];
__asm __volatile ("#%0 %1" : "=m" (a), "=m" (b) : : "fr28", "fr31");
  }
  ns_f ();
}

results in

ns_f.2345:
stwu 1,-96(1)
mflr 0
stfd 28,64(1)
stw 0,100(1)
stfd 31,88(1)
[snip]
addi 11,1,96
b _restfpr_28_x

_restfpr_28_x will restore fr29 and fr30 from uninitialised stack.

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2012-04-19 
11:29:20 UTC ---
Author: gjl
Date: Thu Apr 19 11:29:13 2012
New Revision: 186588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186588
Log:
PR target/53033
* config/avr/avr.c (avr_out_load_psi): Fix assembler template for
the case *(X+const).


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

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2012-04-19 
11:33:08 UTC ---
Author: gjl
Date: Thu Apr 19 11:33:01 2012
New Revision: 186589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186589
Log:
Backport from 2012-04-19 mainline r186588.
PR target/53033
* config/avr/avr.c (avr_out_load_psi): Fix assembler template for
the case *(X+const).


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr.c

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Georg-Johann Lay  2012-04-19 
11:40:27 UTC ---
Fixed in 4.7.1

[Bug c/53041] New: Changing of array is leading to changing of another variable

[sveark at gmail dot com]

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

 Bug #: 53041
   Summary: Changing of array is leading to changing of another
variable
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sve...@gmail.com


Created attachment 27188
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27188
The source code

GCC version is gcc (SUSE Linux) 4.6.2

[Bug c/53041] Changing of array is leading to changing of another variable

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-04-19 
12:06:13 UTC ---
This is not a proper bug report, please read http://gcc.gnu.org/bugs/

What are you claiming is a bug in GCC?

Your program is dangerous and has undefined behaviour if more than one
character is entered, that's not GCC's fault

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
http://en.wikipedia.org/wiki/Scanf_format_string#Security

[Bug c/53041] Changing of array is leading to changing of another variable

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #2 from Manuel López-Ibáñez  2012-04-19 
12:10:27 UTC ---
See: http://pubs.opengroup.org/onlinepubs/007904975/functions/scanf.html

s
Matches a sequence of bytes that are not white-space characters. The
application shall ensure that the corresponding argument is a pointer to the
initial byte of an array of char, signed char, or unsigned char large enough to
accept the sequence and a terminating null character code, which shall be added
automatically.

[Bug fortran/53015] free_pi_tree(): Unresolved fixup is back

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #4 from janus at gcc dot gnu.org 2012-04-19 12:15:16 UTC ---
(In reply to comment #3)
> If I -I and -J point to the same directory, I get the free pi_tree stuff.
> Removing the -I (as it is not needed for this purpose) solves the problem.

I have to admit that I have never used the -J option myself, but the
documentation at
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gfortran/Directory-Options.html seems
to suggest that using "-Jdir" sort of implies "-Idir" (in the sense that this
directory is searched for .mod files).

Is there a particular reason that you use both of them? The problem may indeed
be due to the two interfering (which of course would be a bug). What happens if
you use neither -I nor -J?

In any case it would be helpful to have some sort of test case (it doesn't
necessarily need to be extremely reduced, but the smaller the better, of
course).

[Bug c++/53036] [c++11] trivial class fails std::is_trivial test

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse  2012-04-19 
12:14:04 UTC ---
Created attachment 27189
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27189
basic patch

The patch detects D as trivial.

Sadly, on this case:
struct A {
  A()=default;
  A(int=2);
};
it says A is trivial whereas I guess the ambiguity makes it non-trivial. That
could be solved for the traits by combining it with is_default_constructible,
but it may be problematic to let g++ internally believe that the class is
trivially default constructible. For some strange reason, in the case of an
ellipsis:
struct A {
  A()=default;
  A(...);
};
it does say: non-trivial.

Maybe the whole dance should only be done if the constructor argument is a
parameter pack (one that belongs to the function? or several packs?).

[Bug middle-end/27193] dump-tree-original-raw does not print the linkage for a variable with file scope.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #4 from Manuel López-Ibáñez  2012-04-19 
12:20:26 UTC ---
No, you should write a plugin: http://gcc.gnu.org/wiki/plugins

[Bug c++/28525] ICE after duplicate_decls

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-19
 Ever Confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  2012-04-19 
12:22:40 UTC ---
Is this still a bug?

[Bug c++/53036] [c++11] trivial class fails std::is_trivial test

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-04-19 12:24:12 UTC ---
(In reply to comment #2)
> Sadly, on this case:
> struct A {
>   A()=default;
>   A(int=2);
> };
> it says A is trivial whereas I guess the ambiguity makes it non-trivial.

I agree. This is correct assuming

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1363

becomes accepted (There is little doubt for that, though).

[Bug c++/53036] [c++11] trivial class fails std::is_trivial test

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini  2012-04-19 
12:32:57 UTC ---
Maybe we should be sending patches to the mailing list... But let's add Jason
in CC.

[Bug translation/37457] pp_base_format, pretty-print.c:529

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-19
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  2012-04-19 
12:43:30 UTC ---
Please find the contact address here:
http://translationproject.org/team/index.html

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-19
Version|4.6.0   |4.8.0
 Ever Confirmed|0   |1

--- Comment #4 from janus at gcc dot gnu.org 2012-04-19 12:45:28 UTC ---
Here is a preliminary patch which makes gfortran accept the code in comment #2:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 186485)
+++ gcc/fortran/interface.c(working copy)
@@ -955,7 +955,9 @@ generic_correspondence (gfc_formal_arglist *f1, gf
 goto next;

   if (f2 != NULL && (compare_type_rank (f1->sym, f2->sym)
- || compare_type_rank (f2->sym, f1->sym)))
+ || compare_type_rank (f2->sym, f1->sym))
+  && !((f1->sym->attr.allocatable && f2->sym->attr.pointer)
+   || (f2->sym->attr.allocatable && f1->sym->attr.pointer)))
 goto next;

   /* Now search for a disambiguating keyword argument starting at
@@ -966,7 +968,9 @@ generic_correspondence (gfc_formal_arglist *f1, gf
 continue;

   sym = find_keyword_arg (g->sym->name, f2_save);
-  if (sym == NULL || !compare_type_rank (g->sym, sym))
+  if (sym == NULL || !compare_type_rank (g->sym, sym)
+  || (sym->attr.allocatable && g->sym->attr.pointer)
+  || (sym->attr.pointer && g->sym->attr.allocatable))
 return 1;
 }

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2012-04-19 12:53:05 UTC ---
(In reply to comment #4)
> Here is a preliminary patch which makes gfortran accept the code in comment 
> #2:

Of course we need to do more. As quoted in comment #0:

"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 has the ALLOCATABLE attribute and the other has the POINTER attribute, or
- one is a function with nonzero rank and the other is not known to be a
function."

The patch above only handles the third item, and the second item works already.
Items #1 and #4 are still missing (I think).

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2012-04-19 13:04:18 UTC ---
(In reply to comment #5)
> "Two dummy arguments are distinguishable if
> - one is a procedure and the other is a data object,

Here is a test case for this item:


module m
  interface testIF
module procedure :: test1
module procedure :: test2
  end interface
contains
  real function test1 (obj)
real :: obj
test1 = obj
  end function
  real function test2 (obj)
procedure(real) :: pr
test2 = pr(0.)
  end function
end module

program test
  use m
  print *,testIF(2.0),testIF(cos)
end program



... which is currently rejected with:


module procedure :: test2
 1
Error: Ambiguous interfaces 'test2' and 'test1' in generic interface 'testif'
at (1)

[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2012-04-19 
13:09:07 UTC ---
Experimental patch that fixes the regression:

diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 3c11c0e..9c04516 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -4112,6 +4112,7 @@ get_computation_cost_at (struct ivopts_data *data,
   else if (ratio == 1)
 {
   tree real_cbase = cbase;
+  int diff_cost, add_cost_val;

   /* Check to see if any adjustment is needed.  */
   if (cstepi == 0 && stmt_is_after_inc)
@@ -4131,7 +4132,19 @@ get_computation_cost_at (struct ivopts_data *data,
  ubase, real_cbase,
  &symbol_present, &var_present, &offset,
  depends_on);
+  diff_cost = cost.cost;
   cost.cost /= avg_loop_niter (data->current_loop);
+  add_cost_val = add_cost (TYPE_MODE (ctype), data->speed);
+  /* do cost correction if address cost is small enough
+ and difference cost is high enough */
+  if (address_p && diff_cost > add_cost_val
+  && get_address_cost (symbol_present, var_present,
+   offset, ratio, cstepi,
+   TYPE_MODE (TREE_TYPE (utype)),
+   TYPE_ADDR_SPACE (TREE_TYPE (utype)),
+   speed, stmt_is_after_inc,
+   can_autoinc).cost <= add_cost_val)
+cost.cost += add_cost_val;
 }
   else if (address_p
   && !POINTER_TYPE_P (ctype)



It also fixes the bwaves regression from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  2012-04-19 
13:15:27 UTC ---
(In reply to comment #4)
> Here is a preliminary patch which makes gfortran accept the code in
> comment #2:

Don't forget to add -std=f2003 diagnostic - either by simply marking it as
ambiguous or fancier by telling that it is invalid but would be valid in
Fortran 2008.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

--- Comment #11 from Igor Zamyatin  2012-04-19 
13:09:25 UTC ---
Another version of the experimental patch is here -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868

It fixes bwaves regression on x86 and might not trigger performance on other
platforms

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[wangmianzhi1 at linuxmail dot org]

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

--- Comment #8 from wangmianzhi  2012-04-19 
13:20:57 UTC ---
if replace the input argument for test2() with pr, the program will 
compile but gives seg fault at run time.



于 2012年04月19日 09:04, janus at gcc dot gnu.org 写道:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
>
> --- Comment #6 from janus at gcc dot gnu.org 2012-04-19 13:04:18 UTC ---
> (In reply to comment #5)
>> "Two dummy arguments are distinguishable if
>> - one is a procedure and the other is a data object,
> Here is a test case for this item:
>
>
> module m
>interface testIF
>  module procedure :: test1
>  module procedure :: test2
>end interface
> contains
>real function test1 (obj)
>  real :: obj
>  test1 = obj
>end function
>real function test2 (obj)
>  procedure(real) :: pr
>  test2 = pr(0.)
>end function
> end module
>
> program test
>use m
>print *,testIF(2.0),testIF(cos)
> end program
>
>
>
> ... which is currently rejected with:
>
>
>  module procedure :: test2
>   1
> Error: Ambiguous interfaces 'test2' and 'test1' in generic interface 'testif'
> at (1)
>

[Bug middle-end/53031] [4.8 Regression] gcc.dg/tree-ssa/vrp54.c scan-tree-dump-not vrp1 "link_error"

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-19 
13:21:50 UTC ---
Author: rguenth
Date: Thu Apr 19 13:21:44 2012
New Revision: 186592

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186592
Log:
2012-04-19  Richard Guenther  

PR tree-optimization/53031
* tree-vrp.c (adjust_range_with_scev): Revert back to
using max_loop_iterations.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug libgomp/52738] libgomp configured with --enable-tls=no crash inside pthread function

[matek09 at gmail dot com]

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

--- Comment #2 from Mateusz Kielar  2012-04-19 
13:23:17 UTC ---
The only way I see to resolve this issue is to check if pthread_getspecific
returns null in gomp_thread and if yes then allocate new thread struct and use
pthread_setspecific to store it. Could anyone share their opinion?

[Bug bootstrap/53042] New: AIX bootstrap: cgraph symbol table error

[dje at gcc dot gnu.org]

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

 Bug #: 53042
   Summary: AIX bootstrap: cgraph symbol table error
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


AIX bootstrap is broken and apparently caused by your symbol table patches.

I now see errors:

/farm/dje/src/src/libstdc++-v3/src/c++98/strstream.cc:418:1: error:
non-DECL_ONE_ONLY node in a same_comdat_group list
 } // namespace
 ^
_ZTCSt10istrstream0_Si/337 (int (* std::istrstream::_ZTCSt10istrstream0_Si
[10])(...)) @70c3df78
  Type: variable
  Visibility: public weak comdat virtual artificial
  Same comdat group as: _ZTVSt10istrstream/335
  References: _ZTISi/486 (addr)_ZNSiD1Ev/311 (addr)_ZNSiD0Ev/312
(addr)_ZTISi/486 (addr)_ZTv0_n12_NSiD1Ev/487 (addr)_ZTv0_n12_NSiD0Ev/488 (addr)
  Referring: _ZTTSt10istrstream/336 (addr)_ZTTSt10istrstream/336 (addr)
  Availability: not-ready
  Varpool flags: initialized needed analyzed finalized
/farm/dje/src/src/libstdc++-v3/src/c++98/strstream.cc:418:1: internal compiler
error: verify_symtab_node failed
 } // namespace

and

/farm/dje/src/src/libstdc++-v3/src/c++11/fstream-inst.cc:49:1: error:
non-DECL_ONE_ONLY node in a same_comdat_group list
 } // namespace
 ^
_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si/803 (int (*
std::basic_ifstream::_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
[10])(...)) @700c6708
  Type: variable
  Visibility: public weak
comdat/farm/dje/src/src/libstdc++-v3/src/c++11/fstream-inst.cc:49:1: internal
compiler error: tree check: expected identifier_node, have string_cst in
dump_symtab_base, at symtab.c:405
 } // namespace

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[matz at gcc dot gnu.org]

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

--- Comment #6 from Michael Matz  2012-04-19 13:29:34 
UTC ---
Author: matz
Date: Thu Apr 19 13:29:29 2012
New Revision: 186593

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186593
Log:
PR middle-end/52977
* tree.h (VECTOR_CST_NELTS): Use part number of types again.
(struct tree_vector): Adjust GTY length.
* tree.c (make_vector_stat): Don't set VECTOR_CST_NELTS.

* gengtype.c (struct walk_type_data): Add in_record_p and loopcounter
members.
(walk_type, ): Handle case where our
caller emitted the length calulation already.
(walk_type, ): Emit length calculations

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gengtype.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[wangmianzhi1 at linuxmail dot org]

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

--- Comment #9 from wangmianzhi  2012-04-19 
13:22:24 UTC ---
if replace the input argument for test2() with pr, the program will compile but
gives seg fault at run time.

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2012-04-19 13:36:46 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > "Two dummy arguments are distinguishable if
> > - one is a procedure and the other is a data object,
> 
> Here is a test case for this item:

Sorry, I messed up the declaration of 'test2' (by not using 'implicit none').
Therefore gfortran is correct in rejecting it. It should have been:


module m
  implicit none
  interface testIF
module procedure test1
module procedure test2
  end interface
contains
  real function test1 (obj)
real :: obj
test1 = obj
  end function
  real function test2 (pr)
procedure(real) :: pr
test2 = pr(0.)
  end function
end module

program test
  use m
  implicit none
  intrinsic :: cos
  print *,testIF(2.0)
  print *,testIF(cos)
end program


This is actually accepted by all gfortran versions I tried (4.3,4.6,4.7,trunk).
However, it yields a segfault at runtime (-fdump-tree-original shows that
'test2' is used in both calls).

[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix5.3
Version|4.7.0   |4.8.0
   Target Milestone|--- |4.8.0
Summary|AIX bootstrap: cgraph   |[4.8 Regression] AIX
   |symbol table error  |bootstrap: cgraph symbol
   ||table error

[Bug middle-end/53031] [4.8 Regression] gcc.dg/tree-ssa/vrp54.c scan-tree-dump-not vrp1 "link_error"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2012-04-19 
13:44:20 UTC ---
Fixed.

[Bug bootstrap/53042] AIX bootstrap: cgraph symbol table error

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-19
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from David Edelsohn  2012-04-19 13:44:04 
UTC ---
/farm/dje/src/src/libstdc++-v3/src/c++98/iostream-inst.cc:49:1: error:
non-DECL_ONE_ONLY node in a same_comdat_group list
 } // namespace
 ^
_ZTCSd8_So/272 (int (* std::basic_iostream::_ZTCSd8_So [10])(...))
@708fad38
  Type: variable
  Visibility: public weak comdat section_name:_ZTCSd8_So virtual artificial
  Same comdat group as: _ZTVSd/269
  References: _ZTISo/413 (addr)_ZNSoD1Ev/230 (addr)_ZNSoD0Ev/231
(addr)_ZTISo/413 (addr)_ZTv0_n12_NSoD1Ev/414 (addr)_ZTv0_n12_NSoD0Ev/415 (addr)
  Referring: _ZTTSd/270 (addr)_ZTTSd/270 (addr)
  Availability: not-ready
  Varpool flags: initialized needed analyzed finalized
/farm/dje/src/src/libstdc++-v3/src/c++98/iostream-inst.cc:49:1: internal
compiler error: verify_symtab_node failed
 } // namespace

/farm/dje/src/src/libstdc++-v3/src/c++98/istream-inst.cc:96:1: error:
non-DECL_ONE_ONLY node in a same_comdat_group list
 } // namespace
 ^
_ZTTSi/622 (const void* std::basic_istream::_ZTTSi [2]) @70a90e10
  Type: variable
  Visibility: public weak comdat section_name:_ZTTSi virtual artificial
  Same comdat group as: _ZTVSi/621
  References: _ZTVSi/621 (addr)_ZTVSi/621 (addr)
  Referring: 
  Availability: not-ready
  Varpool flags: initialized needed analyzed finalized
/farm/dje/src/src/libstdc++-v3/src/c++98/istream-inst.cc:96:1: internal
compiler error: verify_symtab_node failed
 } // namespace

[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-19 
14:09:20 UTC ---
Patch:

Index: gcc/symtab.c
===
--- gcc/symtab.c(revision 186594)
+++ gcc/symtab.c(working copy)
@@ -537,10 +537,23 @@ verify_symtab_base (symtab_node node)
 {
   symtab_node n = node->symbol.same_comdat_group;

-  if (!DECL_ONE_ONLY (n->symbol.decl))
+  if (SUPPORTS_ONE_ONLY)
{
- error ("non-DECL_ONE_ONLY node in a same_comdat_group list");
- error_found = true;
+ if (!DECL_ONE_ONLY (n->symbol.decl))
+   {
+ error ("non-DECL_ONE_ONLY node in a same_comdat_group list");
+ error_found = true;
+   }
+   }
+  else
+   {
+ if (!DECL_COMMON (n->symbol.decl)
+ && !DECL_WEAK (n->symbol.decl))
+   {
+ error ("non-DECL_COMMON / DECL_WEAK node in a same_comdat_group "
+"list");
+ error_found = true;
+   }
}
   if (n->symbol.type != node->symbol.type)
{

[Bug fortran/48438] Several gfortran tests FAIL on Tru64 UNIX

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jb at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #3 from Janne Blomqvist  2012-04-19 14:14:11 
UTC ---
AFAIU, for the 4.8 release Rainer has removed support for the alpha*-dec*-osf*
target, hence closing this PR as wontfix.

[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #1 from Bernd Schmidt  2012-04-19 
14:21:06 UTC ---
Created attachment 27190
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27190
Candidate patch

Does this fix it?

[Bug middle-end/53043] New: [4.8 Regression] gcc.target/i386/pr45830.c scan-tree-dump switchconv "Expanding as bit test is preferable"

[hjl.tools at gmail dot com]

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

 Bug #: 53043
   Summary: [4.8 Regression] gcc.target/i386/pr45830.c
scan-tree-dump switchconv "Expanding as bit test is
preferable"
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86, revision 186576 gave

FAIL: gcc.target/i386/pr45830.c scan-tree-dump switchconv "Expanding as bit
test is preferable"

Revision 186572 is OK.

[Bug fortran/40766] this fortran program is too slow

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #22 from Janne Blomqvist  2012-04-19 
14:34:35 UTC ---
AFAIK the recently released Glibc 2.15 incorporates quite a lot of work in
libm. Whether it fixes any of these performance issues I don't know.

[Bug tree-optimization/53044] New: completely peel loops that do not run a constant time

[rguenth at gcc dot gnu.org]

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

 Bug #: 53044
   Summary: completely peel loops that do not run a constant time
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


There exist loops where we do not know how many times they run.  Consider

int objects[2];

void foo (int n)
{
  int i;
  for (i = 0; i < n; ++i)
objects[i] = i;
}

we do know the loop will run at most twice (due to undefined behavior
analysis, the info is accessible via max_loop_iterations (loop)).

It could be beneficial to completely peel such loops (retaining the
exit checks, of course).  At least for loops that do not run many
times (like at most once or twice, as in the above example).

int objects[1];

void foo (int n)
{
  int i;
  for (i = 0; i < n; ++i)
objects[i] = i;
}

jump threading should handle the above case from VRP, but currently
VRP transforms the above to

:
  if (n_2(D) > 0)
goto ;
  else
goto ;

:
  return;

:

:
  ivtmp.5_1 = 0;
  i_9 = 0;
  MEM[(int[1] *)&objects] = 0;
  ivtmp.5_8 = 1;
  i_7 = 1;
  if (n_2(D) > 1)
goto ;
  else
goto ;

:
  goto ;

:
  goto ;

thus, a conditionally endless loop (ugh, a side-effect that we even preserve).

[Bug c++/53039] [4.7/4.8 Regression] including breaks std::is_convertible with template-pack expansion

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2012-04-19 14:49:32 
UTC ---
(In reply to comment #4)
> HJ, can you help with the search? (mind the -std=c++11)

My regression hunt machine is down. It will take a while to
get it back.

[Bug middle-end/53043] [4.8 Regression] gcc.target/i386/pr45830.c scan-tree-dump switchconv "Expanding as bit test is preferable"

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-04-19 14:55:54 
UTC ---
It may be caused by revision 186576:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00527.html

[Bug c/51834] -Wsequence-point fails when convoluted expressions with multiple side effects are used

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  2012-04-19 
15:06:58 UTC ---
(In reply to comment #3)
> (i++, i) + i is undefined.  The sequence point only orders i++ and i inside 
> the
> parens, but not the operands of +.  The third example is not undefined.

The example is not (i++, i) + i, but (i, i++, i) + i, which is different
because there is a sequence point before and after the i++. Still, there seem
to be disagreements on how to interpret the standard.

There's a discussion "On sequence points and evaluation order" [1] in
comp.std.c in 1995-12 (though that's a bit old), from which there are arguments
to see the above expressions as UB. But "sequence points and evaluation order"
[2] in comp.lang.c in 2006-09 and a message from Keith Thompson [3] in
comp.std.c in 2010-10 both contradict it: they both say something like sin(x) +
cos(x) has defined behavior even if sin() and cos() both modify errno (and that
these functions can be implemented by a macro, as long as it has a sequence
point).

[1]
http://groups.google.com/group/comp.std.c/browse_thread/thread/d133e9c51bef572b/0b6545278c23d37f
[2]
http://groups.google.com/group/comp.lang.c/browse_thread/thread/c4bc836b783b91be/d807a3ad7202b45b
[3] http://groups.google.com/group/comp.std.c/msg/2dc8d2e8a0f4e572

What's strange is that GCC (4.4 to 4.7 at least) complains on

  (i ? (j |= 1, 0) : 0) | (i ? (j |= 1, 0) : 0);

but not on

  (j |= 1, 0) | (j |= 1, 0);

Contrary to GCC, I would say that the latter is UB (because from the root of
the expression, one can evaluate both j |= 1 without getting a sequence point
yet -- GCC should have output a warning, and that's bug 51562), but not the
former (similar to the errno case).

Here's a simple testcase I've used, with more tests:

int i, j;

static inline int set_flag (void)
{
  j |= 1;
  return 0;
}

#define FOO (i ? (j |= 1, 0) : 0)
#define BAR (i ? set_flag () : 0)

void fct (void)
{
  FOO || FOO;
  FOO | FOO;
  BAR | BAR;
  set_flag () + set_flag ();
  j = (++i, j) + (j, ++i);
  return;
}

GCC 4.7.0 warns only for "FOO | FOO;" (and I think that's incorrect, as said
above).

[Bug middle-end/53043] [4.8 Regression] gcc.target/i386/pr45830.c scan-tree-dump switchconv "Expanding as bit test is preferable"

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-19
 AssignedTo|unassigned at gcc dot   |steven at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Steven Bosscher  2012-04-19 
15:09:29 UTC ---
Mine. The message was updated in my local tree but I omitted that file in the
commit.

[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hubicka at ucw dot cz]

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

--- Comment #95 from Jan Hubicka  2012-04-19 15:07:27 
UTC ---
> It is misleading to think that the linker accumulates code in translation unit
> order for a C++ program.  E.g., that is not what happens for template code or
> string constants.  And of course the placement of functions called in 
> different
> translation units is arbitrary.
> 
> A lot of work was done in both GNU ld and gold to move constructors from 
> .ctors
> to .init_array, all to improve startup latency for firefox.  If that same
> amount of work were done on better layout of initialization code, we would
> improve all programs.

I did some work on this, too.  GCC now identify the functions executed only at
startup and global destruction time and puts them into .text.startup
subsections.
This completely elliminate the problem for implicit constructors generated
by #include . Those just calls libstdc++ constructor that checks
flags and does nothing most of time.

Sadly I think gold still ignore those, so the optimization works only with
GNU LD.

With more complex constructors this logic helps. It is however not resonable to
assume that ctors execute and access only stuff that can be recognized by
reachability analysis to be only used at startup (after all they are
constructing something).

It is resonable to assume that static constructor in translation unit X will
access functions and variables of unit X (because it is constructing them) + of
course some other common stuff needed to do its job that is shared across rest
of construction process.

For this it makes IMO a lot of sense to make the (implicit to user) order of
execution of constructors match the (impicit) order how sections are laid out.
Sure that there are counterexamples where this does not help, but it is good
heuristics and what we do by default now is almost always the slowest variant.

Firefox is really not a special case here. C++ makes it extremely easy to
introduce
static constructors and destructors and thus most large C++ programs expose
this
problems (at least I know that Chrome and OOo do).

I am not quite sure how linker ordering plugins and code layout is going to
help here better.

Some linkers do automatic reordering based on reconstructed callgraph.
I prototyped code layout pass (ipa-reorder) based on static analysis of the
callgraph at LTO. It works by clustering the callgraph/varpool nodes into
sequences based on the presence of references hoping to get related code
together.

In my tests it however reaches very mixed results on Mozilla, because 
static analysis quickly lose track of virtual calls and use of pointers.

It still seems to me that switching the default ctor execution order, at risk
of breaking non-conforming C++ programs, is a good idea here.  We get
measurable improvements for most of large C++ packages out there and 
hopefully the fallout is not going to be great - many other runtimes
already execute ctors in forwarding order.

We could get the static function/variable reordering pass into GCC,
implement in linker reordering and do reordering based on profile feedback,
but all those are rather ortogonal to the issue discussed here.

Honza

[Bug middle-end/53043] [4.8 Regression] gcc.target/i386/pr45830.c scan-tree-dump switchconv "Expanding as bit test is preferable"

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Steven Bosscher  2012-04-19 
15:14:37 UTC ---
http://gcc.gnu.org/viewcvs?view=revision&revision=186597

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 CC||bergner at vnet dot
   ||ibm.com, wschmidt at gcc
   ||dot gnu.org
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from William J. Schmidt  2012-04-19 
15:20:21 UTC ---
I'll take this one.

[Bug target/53040] nested functions may trash floating point registers

[amodra at gmail dot com]

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

--- Comment #1 from Alan Modra  2012-04-19 15:24:30 
UTC ---
Created attachment 27191
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27191
obvious fix

[Bug target/53038] cfi_restore for cr before cr is actually restored

[amodra at gmail dot com]

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

--- Comment #2 from Alan Modra  2012-04-19 15:27:47 
UTC ---
testing a fix

[Bug target/53038] cfi_restore for cr before cr is actually restored

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-19
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c/52927] "procps" do not work with -Os flag.

[jonatan.goebel at digitel dot com.br]

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

--- Comment #9 from Jonatan GOebel  
2012-04-19 15:14:27 UTC ---
Hi.

The problem actually happen when using -Os and -frename-registers.

Also the source code may note help, because it randomly happens on different
parts of the code depending on compiling flags and source code size. But always
stuck after a "return" that never returns.

[Bug target/53040] nested functions may trash floating point registers

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-19
 Ever Confirmed|0   |1

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2012-04-19 15:47:14 
UTC ---
Given

typedef unsigned long long __u64 __attribute__((aligned(4)));

all most all __u64 will be aligned at 4.   The only case we may
do something about is

typedef unsigned long long __u64
__attribute__((aligned(4),warn_if_not_aligned(8)));

struct foo
{
  int i1;
  int i2;
  int i3;

  __u64 x;
};

since alignment of the x field also depends on alignment of
struct foo.

[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #3 from H. Peter Anvin  2012-04-19 15:51:35 
UTC ---
Logically, about half of u64's will be properly aligned at the moment... Linus'
request is that we flag the currently misaligned __[su]64's as __compat_[su]64
and make __[su]64 aligned, so at least *new* interfaces will be properly
aligned.

[Bug c++/53039] [4.7/4.8 Regression] including breaks std::is_convertible with template-pack expansion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Paolo Carlini  2012-04-19 
15:58:17 UTC ---
Too bad, didn't know that. Then I'll do something myself ASAP.

In the meanwhile, at the risk of appearing a bit boring, let me add Jason in CC
for this one too, the issue seems quite "interesting" ;)

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2012-04-19 16:00:41 
UTC ---
(In reply to comment #3)
> Logically, about half of u64's will be properly aligned at the moment... 
> Linus'

No necessarily. For

u64 x;
int y;
u64 z;

both x and z may be 4 byte aligned.

> request is that we flag the currently misaligned __[su]64's as __compat_[su]64
> and make __[su]64 aligned, so at least *new* interfaces will be properly
> aligned.

Is this feature only used for function parameters?

[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  2012-04-19 16:03:09 UTC 
---
Thanks for working on this.  The patch is pre-approved if it passes testing.

The new symtab verifier is just old cgraph verifier and only change is that
we now do same testing for variables, too.  I do not see why COMDAT_GROUP gets
right on functions and not on variables.  It seems like latent issue here:

Index: decl2.c
===
--- decl2.c(revision 186576)
+++ decl2.c(working copy)
@@ -1894,7 +1894,7 @@ maybe_emit_vtables (tree ctype)
  actually marking the variable as written.  */
   if (flag_syntax_only)
 TREE_ASM_WRITTEN (vtbl) = 1;
-  else if (DECL_COMDAT (vtbl))
+  else if (DECL_ONE_ONLY (vtbl))
 {
   current = varpool_node (vtbl);
   if (last)

At least the corresponding callgraph code is using this test.  David, does this
passes the original testing?

Honza

[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #5 from H. Peter Anvin  2012-04-19 16:05:29 
UTC ---
On 04/19/2012 09:00 AM, hjl.tools at gmail dot com wrote:
> 
>> request is that we flag the currently misaligned __[su]64's as 
>> __compat_[su]64
>> and make __[su]64 aligned, so at least *new* interfaces will be properly
>> aligned.
> 
> Is this feature only used for function parameters?
> 

No.

-hpa

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2012-04-19 16:53:18 
UTC ---
For a global or local 64bit variable, x, inside kernel,
why should it be 4 byte aligned if it isn't part of system
call interface?

[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #7 from H. Peter Anvin  2012-04-19 16:57:14 
UTC ---
The __u64/__s64 types are used for interfaces only.  The kernel itself is
x86-64 and uses aligned types for internal uses.

The mismatch between i386 and x86-64 alignment has a tendency to cause
unexpected bugs, and Linus would like to avoid those by having new interfaces
use aligned types consistently.

[Bug tree-optimization/53045] New: Missing loop termination

[ubizjak at gmail dot com]

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

 Bug #: 53045
   Summary: Missing loop termination
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com


Following testcase

--cut here--
struct { double d[1]; } foo0, foo1, foo2, foo3, foo4, foo5, foo6, foo7;

int main ()
{
  struct { double d; } bar[8]
= { 48.394, 39.3, -397.9, 3484.9, -8.394, -93.3, 7.9, 84.94 };
  int i;

  for (i = 0; i < 8; i++)
foo0.d[i] = bar[i].d;

  return 0;
}
-- cut here--

segfaults when compiled with -O2,
xgcc (GCC) 4.8.0 20120419 (experimental) [trunk revision 186596]

Loop termination is missing from asm dump:

.L2:
movsd   %xmm0, foo0(%rax)
movsd   -64(%rsp,%rax), %xmm0
addq$8, %rax
jmp .L2

Loop termination is already missing from .optimized dump:

This problem is the reason for following testsuite failures on x86 AVX:

FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -O2 
FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finli
ne-functions 
FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -O3 -g 
FAIL: gcc.target/x86_64/abi/avx/test_passing_structs.c execution,  -Os 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -O2 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finlin
e-functions 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -O3 -g 
FAIL: gcc.target/x86_64/abi/avx/test_passing_unions.c execution,  -Os

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  2012-04-19 17:07:20 
UTC ---
Shouldn't

typedef unsigned long long __u64 __attribute__((aligned(4)));

only be used in system call interface?

[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #9 from H. Peter Anvin  2012-04-19 17:11:00 
UTC ---
Yes.

The point is: WE WANT TO MIGRATE THE SYSTEM CALL INTERFACE TO AN ALIGNED
__[us]64 INTERFACE, mostly so that new interfaces are properly aligned from the
start.

In order to do that, we need to flag the existing legacy interfaces which will
need to be flagged as __compat_[us]64 in order to not break.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #27184|0   |1
is obsolete||

--- Comment #14 from H.J. Lu  2012-04-19 17:17:51 
UTC ---
Created attachment 27192
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27192
A patch

Please try this patch.

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2012-04-19 17:20:42 
UTC ---
Isn't checking alignment of x in:

typedef unsigned long long __u64
__attribute__((aligned(4),warn_if_not_aligned(8)));

struct foo
{
  int i1;
  int i2;
  int i3;

  __u64 x;
};

sufficient for kernel interface purpose?  Is there another case
we need to check?

[Bug middle-end/53046] New: [4.8 Regression] New libstdc++ test failures

[hjl.tools at gmail dot com]

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

 Bug #: 53046
   Summary: [4.8 Regression] New libstdc++ test failures
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186596 gave

FAIL: 23_containers/bitset/operations/constexpr-2.cc (test for excess errors)
FAIL: 25_algorithms/stable_partition/mem_check.cc execution test
FAIL: 25_algorithms/stable_sort/mem_check.cc execution test

Revision 186588 is OK.

[Bug middle-end/53047] New: [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

 Bug #: 53047
   Summary: [4.8 Regression] 482.sphinx3  in SPEC CPU 2006
miscompiled
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186566 miscompiled 482.sphinx3 in SPEC CPU 2006:

  Running 482.sphinx3 ref base lnx32e-gcc default

482.sphinx3: copy 0 non-zero return code (exit code=11, signal=0)



Contents of an4.err

/bin/sh: line 1: 15111 Segmentation fault  taskset -c $TASK_CPU
../run_base_
ref_lnx32e-gcc./sphinx_livepretend_base.lnx32e-gcc ctlfile . args.an4

Revision 186516 is OK.

[Bug middle-end/53048] New: [4.8 Regression] 256.bzip2 in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

 Bug #: 53048
   Summary: [4.8 Regression] 256.bzip2 in SPEC CPU 2000 failed to
build
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186591 gave

gcc -c -o bzip2.o   -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math
-fwhole-program -flto=jobserver -fuse-linker-plugin  bzip2.c
bzip2.c: In function 'sendMTFValues':
bzip2.c:1316:6: internal compiler error: Segmentation fault
 void sendMTFValues ( void )
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake[3]: *** [bzip2.o] Error 1

Revision186507 is OK.

[Bug c/52880] -Woverride-init emitts unexpected error

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-04-19 
17:42:01 UTC ---
Created attachment 27193
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27193
gcc48-pr52880.patch

This patch works for me on this testcase, not sure if it is the right fix
though.

The problem is I think in that we are moving initializers back and forth
between
constructor_elements (a vector) and constructor_pending_elts (AVL tree).  The
move from constructor_elements to AVL tree happens in set_nonincremental_init
and all constructor_elements are moved there into the AVL (and -Woverride-init
warnings emitted).  The other direction is in output_pending_init_elements,
when constructor_elements is repopulated, but nothing is removed from the AVL
tree (without -Woverride-init that is just fine, saving the need to free and
realloc AVL nodes all the time).
So, if an initializer is first added to AVL tree, then copied to
constructor_elements when all fields until .e are specified, then again moved
into AVL tree, we get a warning.

I believe that during set_nonincremental_init we should never warn about
-Woverride-init, if in incremental mode the AVL tree should be either empty, or
contain initializers already copied to constructor_elements during
output_pending_init_elements.  An attempt to override already specified
initializer should always happen in non-incremental mode IMHO, so if in
incremental mode set_nonincremental_init will happen first.

[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #11 from H. Peter Anvin  2012-04-19 17:42:28 
UTC ---
Sorry, that should be sufficient.  I'm not awake today, it seems.

[Bug middle-end/53049] New: expand/TER unappropriate moving unspec volatile

[gjl at gcc dot gnu.org]

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

 Bug #: 53049
   Summary: expand/TER unappropriate moving unspec volatile
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr


extern unsigned ivar;

void test2 (unsigned val)
{
  val = 65535U / val;

  __builtin_avr_cli();
  ivar = val;
  __builtin_avr_sei();
}

void test3 (unsigned val)
{
  val = 65535U / val;

  __asm__ __volatile__ ("cli" ::: "memory");
  ivar = val;
  __asm__ __volatile__ ("sei" ::: "memory");
}

In this C code, the division is performed by a libgcc call, and TER drags the
CLI builtin resp. asm volatile over the operation.

It's not forbidden by the standard, but anyone who ever did system programming
will agree that such transformation is devastating for interrupt response time:

In the example, the CLI/SEI instructions are used to temporarily switch off
IRQs so that an atomic (write) operation to IVAR can be performed.

Seen with 4.7.1 20120416 (prerelease) and with 4.8.0, presumably also present
on older versions.

Compiled with:

$ avr-gcc test2.c -S -Os -fdump-rtl-expand-details -dP -O1

-fno-tree-ter fixed the issue

Comfigured with:

../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-languages=c,c++

GNU C (GCC) version 4.7.1 20120416 (prerelease) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2

[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-04-19 
18:32:37 UTC ---
Created attachment 27194
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27194
C source code

[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-04-19 
18:34:38 UTC ---
Created attachment 27195
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27195
.150r.expand dump

Notice the

Replacing Expressions
val_2 replace with --> val_2 = 65535 / val_1(D);

[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-19
 Ever Confirmed|0   |1

[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  2012-04-19 18:57:38 
UTC ---
Both Richi and Honza's patches independently progress past the failure point.

[Bug debug/45088] pointer type information lost in debuginfo

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  2012-04-19 
19:09:14 UTC ---
(In reply to comment #10)
> what about 4.7 branch?

The fix was on the trunk before 4.7 branched, so yes.

[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2012-04-19 
19:18:37 UTC ---
I think there is an already closed bug about this issue and we decided last
time, it is not something which we want to implement an unspec volatile or an
volatile inline-asm as a full clobber for expressions movement.

[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2012-04-19 
19:31:12 UTC ---

In tree-ssa-ter.c:is_replaceable_p() there is:

  /* Leave any stmt with volatile operands alone as well.  */
  if (gimple_has_volatile_ops (stmt))
return false;


and in tree-ssa-ter.c:find_replaceable_in_bb():

  /* Mark expression as replaceable unless stmt is volatile, or the
 def variable has the same root variable as something in the
 substitution list, or the def and use span a call such that
 we'll expand lifetimes across a call.  */
  if (gimple_has_volatile_ops (stmt) || same_root_var

So it leaves volatiles alone -- at least that's what the comments indicate and
why there are tests for has_volatile at all.

If you drag A over B, you can just as well say that B is dragged over A.
This means that no volatile must be crossed as a statement is moved around.
Otherwise, a programm will never be able to state "There is something going on
that is important, but cannot be expressed".

C has no notion of execution time at all, but everyone knows that execution
time in /any/ program is crucial...

Is there a way in the backend to interfere with that malicous transforms?

A builtin is treated as CALL at this level, and calls are skipped to. So it's
all in a mess...

[Bug c++/53050] New: ssa_forward_propagate_and_combine: segmentation fault

[dcb314 at hotmail dot com]

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

 Bug #: 53050
   Summary: ssa_forward_propagate_and_combine: segmentation fault
Classification: Unclassified
   Product: gcc
   Version: 4.8.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 opencv-2.3.1
on gcc-4.8 trunk dated 20120418 on an AMD x86_64 box.

The compiler said

/home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp: In
function 'void cv::medianBlur_SortNet(const cv::Mat&, cv::Mat&, int) [with Op =
cv::MinMax16s; VecOp = cv::MinMaxVec16s]':
/home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1:
internal compiler error: Segmentation fault
 medianBlur_SortNet( const Mat& _src, Mat& _dst, int m )
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

valgrind says

==19270== Invalid read of size 2
==19270==at 0xC11CBC: ssa_forward_propagate_and_combine()
(tree-ssa-forwprop.c:649)
==19270==by 0xA5E64C: execute_one_pass(opt_pass*) (passes.c:2176)
==19270==by 0xA5EBD6: execute_pass_list(opt_pass*) (passes.c:2231)
==19270==by 0x7EFE4D: _ZL24tree_rest_of_compilationP11cgraph_node.isra.28
(cgraphunit.c:1872)
==19270==by 0x7F2DA5: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1942)
==19270==by 0x7F5047: cgraph_optimize() (cgraphunit.c:2007)
==19270==by 0x7F59D9: cgraph_finalize_compilation_unit()
(cgraphunit.c:2781)
==19270==by 0x5F6BCA: cp_write_global_declarations() (decl2.c:4072)
==19270==by 0xB2528E: toplev_main(int, char**) (toplev.c:572)
==19270==by 0x3B96E21734: (below main) (in /usr/lib64/libc-2.15.so)
==19270==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Preprocessed source code attached. Flags -O3 -march=amdfam10 required.

[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault

[dcb314 at hotmail dot com]

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

--- Comment #1 from dcb  2012-04-19 20:02:12 UTC ---
Created attachment 27196
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27196
gzipped C++ source code