32-bit PowerPC reference test platform
Hello, what is the reference test platform for the 32-bit PowerPC target? We have the primary target powerpc64-unknown-linux-gnu and the secondary target powerpc-ibm-aix5.3.0.0. On the GCC compile farm there is no AIX available http://gcc.gnu.org/wiki/CompileFarm and I don't have an AIX machine. On which platform should I test to show that changes like this http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02931.html cause no harm? -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Time for GCC 5.0? (TIC)
On 11/06/2012 07:06 AM, Jeff Law wrote: I tend to agree that major version number bumps ought to be tied to major user-visible changes. I think dropping reload would quality, particularly if there are other major user visible changes going on. For example, significant improvements in modularity allowing for easier plugin development, major improvements in static dynamic analysis capabilities, etc. Or a new ABI for libstdc++, I guess. -- Florian Weimer / Red Hat Product Security Team
Re: Time for GCC 5.0? (TIC)
On 6 November 2012 09:16, Florian Weimer wrote: On 11/06/2012 07:06 AM, Jeff Law wrote: I tend to agree that major version number bumps ought to be tied to major user-visible changes. It wasn't for GCC 4.0, but I'm not suggesting it should be done again. The new C++ parser and ABI in GCC 3.4 was a far more visible difference than SSA. I think dropping reload would quality, particularly if there are other major user visible changes going on. For example, significant improvements in modularity allowing for easier plugin development, major improvements in static dynamic analysis capabilities, etc. Or a new ABI for libstdc++, I guess. Which is not on the cards for the foreseeable future. The suggested attributes to allow old and new libstdc++ ABIs to coexist, and dropping the experimental rider from C++11 mode would warrant a major version bump IMHO.
Question about aliases
Hello. I've been watching the sources of aliasing in gcc and found one comment, that seemed to me a bit strange. In file `gcc/alias.c' in function `get_alias_set': /* From the former common C and C++ langhook implementation: Unfortunately, there is no canonical form of a pointer type. In particular, if we have `typedef int I', then `int *', and `I *' are different types. So, we have to pick a canonical representative. We do this below. Technically, this approach is actually more conservative that it needs to be. In particular, `const int *' and `int *' should be in different alias sets, according to the C and C++ standard, since their types are not the same, and so, technically, an `int **' and `const int **' cannot point at the same thing. Please, can you explain the following: According to the standard A typedef declaration does not introduce a new type, only a synonym for the type so specified. So, as I understand in this case `I *' and `int *' should be equal types? Also, according to the issue 6.5 (7), we cat access to an object value with expression that has a qualified version of a type compatible with the effective type of the object So, `const int *' can legally point to the `int *' but not in reverse order, and that's why `const int *' and `int *' should be in different alias sets? Alex.
Re: Time for GCC 5.0? (TIC)
On Tue, Nov 6, 2012 at 1:17 AM, Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote: On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote: Say, why don't we reserve GCC 5.0 for the first version that gets rid of reload? Then let's see if we can get there while the X in 4.X is still in single digits! (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html) I suppose LRA counts, even if it doesn't get rid of reload completely just yet. Bump the number! :-) Also the fact that GCC is now written in C++ seems to me to be deserving of a bump to 5.0. So now we have two reasons! A third reason would be the much improved diagnostics, which are user-visible changes: caret diagnostics, marco expansion, etc. There's still a lot to do on that front but it's a user visible and quite significant change. But the TIC in $SUBJECT was for tongue in cheek. Spawning a repeat of the GCC 4.0 discussion wasn't my intention. Ciao! Steven
Re: Question about aliases
On 6 November 2012 09:23, Alex Markin wrote: Also, according to the issue 6.5 (7), we cat access to an object value with expression that has a qualified version of a type compatible with the effective type of the object So, `const int *' can legally point to the `int *' but not in reverse order, A `const int*' can point to the same object as an `int*' points to, it can't point to the `int*' itself (as you wrote). Accessing a non-const `int' through a const int*' would be a case where the effective type of the object [int] is accessing through a qualified version of the type [const int], If the effective type is `const int' then an `int*' cannot point to it, because `int' is not `const int' and is not a qualified version of `const int'. But that's to do with what a `const int*' and `int*' can point to. That relates to the alias sets of `int' and `const int' which is not the same as `int*' and `const int*' and that's why `const int *' and `int *' should be in different alias sets? No, they are in different alias sets because a `const int**' and an `int**' cannot point to the same object. See http://c-faq.com/ansi/constmismatch.html
Re: calculation of pi
On 11/05/2012 12:26 PM, David Brown wrote: On 05/11/2012 11:33, Mischa Baars wrote: On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. Hi, I think you are still misunderstanding the situation here. Floating point arguments are not passed in the xmm registers because Ian thinks it's faster. They are passed in the xmm registers because that is the ABI that was agreed on long ago by a group of experienced experts involved in the design of the processor (the 64-bit AMD processors, since they pre-dated Intel's 64-bit x86 chips), compiler design, and operating system design (since it is the ABI for 64-bit x86 Linux we are discussing). It is quite possible that Ian was part of that group - he is an experienced expert - but it was not his decision. And it is /not/ going to change. The ABI is fixed - you have to live with it. I'm sure there are many aspects of the 32-bit x86 ABI that people would like to change, since it was fixed in stone before features like xmm registers were part of the x86 cpus. But that doesn't happen - you have to keep the ABI consistent. For purely internal code - static functions without external linkage - the compiler can use whatever calling conventions it wants. If you think that such calls could be done better, then that can be discussed or filed as missed optimisation bug reports. In the particular case of passing floating point arguments, of course, the extra step needed to move data from an xmm register onto the stack for the fsin code is totally negligible. The great majority of floating point operations /are/ handled by SSE instructions, since operations such as load, store, register move, and basic arithmetic outweigh the use of transcendental functions by many orders of magnitude. You do not change the ABI used by an entire operating system to shave a few clock cycles off an unusual piece of test code to calculate pi. mvh., David Then it will probably will not hurt you either when you run this 'unusual piece of test code' on your 'entire operating system' :) Mischa. 2012110501 - division by zero.tar.bz2 Description: application/bzip
GCC 4.8.0 Status Report (2012-11-06), Stage 1 is over, Stage 3 in effect immediately
Status == The GCC trunk is now in stage3, patches submitted during stage1 may be still accepted, if they don't need significant rewrites, but please try to get them in soon. There is a lot of them outstanding, so please also help reviewing them. Otherwise only bugfixes and documentation fixes are allowed for the trunk. If all goes well, stage3 would again as last time go on for roughly two months, with the aim of getting the release at the end of March to mid April. We have accumulated quite a lot of bugs during the 8 months long stage 1, please help with analysing them and bugfixing. Quality Data Priority # Change from Last Report --- --- P1 23 P2 77 P3 91 + 6 --- --- Total 191 + 6 Previous Report === http://gcc.gnu.org/ml/gcc/2012-10/msg00434.html The next report will be sent by Richard.
Re: 32-bit PowerPC reference test platform
On Tue, Nov 6, 2012 at 3:30 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: what is the reference test platform for the 32-bit PowerPC target? We have the primary target powerpc64-unknown-linux-gnu and the secondary target powerpc-ibm-aix5.3.0.0. On the GCC compile farm there is no AIX available http://gcc.gnu.org/wiki/CompileFarm First, I am trying to have IBM contribute an AIX system to the GCC Compile Farm. and I don't have an AIX machine. On which platform should I test to show that changes like this http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02931.html cause no harm? I am not sure what you mean by 32 bit PowerPC target? Yes, AIX defaults to building 32 bit applications, but 32 bit PowerPC processors are quite different (both Freescale processors and other PPC32 targets). And AIX does not support ELF, sdata, sdata2, etc. that are referenced in many of those testcases. Thanks, David
Re: 32-bit PowerPC reference test platform
On 11/06/2012 03:32 PM, David Edelsohn wrote: On Tue, Nov 6, 2012 at 3:30 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: [...] and I don't have an AIX machine. On which platform should I test to show that changes like this http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02931.html cause no harm? I am not sure what you mean by 32 bit PowerPC target? Yes, AIX defaults to building 32 bit applications, but 32 bit PowerPC processors are quite different (both Freescale processors and other PPC32 targets). And AIX does not support ELF, sdata, sdata2, etc. that are referenced in many of those testcases. Ok, does this mean that there is no primary and secondary target in GCC that covers PowerPC Book E with ELF and EABI? If I change something in this area is there at least a well known tertiary target? GCC is used for a lot of Freescale products in the embedded systems market. What is necessary to make e.g. powerpc-unknown-eabi a secondary target? -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RE: Defining scheduling resource constraint
-Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 05 November 2012 16:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the bookkeeping yourself - keep track of which registers have been set in the current cycle, and ensure insns which set the same registers go to the back of the queue and aren't considered anymore until the next cycle. I am following your advice and using sched.reorg to remove the instruction from the ready list. What I am doing is checking the register written in ready[n_ready - 1] (if any) and look for the remainder of the ready list for insns writing to the same register. If I find one such insn, in index k, then I remove the insn by moving all insns from 0 - k-1 to 1- k (essentially shifting right all instructions below k. However this is getting me into trouble with an ice. I feel like I should instead be moving the instruction from ready to pending instead of simply removing it from ready, however I have no access to Haifa-sched.c internals from the backend. Any suggestions on how to remove this instruction? Or do I need to keep more scheduling state in the backend in order to do this properly? Cheers, Paulo Matos
Re: Defining scheduling resource constraint
On 11/06/2012 05:50 PM, Paulo Matos wrote: I am following your advice and using sched.reorg to remove the instruction from the ready list. What I am doing is checking the register written in ready[n_ready - 1] (if any) and look for the remainder of the ready list for insns writing to the same register. That probably won't work, you'll need to keep track of which registers have already been written in the current cycle - that needs to be updated in the variable_issue hook. If I find one such insn, in index k, then I remove the insn by moving all insns from 0 - k-1 to 1- k (essentially shifting right all instructions below k. If you also put it back into the position in the array that has become free, that sounds about right. However this is getting me into trouble with an ice. I feel like I should instead be moving the instruction from ready to pending instead of simply removing it from ready, however I have no access to Haifa-sched.c internals from the backend. Well, if you're doing it right, you're not really removing the instructions, just reordering the array and returning a different value for n_ready. Look at c6x.c for some example code. Bernd
Hiya! I am looking for for man!
In a nutshell, I'm a university graduate (BBA) and am working as the Logistics Coordinator with the Telegraph Journal. I am an outdoor enthusiast and also enjoy numerous competitive sports. However, I do often enjoy evenings that may simply consist of watching a good movie or just sitting around chatting with others. Anyways, if you're at all interested, feel free to message me.
Re: 32-bit PowerPC reference test platform
On Tue, Nov 6, 2012 at 11:08 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: Ok, does this mean that there is no primary and secondary target in GCC that covers PowerPC Book E with ELF and EABI? If I change something in this area is there at least a well known tertiary target? GCC is used for a lot of Freescale products in the embedded systems market. What is necessary to make e.g. powerpc-unknown-eabi a secondary target? Some people post testsuite results for powerpc-unknown-linux-gnu on the testsuite mailinglist -- one from Debain and I do not know the affiliation of the other. powerpc-apple-darwin also is 32 bit. And IBM tests 32 bit multilib although GCC is built as 64 bit. I thought that Codesourcery tested 32 bit PowerPC at some point in the past. You need to ask Freescale why they are not more engaged. Thanks, David
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993 --- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-11-06 09:16:41 UTC --- Author: kkojima Date: Tue Nov 6 09:16:34 2012 New Revision: 193210 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193210 Log: PR target/41993 * mode-switching.c (create_pre_exit): Set return_copy to last_insn when copy_start is a pseudo reg. Modified: trunk/gcc/ChangeLog trunk/gcc/mode-switching.c
[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 David Fang fang at csl dot cornell.edu changed: What|Removed |Added CC||fang at csl dot cornell.edu --- Comment #3 from David Fang fang at csl dot cornell.edu 2012-11-06 09:26:38 UTC --- Would this be testable on powerpc-apple-darwin8?
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06 09:45:58 UTC --- Not completely. Apparently the new testcase fails on both x86_64-linux and i686-linux with -O1 -g. The reason for that is that with -O1 jump threading isn't performed, and the bb duplication is done in tree-ssa-loop-ch.c instead. So, I'd say we want to do something similar to what propagate_threaded_block_debug_into does, in copy_loop_headers or so, on copied_bbs, copying debug stmts into the loop body (exit-dest before the gimple_duplicate_sese_region call). Calling p propagate_threaded_block_debug_into (exit-dest, entry-dest) from the debugger fixed the testcase for -O1 -g.
[Bug middle-end/49220] ICE in create_pre_exit, at mode-switching.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-11-06 09:51:31 UTC --- x86 also uses MODE_EXIT for AVX vzeroupper insertion. The test however doesn't fail on this target.
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 --- Comment #3 from janus at gcc dot gnu.org 2012-11-06 10:10:35 UTC --- Related test case: module moda implicit none type t real, pointer :: p = null() end type t contains pure subroutine s1(a,b) type(t), intent(in) :: b class(t), allocatable, intent(out) :: a allocate(a,source=b) end subroutine pure subroutine s2(a,b) type(t), intent(in) :: b class(t), allocatable, intent(out) :: a allocate(t::a) a%p = b%p end subroutine end module (slightly modified version of the one posted at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/Vj6a0tM5cvs) Currently only the second case is rejected due to Bad target in pointer assignment in PURE procedure. Possibly the same should apply to the first one? Anyway, both should be rejected due to the CLASS, INTENT(OUT) argument.
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #15 from janus at gcc dot gnu.org 2012-11-06 10:15:46 UTC --- Author: janus Date: Tue Nov 6 10:15:42 2012 New Revision: 193226 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193226 Log: 2012-11-06 Janus Weil ja...@gcc.gnu.org PR fortran/54917 * target-memory.c (gfc_target_expr_size,gfc_target_interpret_expr): Handle BT_CLASS. * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Add support for polymorphic arguments. 2012-11-06 Janus Weil ja...@gcc.gnu.org PR fortran/54917 * gfortran.dg/transfer_class_1.f90: New. * gfortran.dg/transfer_class_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_class_1.f90 trunk/gcc/testsuite/gfortran.dg/transfer_class_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47505] [OOP] Intrinsics which should operate on polymorphic objects (BT_CLASS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47505 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-06 Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-11-06 11:31:09 UTC --- Note: CLASS-support for TRANSFER has been implemented in r193226, cf. PR 54917.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #48 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 11:35:22 UTC --- Fixed for 4.8
[Bug libstdc++/53221] [C++11] basic_string lacks copy/move constructors with allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-06 11:55:47 UTC --- Author: olegendo Date: Tue Nov 6 11:55:43 2012 New Revision: 193236 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193236 Log: PR target/54089 * config/sh/sh.c (and_xor_ior_costs, addsubcosts): Double the costs for ops larger than SImode. * config/sh/sh.md (rotcl, *rotcl): New insns and splits. (ashldi3_k): Convert to insn_and_split and use new rotcl insn. PR target/54089 * gcc.target/sh/pr54089-8.c: New. * gcc.target/sh/pr54089-9.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54089-8.c trunk/gcc/testsuite/gcc.target/sh/pr54089-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #10 from dave.anglin at bell dot net 2012-11-06 12:26:06 UTC ---
On 5-Nov-12, at 11:20 AM, amylaar at gcc dot gnu.org wrote:
I take back that statement about this being straightforward. We
need valid
minimum and maximum instruction lengths. The opaque dummy clause
automatically
provides a value to be included in these calculations.
This is failing at -O0:
(define_insn
[(set (reg:SI 29)
(div:SI (reg:SI 26) (match_operand:SI 0 div_operand )))
(clobber (match_operand:SI 1 register_operand =a))
(clobber (match_operand:SI 2 register_operand =r))
(clobber (reg:SI 26))
(clobber (reg:SI 25))
(clobber (reg:SI 31))]
!TARGET_64BIT
*
return pa_output_div_insn (operands, 0, insn);
[(set_attr type milli)
(set (attr length)
(cond [(and (match_test 0) (eq (const_int 0) (pc)))
(const_int 24)]
(symbol_ref pa_attr_length_millicode_call (insn])
The insn is actually a millicode call (branch) which needs to be able
to reach stub table. Different variants are generated depending on
pc. I modified the opaque clause a bit as I decided I didn't want to it
to depend on operand 0. Don't see how a negative length can arise.
spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/
gcc/ -fno-d
iagnostics-show-caret -O0 -w -c -o 2427-1.o /home/dave/gnu/gcc/gcc/
gcc/tests
uite/gcc.c-torture/compile/2427-1.c/home/dave/gnu/gcc/gcc/gcc/
testsuite/gcc.c-torture/compile/2427-1.c: In func
tion 'ConvertFor3dDriver':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: err
or: negative insn length
(insn 47 46 48 (parallel [
(set (reg:SI 29 %r29)
(div:SI (reg:SI 26 %r26)
(reg:SI 25 %r25)))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 19 %r19 [125]))
(clobber (reg:SI 26 %r26))(clobber (reg:SI 25
%r25))
(clobber (reg:SI 31 %r31))
]) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:8 122 {*pa.md:5433}
(nil))
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: int
ernal compiler error: in shorten_branches, at final.c:1162
0x537f7b _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../gcc/gcc/rtl-error.c:110
0x308df7 shorten_branches(rtx_def*)
../../gcc/gcc/final.c:1162
0x3094e3 rest_of_handle_shorten_branches
../../gcc/gcc/final.c:4368
Dave
--
John David Anglindave.ang...@bell.net
[Bug c++/55220] New: [c++11] Internal error when doing partial template specialization on variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55220
Bug #: 55220
Summary: [c++11] Internal error when doing partial template
specialization on variadic template
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alex.ir...@gmail.com
GCC is reporting internal error when compiling the following well-formed (to my
belief) code:
#include iostream
template typename ... struct something_like_tuple
{
};
template typename, typename struct is_last
{
static const bool value = false;
};
template typename T, template typename ... class Tuple, typename ... Head
struct is_lastT, TupleHead ..., T
{
static const bool value = true;
};
int main(int argc, char* argv[])
{
typedef something_like_tuplechar, int, float something_like_tuple_t;
std::cout is_lastfloat, something_like_tuple_t::value std::endl; /*
-- line 23 */
std::cout is_lastint, something_like_tuple_t::value std::endl;
}
g++ invoked as following:
g++ --std=c++11 test.cpp -o test
Output:
test.cpp: In function âint main(int, char**)â:
test.cpp:23:53: internal compiler error: in unify, at cp/pt.c:16952
Please submit a full bug report,
with preprocessed source if appropriate.
g++ -v
Using built-in specs.
COLLECT_GCC=##I believe not relevant##
COLLECT_LTO_WRAPPER=##I believe not relevant##
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=##I believe not relevant##
--enable-threads=posix --enable-shared --enable-checking=release
--enable-languages=c,c++ i686-pc-linux-gnu --with-mpc-include=##I believe not
relevant## --with-mpc-lib=##I believe not relevant##
Thread model: posix
gcc version 4.7.1 (GCC)
[Bug rtl-optimization/55221] New: [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 Bug #: 55221 Summary: [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction) Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk FreeBSD 10.0-CURRENT #6 r237134 ia64 Updating from gcc-4.6.4.20120928 to 4.6.4.20121102 cc -c -O2 -pipe -I/usr/local/include -fno-strict-aliasing -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.6-20121102/gcc -I.././../gcc-4.6-20121102/gcc/build -I.././../gcc-4.6-20121102/gcc/../include -I.././../gcc-4.6-20121102/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.6-20121102/gcc/../libdecnumber -I.././../gcc-4.6-20121102/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include \ -o build/rtl.o .././../gcc-4.6-20121102/gcc/rtl.c In file included from .././../gcc-4.6-20121102/gcc/genflags.c:28: .././../gcc-4.6-20121102/gcc/rtl.h:1989: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:1990: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:1991: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:1992: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:1992: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:1993: warning: ISO C forbids forward references to 'enum' types .././../gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a function)
[Bug c++/55220] [c++11] Internal error when doing partial template specialization on variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55220 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-06 Known to work||4.8.0 Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 13:09:32 UTC --- compiles ok on trunk
[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 --- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de 2012-11-06 13:18:15 UTC --- (In reply to comment #3) Would this be testable on powerpc-apple-darwin8? See also http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02051.html The -mcpu=8540 -msdata=eabi option is important. I don't know how to trigger this bug without the -mcpu=8540 option.
[Bug c/55222] New: weird unstable array subscript is above array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55222
Bug #: 55222
Summary: weird unstable array subscript is above array bounds
warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com
The following piece of code is a reduced version of a parser generated by
Bison. It triggers a new warning (which must be very recently added to 4.8, as
last week or so there were no such warning AFAICT).
One issue is that the warning looks like a certainty, array subscript is above
array bounds, well, no it is not, and another is that if I remove the previous
line, which displays yyi, then the warning disappears. This is fishy (at
least to my eyes).
$ cat array.c
#include stdio.h
typedef unsigned char uint8;
typedef signed char int8;
/* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN. */
static const uint8 yyr2[] =
{
0, 2, 0
};
/* YYPRHS[YYN] -- Index of the first RHS symbol of rule number YYN in
YYRHS. */
static const uint8 yyprhs[] =
{
0, 0, 3
};
/* YYRHS -- A `-1'-separated list of the rules' RHS. */
static const int8 yyrhs[] =
{
4, 0,-1,-1
};
void
yy_reduce_print (int yyrule)
{
int yyi;
for (yyi = 0; yyi yyr2[yyrule]; yyi++)
{
fprintf (stderr, $%d = , yyi);
fprintf (stderr, %d\n, yyrhs[yyprhs[yyrule] + yyi]);
}
}
$ gcc-mp-4.8 -Wall -O3 array.c -c
array.c: In function 'yy_reduce_print':
array.c:32:37: warning: array subscript is above array bounds [-Warray-bounds]
fprintf (stderr, %d\n, yyrhs[yyprhs[yyrule] + yyi]);
^
$ gcc-mp-4.8 --version
gcc-mp-4.8 (MacPorts gcc48 4.8-20121028_0) 4.8.0 20121028 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-mp-4.7 -Wall -O3 array.c -c
$ gcc-mp-4.7 --version
gcc-mp-4.7 (MacPorts gcc47 4.7.2_2) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
[Bug c++/55220] [c++11] Internal error when doing partial template specialization on variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55220 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 13:27:39 UTC --- seems to be fixed already for 4.7.3
[Bug lto/53808] Undefined symbol when building a library with lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot com 2012-11-06 13:53:00 UTC --- I can see two options for fixing this 1) producing a copy of the destructor when we devirtualize and not devirtualizing if we cannot emit one. 2) making the destructor that is emitted with the vtable strong. On the clang side John McCall likes the first option better (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022606.html). Jason, what do you think?
[Bug c++/55220] [c++11] ICE when doing partial template specialization on variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55220 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Known to work|4.7.3, 4.8.0| Summary|[c++11] Internal error when |[c++11] ICE when doing |doing partial template |partial template |specialization on variadic |specialization on variadic |template|template Known to fail|4.7.1 |4.5.4, 4.7.3, 4.8.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-06 14:11:05 UTC --- Unfortunately I can reproduce it everywhere. Doesn't seem a regression, though, we may have a duplicate.
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993 --- Comment #9 from uros at gcc dot gnu.org 2012-11-06 14:31:00 UTC --- Author: uros Date: Tue Nov 6 14:30:52 2012 New Revision: 193242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193242 Log: PR middle-end/41993 * gcc.dg/torture/pr41993.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr41993.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55220] [c++11] ICE when doing partial template specialization on variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55220 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 14:39:31 UTC --- Ah, it compiles OK if GCC is built with --disable-checking, but fails otherwise
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
--- Comment #13 from David Edelsohn dje at gcc dot gnu.org 2012-11-06
14:46:34 UTC ---
Because if you have a function declared as inline in a header file that gets
propagated to multiple source files is ok, but in my case that inline keyword
was removed by some $ifdef LINUX and so I end up with having the constructor
body defined in the header like this: ClassA::ClassA(){//body}. Now because
this is in the header it will propagate to all sources that includes it. So
finally I end up with that constructor in multiple constructors sources. This
would not happen if the inline keyword have not been removed from it. This was
a bug in our code and I removed it.
Okay, so the problem was *lack* of inlined constructors. Now that makes more
sense.
Our project has one exe and several shared and static libs. To make the
things easier I moved every source file in the exe. Now the problem I have is
with the order of the initialization of global objects that reside in multiple
object files. I need objects in a source file by constructed first before any
other objects in the rest of the files are constructed.
If you actually create shared libraries, you should add -fPIC to the
compilation command. This also adds some additional uniqueness to symbols.
You said that I can decorate the constructors with a priority. How to do that
? Before migrating from xlC we used #pragma priority. This is ignored by gcc.
We also used -qpriority flag of xlC. Also gcc does not have something like
this. Or?
Use __attribute__ ((init_priority ()))
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
[Bug middle-end/49220] ICE in create_pre_exit, at mode-switching.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-11-06 14:46:59 UTC --- Kaz, can you please submit the patch from comment #1 to the mailing list?
[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-06 14:57:22 UTC --- Should be fixed now.
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06 15:04:10 UTC --- The change is that now the struct is dynamically initialized rather than statically as it used to. So it is not wrong, just worse code quality. And the reason for that is that maybe_constant_value doesn't fold it into a constant, because there is TREE_OVERFLOW. sizeof result is size_t, unsigned type and TREE_OVERFLOW comes probably from - 1 at the end converted to -1U and then converted to int.
[Bug tree-optimization/55216] [4.8 Regression] Infinite loop generated on non-infinite code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||amonakov at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org 2012-11-06 15:05:40 UTC --- The code invokes undefined behavior and is invalid: accessing d[++k] implies that modified k is less than 16 (because maximum valid index of d is 15), and therefore loop test (k 16) is always true. Enhancement request to produce a warning is filed as PR 52365.
[Bug tree-optimization/55216] [4.8 Regression] Infinite loop generated on non-infinite code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216 --- Comment #3 from Alexander Monakov amonakov at gcc dot gnu.org 2012-11-06 15:06:50 UTC --- Enhancement request to produce a warning is filed as PR 52365. Correction: PR 53265.
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.4
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06
15:21:25 UTC ---
enum E { E1 = -1 + (int) (sizeof (int) - 1) };
errors while it used to be accepted before.
Dunno if that is valid or not.
If it is valid, the series of foldings that result into the overflow are first
folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and later
on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to
-1 + (int) sizeof (int) + (int) 18446744073709551615UL.
[Bug middle-end/55219] [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-06 15:31:43 UTC ---
Here is a reduced testcase that still uses over 2GB of RAM in all
supported gcc versions:
markus@x4 tmp % cat test.i
typedef enum
{ b }
zn_type;
int x, a1_1_2, a1_1_8, a1_1_4, a1_1_3, a1_0, a1_0_0, a1_1_5;
double a2_0_1;
const int a2_1_4;
const zn_type a2_0;
void
fn1 ()
{
a1_0_0 =
(a1_0 ? a1_1_2 : a1_0 ? a1_1_3 : a1_0 ? a1_1_4 : a1_0 ? a1_1_5 :
a1_0 ? a1_1_3 : a1_0 ? a1_1_4 : a1_0 ? a1_1_8 : x) +
(a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ?
:
a2_0 ? : a2_0 ? : a2_0 ? a2_0_1 : a2_0 ? : 0 ? : a2_0 ? : a2_0 ? :
a2_0 ? : a2_0 ? : a2_0 ? : a2_0 ? a2_1_4 : a2_0 ? : x);
}
markus@x4 tmp % ulimit -v 200
markus@x4 tmp % gcc -c test.i
virtual memory exhausted: Cannot allocate memory
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de 2012-11-06 15:31:42 UTC --- (In reply to comment #2) The change is that now the struct is dynamically initialized rather than statically as it used to. What do you mean with dynamically initialized? So it is not wrong, just worse code quality. You mean that the result of Paolo Carlini's test case is correct?
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #5 from Sebastian Huber sebastian.hu...@embedded-brains.de
2012-11-06 15:34:57 UTC ---
(In reply to comment #3)
enum E { E1 = -1 + (int) (sizeof (int) - 1) };
errors while it used to be accepted before.
Dunno if that is valid or not.
If it is valid, the series of foldings that result into the overflow are first
folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and
later
on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to
-1 + (int) sizeof (int) + (int) 18446744073709551615UL.
Why is the ( ) ignored? The sizeof (int) - 1 is clearly an unsigned integer
which can be converted to a signed integer.
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06 15:37:09 UTC --- What I mean that for your testcase while you have s: .zero 8 instead of s: .long 4, 16399, there is also dynamic initialization: movl$4, s(%rip) movl$16399, s+4(%rip) (at -O2, at -O0 worse).
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #11 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-06 15:40:43 UTC --- (In reply to comment #10) The insn is actually a millicode call (branch) which needs to be able to reach stub table. Different variants are generated depending on pc. I modified the opaque clause a bit as I decided I didn't want to it to depend on operand 0. Don't see how a negative length can arise. I was actually astonished that these patterns work at all to some extent; the way I recalled it, you have to test for every possible value of your c-function in a cond clause, and then provide that value as a constant, for the length calculation to work. I see now that you get INT_MAX substituted as the maximum length if the value is unknown. If you add anything to that, the value becomes negative. I suppose your only get-out-of-jail card with the current interface, if you can't/won't provide a full cond with constant values, is to let ADJUST_INSN_LENGTH obliterate the MAX_INT, and replace it with something sensible.
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de 2012-11-06 15:50:38 UTC --- (In reply to comment #6) What I mean that for your testcase while you have s: .zero 8 instead of s: .long 4, 16399, there is also dynamic initialization: movl$4, s(%rip) movl$16399, s+4(%rip) (at -O2, at -O0 worse). Ok, I should have looked at the assembler output. I hit this problem on the RTEMS operating system. It uses a supposed to be statically initialized configuration structure for system initialization. The global constructors run in the initialization task (which would dynamically initialize the configuration structure now). To be able to start the initialization task, we need the configuration. From my point of view this dynamic initialization is pretty bad here.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 Jan Engelhardt jengelh at inai dot de changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #2 from Jan Engelhardt jengelh at inai dot de 2012-11-06 16:19:09 UTC --- Thanks for the description. It seems that what you say also affects the x32 mode (-mx32) for x86_64, am I correct in that observation?
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #14 from Adi adivilceanu at yahoo dot com 2012-11-06 16:22:37 UTC --- Regarding the __attribute__ ((init_priority ())). Are you sure this works on AIX at namespace level. I think it might work on linux. But on AIX I see no way of that ever working. Here is my understanding on how collect2 works on AIX(correct me if I am wrong): - g++ front end creates one _GLOBAL__I_65535_0_nameoffirstobject per object file. Here it is putting all the static constructors that should be called from that object file. - collect2 links (via ld) the whole exe(+libs). Then it is scanning all the _GLOBAL__ and is putting them into the ctors array and generates a functions named _GLOBAL__FI_exe_name that will call each _GLOBAL__* entry fro the array in reverse order. So as I see it this whole mechanism can at maximum support priority ordering on a object file basis. (I mean it could sort the _GLOBAL__* entries according to some criteria). Question: How can you influence this criteria? I did a hack and altered the ctors array generated by collect2(in that /tmp//ccGVUVzP.c) and reordered all those _GLOBAL__* entries based on my project needs. Then I recompiled the ccGVUVzP.c file and manually called ld (like g++ is doing the second time). So somehow I simulate the #pragma priority from xlC on a file basis. And the hack worked. Now if you use init_priority for a single global variable in an object file, and use it again on another global in a different object file I do not see how this could work? How would bypass the _GLOBAL__* entries in the ctors array which is already sorted? So my big assumption here is(correct me if I am wrong): On gcc for AIX, all globals from an object file are initialized before globals from another object file are. So you can not have initialization of one global1 from object1.o and then global2 from object2 and then global3 from object1 again. Is my assuption correct? If so a __attribute__ ((init_priority is not ok for what I need. Now regarding the fPIC. I just started using it now. That has changed a lot of stuff. First the _GLOABL__* names are now based on file name rather than name of first object. I am just starting to test this. I will follow up with the results. Thanks for your support.
[Bug middle-end/55130] [4.8 Regression] ICE in insn_rhs_dead_pseudo_p, at lra-constraints.c:3224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55130 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-11-06 16:45:47 UTC --- Fixed.
[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-06 17:04:00 UTC --- The profile should not be affected by clonning. We do not re-run the estimation and simply use what was there before...
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06 17:11:21 UTC --- Created attachment 28624 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28624 gcc48-pr55137.patch Untested patch.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #12 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-06 17:25:30 UTC --- One way to get the maximum right would be to change genattrtab:max_attr_value too process umax and/or smax, and use that to encapsulate the symbol_ref. longer term, i think it would be nice if we had rtx codes that not so much min/max, but assert that a value is in a given range; with gcc_assert in the generaed function. We could use one to assert a range that is invaiant during branch shortening, and another one that is variant.
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #13 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-11-06 17:54:31 UTC --- The patch tests clean on x86_64-linux.
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756
--- Comment #4 from janus at gcc dot gnu.org 2012-11-06 17:58:36 UTC ---
Draft patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 193224)
+++ gcc/fortran/resolve.c(working copy)
@@ -419,6 +419,16 @@ resolve_formal_arglist (gfc_symbol *proc)
sym-declared_at);
}
}
+
+ /* F08:C1278a. */
+ if (sym-ts.type == BT_CLASS sym-attr.intent == INTENT_OUT
+ (gfc_option.allow_std GFC_STD_F2008) != 0)
+{
+ gfc_error (INTENT(OUT) argument '%s' of pure procedure '%s'
+ at %L may not be polymorphic in Fortran 2008,
+ sym-name, proc-name, sym-declared_at);
+ continue;
+}
}
if (proc-attr.implicit_pure)
Unfortunately, we cannot use 'gfc_notify_std' here (or we would need to add
something like GFC_STD_F2008_DEL, although this is not officially a 'deleted
feature', I guess).
So, we could just go with the above, or alternatively reject it regardless of
the chosen standard. This 'feature' probably counts as an 'oversight' which was
missed in F03 and added to F08 only in a corrigendum.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #17 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-06 17:59:04 UTC --- Author: aoliva Date: Tue Nov 6 17:58:52 2012 New Revision: 193251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193251 Log: PR debug/54693 * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): Use a stack vector before allocating a pointer set. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #3 from davem at gcc dot gnu.org 2012-11-06 18:00:30 UTC --- Unfortunately I'm not familiar enough with the i386 backend to say whether the situation is identical there for x32 code generation. But if it were the case, it would not surprise me.
[Bug target/47440] Use LCM for vzeroupper insertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-11-06 18:03:40 UTC --- Author: kyukhin Date: Tue Nov 6 10:29:23 2012 New Revision: 193229 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193229 Log: * config/i386/i386-protos.h (emit_i387_cw_initialization): Deleted. (emit_vzero): Added prototype. (ix86_mode_entry): Likewise. (ix86_mode_exit): Likewise. (ix86_emit_mode_set): Likewise. * config/i386/i386.c (typedef struct block_info_def): Deleted. (define BLOCK_INFO): Deleted. (check_avx256_stores): Added checking for MEM_P. (move_or_delete_vzeroupper_2): Deleted. (move_or_delete_vzeroupper_1): Deleted. (move_or_delete_vzeroupper): Deleted. (ix86_maybe_emit_epilogue_vzeroupper): Deleted. (function_pass_avx256_p): Deleted. (ix86_function_ok_for_sibcall): Deleted disabling sibcall. (nit_cumulative_args): Deleted initialization of of avx256 fields of cfun-machine. (ix86_emit_restore_sse_regs_using_mov): Deleted vzeroupper generation. (ix86_expand_epilogue): Likewise. (ix86_avx_u128_mode_needed): New. (ix86_i387_mode_needed): Renamed ix86_mode_needed. (ix86_mode_needed): New. (ix86_avx_u128_mode_after): New. (ix86_mode_after): New. (ix86_avx_u128_mode_entry): New. (ix86_mode_entry): New. (ix86_avx_u128_mode_exit): New. (ix86_mode_exit): New. (ix86_emit_mode_set): New. (ix86_expand_call): Deleted vzeroupper generation. (ix86_split_call_vzeroupper): Deleted. (ix86_init_machine_status): Initialzed optimize_mode_switching. (ix86_expand_special_args_builtin): Changed. (ix86_reorg): Deleted a call of move_or_delete_vzeroupper. * config/i386/i386.h (VALID_AVX256_REG_OR_OI_MODE): New. (AVX_U128): New. (avx_u128_state): New. (NUM_MODES_FOR_MODE_SWITCHING): Added AVX_U128_ANY. (MODE_AFTER): New. (MODE_ENTRY): New. (MODE_EXIT): New. (EMIT_MODE_SET): Changed. (machine_function): Deleted avx256 fields. * config/i386/i386.md (UNSPEC_CALL_NEEDS_VZEROUPPER): Deleted. (define_insn_and_split *call_vzeroupper): Deleted. (define_insn_and_split *call_rex64_ms_sysv_vzeroupper): Deleted. (define_insn_and_split *sibcall_vzeroupper): Deleted. (define_insn_and_split *call_pop_vzeroupper): Deleted. (define_insn_and_split *sibcall_pop_vzeroupper): Deleted. (define_insn_and_split *call_value_vzeroupper): Deleted. (define_insn_and_split *sibcall_value_vzeroupper): Deleted. (define_insn_and_split *call_value_rex64_ms_sysv_vzeroupper): Deleted. (define_insn_and_split *call_value_pop_vzeroupper): Deleted. (define_insn_and_split *sibcall_value_pop_vzeroupper): Deleted. (define_expand return): Deleted vzeroupper emitting. (define_expand simple_return): Deleted. * config/i386/predicates.md (vzeroupper_operation): New. * config/i386/sse.md (avx_vzeroupper): Changed. testsuite/ChangeLog: * gcc.target/i386/avx-vzeroupper-5.c: Changed scan-assembler-times. * gcc.target/i386/avx-vzeroupper-8.c: Likewise. * gcc.target/i386/avx-vzeroupper-9.c: Likewise. * gcc.target/i386/avx-vzeroupper-10.c: Likewise. * gcc.target/i386/avx-vzeroupper-11.c: Likewise. * gcc.target/i386/avx-vzeroupper-12.c: Likewise. * gcc.target/i386/avx-vzeroupper-19.c: Likewis. * gcc.target/i386/avx-vzeroupper-27.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-27.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-10.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-11.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-12.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-19.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-5.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-8.c trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-9.c
[Bug target/47440] Use LCM for vzeroupper insertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg00292.htm ||l Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-11-06 18:05:21 UTC --- Implemented in 4.8.0.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #24 from davem at gcc dot gnu.org 2012-11-06 18:07:46 UTC --- On several occasions, in both public and private emails, I have in fact expressed my displeasure with how the configure system and the sparc backend treat things based upon the target triplet. I've always, and consistently, expressed my position that when configure sees plain sparc gcc should generate 32-bit code by default. And when it sees sparc64 it should generate 64-bit code by default. Finally, I've always stated that there should be an easy way to modify this default (after installation) on a system wide basis (f.e. via a file under sysroot). Back to the bug. I do builds with --with-cpu=niagara4 so that more of the VIS patterns and new code gets exercised. Among other things, this changes the heuristics for various things like block moves. This unaligned load is part of a block move resulting from a structure copy. In any event, I can reproduce it by using --with-cpu=v8, so I can debug it properly. I hope to have this fixed by the end of today.
[Bug c++/55223] New: [C++11] Default lambda expression of a templated class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223
Bug #: 55223
Summary: [C++11] Default lambda expression of a templated class
member
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vince@gmail.com
The following example returns a compiler error internal compiler error : in
tsubst_copy, at cp/pt.c:11354. It occurs when the default std::function of a
templated class member is used :
//---
#include iostream
#include functional
templatetypename T struct C
{
static T test(std::functionT(int) f = [](int i){return i;})
{return f(42);}
};
int main(int argc, char* argv[])
{
Cint::test(); // ERROR = internal compiler error : in tsubst_copy, at
cp/pt.c:11354
Cint::test([](int i){return i;}); // OK
return 0;
}
//---
Tested on GCC 4.6.3 and 4.7.2.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #11 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-06 19:23:51 UTC --- The associated core issue http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1495 has now ready state, so I think this issue could now be unsuspended
[Bug c++/55223] [C++11] Default lambda expression of a templated class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-06 Blocks||54367 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 19:37:27 UTC --- crashes in the same place as Bug 53486, but I think that's ice-on-invalid-code and has a huge testcase, so let's keep this open
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|SUSPENDED |NEW Summary|[C++0x] ICE when adding |[Core/1495] ICE when adding |partial specialization for |partial specialization for |variadic-templated |variadic-templated |structure |structure --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-06 20:12:16 UTC --- Ok. In such cases, let's remember to add the DR # to the Subject.
[Bug middle-end/54685] [SH] Improve unsigned int comparison with 0x7FFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54685 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-06 20:24:57 UTC --- I've briefly checked this on ARM and there the expansion is done in a similar way. However, due to ARM's ISA it is not that much of a problem.
[Bug c++/52343] [C++11] alias-definition dont work in `templateclass` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 --- Comment #2 from Larry Evans cppljevans at suddenlink dot net 2012-11-06 20:53:02 UTC --- Created attachment 28625 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28625 test file
[Bug c++/52343] [C++11] alias-definition dont work in `templateclass` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 --- Comment #3 from Larry Evans cppljevans at suddenlink dot net 2012-11-06 20:55:19 UTC --- Created attachment 28626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28626 compilation of test file with 2 compilers and 2 values of macro. The error is shown when -DUSE_ALIAS and with the later compiler, which was created with release configuration. The earlier compiler, with debug configuration, doesn't show error.
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-06 21:05:35 UTC --- if the DR makes it ill-formed and GCC rejects it is this FIXED?
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 --- Comment #5 from janus at gcc dot gnu.org 2012-11-06 21:19:54 UTC --- (In reply to comment #4) Draft patch: In fact this causes a number of testsuite failures: FAIL: gfortran.dg/class_array_3.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_array_7.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_dummy_4.f03 -O (test for excess errors) FAIL: gfortran.dg/typebound_operator_4.f03 -O (test for excess errors) FAIL: gfortran.dg/typebound_proc_16.f03 -O (test for excess errors) I think that all of the errors are correct (meaning the test cases are invalid).
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #38 from François Dumont fdumont at gcc dot gnu.org 2012-11-06 21:22:48 UTC --- Sure, I will. However I don't expect this problem to have any relation with the performance subject of this PR.
[Bug middle-end/55219] [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-06 Ever Confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-11-06 21:25:30 UTC --- Problem is in fold-const.c.
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #39 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-06 21:33:57 UTC --- Ok thanks. I guess depending on the complexity of the fixes we can apply some only to mainline first and reconsider the 4_7 branch later. Please do your best to work on both issues: we just entered Stage 3 thus no new features from now on, we are all concentrated on bug fixes until the release.
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #15 from Adi adivilceanu at yahoo dot com 2012-11-06 21:49:47 UTC --- This is a follow up on comment 14. It seems that -fPIC dramatically improved the way constructors are called. It seems that the linker has some logic and is initializing the globals from various object files in a correct order.(it somehow checks the dependencies betweeen globals I assume). I don't know how this is happening yet. As I see the ctors array has the same elements(except for the generated name that has changed), so something other then the ctors list is involved here. Do you know what? Now this works on my exe that is linked with static libs. Now if I go and link my exe with the shared version of my libs than it is not working. I saw this is because first all the constructors from the exe are called first and only after that constructors from the shared libs are called. But as I said I need some objects from the shared lib constructed first before objects in the main exe are initialized. Do you know how I can solve this case ?
[Bug middle-end/55219] [4.7/4.8 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-06 21:52:08 UTC --- Created attachment 28627 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28627 callgraph A callgraph is attached.
[Bug target/55224] New: [4.8 Regression] FAIL: gcc.target/i386/tailcall-1.c scan-assembler jmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55224 Bug #: 55224 Summary: [4.8 Regression] FAIL: gcc.target/i386/tailcall-1.c scan-assembler jmp Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: kirill.yuk...@intel.com, vbyakov...@gmail.com On Linux/ia32, revision 193229: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00176.html caused: FAIL: gcc.target/i386/tailcall-1.c scan-assembler jmp
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-06 22:15:02 UTC --- There is no x32 mode in hardware. Since x32 runs in 64-bit mode and only OS limits x32 address space to 32-bit, x32 process has full access to 64-bit insns, just like 64-bit process.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #25 from davem at gcc dot gnu.org 2012-11-06 22:32:40 UTC --- Just an update. I know what the exact problem is. Actually it's a combination of things. Because of the way that IRA maintains it's hard reg sets, it can end up thinking that odd integer registers are legitimate to allocate for DImode values. Specifically, when an allocno's -profitable_regs is populated, it sets bits for both registers in a DImode pair (actually this happens when populating ira_useful_class_mode_regs[][], which in turn get copied into the initial value of -profitable_regs). Then during allocation, the bits are tested individually. So say that all the integer register pairs are set in the profitable_regs reg set. Then %o0 is allocated for an SImode value. IRA thinks that it's ok to allocate %o1 for a DImode pseudo because %o1 and %o2 are set in the hard register set. Even if the above problem is solved, the next problem we run into has to do with argument passing. Normally if we have something like (set (reg:DI %o1) ...) it will get split up into two SImode moves. But this cannot happen if the SET_SRC is a non-offsetable MEM. We relied upon the constraint that got removed to force a reload in this situation. I am going to do one of two possible things tonight to solve this. I'll either create a new register class for these even DImode hard regs, or I'll simply revert my change.
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #16 from janus at gcc dot gnu.org 2012-11-06 22:44:59 UTC --- Author: janus Date: Tue Nov 6 22:44:47 2012 New Revision: 193262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193262 Log: 2012-11-06 Janus Weil ja...@gcc.gnu.org PR fortran/54917 * target-memory.c (gfc_target_expr_size,gfc_target_interpret_expr): Handle BT_CLASS. 2012-11-06 Janus Weil ja...@gcc.gnu.org PR fortran/54917 * gfortran.dg/transfer_class_1.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/transfer_class_1.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/target-memory.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from janus at gcc dot gnu.org 2012-11-06 22:52:35 UTC --- With r193226 and r193262, the ICEs and runtime problems have been fixed on trunk, and the regression ICE has also been backported to 4.7. Closing as fixed. Thanks for the bugreport!
[Bug middle-end/49220] ICE in create_pre_exit, at mode-switching.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220 --- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-11-06 23:21:46 UTC --- I'll post it when the usual tests on x86 and sh are done.
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg00444.htm ||l CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org |
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #14 from Michal Malecki ethouris at gmail dot com 2012-11-06 23:32:36 UTC --- (In reply to comment #13) if the DR makes it ill-formed and GCC rejects it is this FIXED? GCC rejects it by doing ICE. I don't think this is the right thing that GCC should do. My last proposal is: gcc should report error at the place where the wannabe specialization is defined (comment with line 18) with something like: 18: This template specialization does not match the template parameters\n12: of this class template. I cannot check whether gcc currently fixed to do this, so I'm sorry if this is behind the current state.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #5 from Jan Engelhardt jengelh at inai dot de 2012-11-07 00:00:01 UTC --- Dave, what do you think about a new mode for SPARC similar to -mx32, in other words, -m64+ILP32?
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-07 00:08:48 UTC --- (In reply to comment #14) GCC rejects it by doing ICE. I don't think this is the right thing that GCC should do. No it doesn't it gives an error, see comment 4. My last proposal is: gcc should report error at the place where the wannabe specialization is defined (comment with line 18) with something like: 18: This template specialization does not match the template parameters\n12: of this class template. I cannot check whether gcc currently fixed to do this, so I'm sorry if this is behind the current state. t.cc:1:11: error: 'size_t' has not been declared template size_t B, typename Type1, typename... Types ^ t.cc:8:8: error: partial specialization is not more specialized than the primary template because it replaces multiple parameters with a pack expansion struct tuple_sliced0, Types... // -- line 18 ^ t.cc:2:8: note: primary template here struct tuple_sliced ^ t.cc:10:13: error: 'tuple' does not name a type typedef tupleTypes... type; ^
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #13 from dave.anglin at bell dot net 2012-11-07 00:39:01 UTC --- On 6-Nov-12, at 10:40 AM, amylaar at gcc dot gnu.org wrote: I see now that you get INT_MAX substituted as the maximum length if the value is unknown. If you add anything to that, the value becomes negative. I suppose your only get-out-of-jail card with the current interface, if you can't/won't provide a full cond with constant values, is to let ADJUST_INSN_LENGTH obliterate the MAX_INT, and replace it with something sensible. It appears that I need to provide the min length instead of the max length in the opaque condition. Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when it is MAX_INT, then the error won't occur. For the call patterns, the number of permutations got out of hand and impossible to maintain. Dave -- John David Anglindave.ang...@bell.net
[Bug libstdc++/51850] debug mode for std::array and tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51850 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-07 00:42:26 UTC --- Author: paolo Date: Wed Nov 7 00:42:19 2012 New Revision: 193278 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193278 Log: 2012-11-06 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/51850 * include/debug/array: New, debug-mode implementation. * include/profile/array: New. * include/std/array: Adjust. * include/std/tuple: Just include array. * include/Makefile.am: Add. * include/Makefile.in: Regenerate. * testsuite/23_containers/array/debug/front1_neg.cc: New. * testsuite/23_containers/array/debug/ square_brackets_operator1_neg.cc: Likewise. * testsuite/23_containers/array/debug/front2_neg.cc: Likewise. * testsuite/23_containers/array/debug/ square_brackets_operator2_neg.cc: Likewise. * testsuite/23_containers/array/debug/back1_neg.cc: Likewise. * testsuite/23_containers/array/debug/back2_neg.cc: Likewise. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Tweak to run only in normal-mode. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: Likewise. * testsuite/23_containers/array/tuple_interface/get_debug_neg.cc: New. * testsuite/23_containers/array/tuple_interface/ tuple_element_debug_neg.cc: Likewise. Added: trunk/libstdc++-v3/include/debug/array trunk/libstdc++-v3/include/profile/array trunk/libstdc++-v3/testsuite/23_containers/array/debug/ trunk/libstdc++-v3/testsuite/23_containers/array/debug/back1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/debug/back2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/debug/front1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/debug/front2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_debug_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_debug_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/std/array trunk/libstdc++-v3/include/std/tuple trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug libstdc++/51850] debug mode for std::array and tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51850 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-07 00:43:19 UTC --- Done.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #14 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-07 00:53:48 UTC --- (In reply to comment #13) It appears that I need to provide the min length instead of the max length in the opaque condition. It's more like, this is the only thing you can do effectively as long as you have an unbounded value in the attribute. And the way the max_attr_length calculation works now, the only bounded values are selections of constants via if-then-else / cond. Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when it is MAX_INT, then the error won't occur. I suppose so, but you'd still have a ridiculous size estimate. And having one INT_MAX length instruction plus a delay slot insn can still push you over the INT_MAX edge.
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #16 from David Edelsohn dje at gcc dot gnu.org 2012-11-07 01:27:00 UTC --- G++ should create one specially named _GLOBAL__I_N_X function per constructor. collect2 sorts the constructors based on the N priority number encoded in the name. If G++ is not creating separate constructors, then that is a general G++ question and not AIX-specific. As far as the problem with shared libs, this is a known, general deficiency in AIX. This is what I referenced in comment #13. AIX runs initializers breadth-first, not depth-first. There is another GCC Bugzilla PR open about this problem.
[Bug target/55218] armv6 doesn't use unaligned access for packed structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-07 02:13:32 UTC --- (After reading the linked post.) Somewhat related: maybe the changes.html text should say bootloader or startup code instead of kernel because everyone just thinks it just means Linux. Patches welcome.
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-07
04:03:53 UTC ---
This is an interesting one. This is the gcc code:
enum memmodel
{
MEMMODEL_RELAXED = 0,
MEMMODEL_CONSUME = 1,
MEMMODEL_ACQUIRE = 2,
MEMMODEL_RELEASE = 3,
MEMMODEL_ACQ_REL = 4,
MEMMODEL_SEQ_CST = 5,
MEMMODEL_LAST = 6
};
#define MEMMODEL_MASK ((116)-1)
enum memmodel model;
model = get_memmodel (CALL_EXPR_ARG (exp, 2));
if ((model MEMMODEL_MASK) != MEMMODEL_RELAXED
(model MEMMODEL_MASK) != MEMMODEL_SEQ_CST
(model MEMMODEL_MASK) != MEMMODEL_RELEASE)
{
error (invalid memory model for %__atomic_store%);
return NULL_RTX;
}
HLE_STORE is 1 16, so outside the enum range
But when looking at the assembler we see that the MEMMODEL_MASK
gets optimized away, it just generates a direct sequence of 32bit cmps.
This makes all the != fail, even though they should succeed
I presume the optimizer assumes nothing can be outside the enum.
I tried to expand the enum by adding
MEMMODEL_ARCH1 = 1 16,
MEMMODEL_ARCH2 = 1 17,
MEMMODEL_ARCH3 = 1 18,
MEMMODEL_ARCH4 = 1 19
But still doesn't work.
Questions:
- Is it legal for the optimizer to assume this?
- Why does extending the enum not help?
We could fix it by not using an enum here of course, but I wonder if this is an
underlying optimizer bug.
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #2 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-07 04:31:24 UTC --- Clang deemed this issue important enough to warrant a new entry (Incomplete retrn types, under Declared type of an expression) in their C++11 status page.
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #3 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-07 04:32:06 UTC --- (In reply to comment #2) Clang deemed this issue important enough to warrant a new entry (Incomplete retrn types, under Declared type of an expression) in their C++11 status page. Link: http://clang.llvm.org/cxx_status.html
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #6 from davem at gcc dot gnu.org 2012-11-07 05:44:52 UTC --- That's basically what -m32 -mcpu=v9 is Jan. The compiler just isn't taking advantage of it as well as it can due to how the sparc backend is designed. We have access to 16 64-bit registers at all times. Please, drop this discussion, when I get a large block of time I'll work on improving the sparc backend in this area. This discussion is just consuming my time and making it take longer for me to get to that task. Thanks.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #26 from davem at gcc dot gnu.org 2012-11-07 07:11:44 UTC --- Ok, it seems it is not possible to expression the even integer register condition using register classes. Therefore I will revert the U constraint removal. I tried creating a DI32_REGS register class that only contained the even integer registers. But this doesn't work because the test of whether a hard register is within a class requires that all of the registers that are a part of the DImode register pair are in the class. So you'd need to include both the even and odd registers, which defeats the entire point of trying to express this using a register class. Longer term we do need a fix for this. It is very clear that IRA is allocating odd registers at times for DImode pseudos on 32-bit, and the only reason it works is that things get fixed up later by either reload or the DImode splitters. If we extended define_register_constraint such that extra conditions could be specified, we could get IRA to do the right thing and also have reload fix up the unavoidable cases where we must use odd numbered registers for DImode values on 32-bit such as argument passing.
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #16 from Michal Malecki ethouris at gmail dot com 2012-11-07 07:17:46 UTC --- (In reply to comment #15) (In reply to comment #14) GCC rejects it by doing ICE. I don't think this is the right thing that GCC should do. No it doesn't it gives an error, see comment 4. ... I'm sorry if this is behind the current state. In this below, just add #include tuple to get rid of undefined symbol errors :) t.cc:1:11: error: 'size_t' has not been declared template size_t B, typename Type1, typename... Types ^ t.cc:8:8: error: partial specialization is not more specialized than the primary template because it replaces multiple parameters with a pack expansion struct tuple_sliced0, Types... // -- line 18 ^ And that's what it should be, thanks. (Would be nice of course, if the part of the message starting from the primary template is another message assigned to the line where the primary template is defined, but this is just cosmetic :).
[Bug libquadmath/55225] New: Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 Bug #: 55225 Summary: Fail to build lgammaq.c from trunk with mingw-w64 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath AssignedTo: unassig...@gcc.gnu.org ReportedBy: alex...@gmail.com Mingw-w64 doesn't have declared signgam in math.h that leads to an error: depbase=`echo math/lgammaq.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CC --mode=compile /temp/x64-trunk-snapshot-posix-seh-rev0/build/gcc-trunk/./gcc/xgcc -B/temp/x64-trunk-snapshot-posix-seh-rev0/build/gcc-trunk/./gcc/ -L/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/lib -L/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/mingw/lib -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/include -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/mingw/include -B/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/bin/ -B/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/lib/ -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/include -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../mingw-sources/gcc-trunk/libquadmath -g -O2 -pipe -fomit-frame-pointer -I/temp/x64-trunk-snapshot-posix-seh-rev0/libs/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -MT math/lgammaq.lo -MD -MP -MF $depbase.Tpo -c -o math/lgammaq.lo ../../../../../mingw-sources/gcc-trunk/libquadmath/math/lgammaq.c \ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /temp/x64-trunk-snapshot-posix-seh-rev0/build/gcc-trunk/./gcc/xgcc -B/temp/x64-trunk-snapshot-posix-seh-rev0/build/gcc-trunk/./gcc/ -L/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/lib -L/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/mingw/lib -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/include -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/mingw/include -B/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/bin/ -B/temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/lib/ -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/include -isystem /temp/x64-trunk-snapshot-posix-seh-rev0/prefix/x86_64-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../mingw-sources/gcc-trunk/libquadmath -g -O2 -pipe -fomit-frame-pointer -I/temp/x64-trunk-snapshot-posix-seh-rev0/libs/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -MT math/lgammaq.lo -MD -MP -MF math/.deps/lgammaq.Tpo -c ../../../../../mingw-sources/gcc-trunk/libquadmath/math/lgammaq.c -DDLL_EXPORT -DPIC -o math/.libs/lgammaq.o ../../../../../mingw-sources/gcc-trunk/libquadmath/math/lgammaq.c: In function 'lgammaq': ../../../../../mingw-sources/gcc-trunk/libquadmath/math/lgammaq.c:763:3: error: 'signgam' undeclared (first use in this function) signgam = 1; ^ ../../../../../mingw-sources/gcc-trunk/libquadmath/math/lgammaq.c:763:3: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [math/lgammaq.lo] Error 1 make[3]: Leaving directory `/temp/x64-trunk-snapshot-posix-seh-rev0/build/gcc-trunk/x86_64-w64-mingw32/libquadmath'
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #27 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-07 07:37:05 UTC --- Longer term we do need a fix for this. It is very clear that IRA is allocating odd registers at times for DImode pseudos on 32-bit, and the only reason it works is that things get fixed up later by either reload or the DImode splitters. If we extended define_register_constraint such that extra conditions could be specified, we could get IRA to do the right thing and also have reload fix up the unavoidable cases where we must use odd numbered registers for DImode values on 32-bit such as argument passing. Thanks for the detailed explanation. I'd suggest copying a good chunk of it into constraints.md when you add back the constraint.
[Bug c++/55226] New: [C++11] ICE regression in regard to anonymous unions and constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55226
Bug #: 55226
Summary: [C++11] ICE regression in regard to anonymous unions
and constexpr
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code gives me now a regressive ICE when switching from my
previous gcc 4.8 (last successfully tested: 4.8.0 20121014 (experimental)) to
gcc 4.8.0 20121104 (experimental) using the compiler flags
-Wall -pedantic -std=c++11
//--
templateclass T
struct optional_data
{
union {
unsigned char for_value_init_;
T value_;
};
constexpr optional_data() : for_value_init_() {}
};
struct ncnm
{
ncnm(ncnm) = delete;
ncnm(const ncnm) = delete;
};
int main()
{
optional_datancnm o; // #20
}
//--
In function 'int main()':|
20|internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:3787|
A tentative guess is that this could have been a side-effect of the fix applied
to bug 54922.
