[Bug c++/48586] New: missing no return warning in template operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48586
Summary: missing no return warning in template operator
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp
GCC missing no return warning in template operator that's return type depends
template parameter.
testcase.C
template typename T
T
operator+=( T , int )
{
}
I expect following warning message.
testcase.C: In function 'T operator+=(T, int)':
testcase.C:5:1: warning: no return statement in function returning non-void
[-Wreturn-type]
All of following versions are missing warning.
Ubuntu/Linaro 4.4.4-14ubuntu5
4.5.2
4.5.3 20110324
4.6.0
4.6.1 20110325
4.7.0 20110402
[Bug tree-optimization/48484] [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 07:21:27 UTC --- Fixed.
[Bug tree-optimization/48484] [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 07:22:08 UTC --- *** Bug 48158 has been marked as a duplicate of this bug. ***
[Bug bootstrap/48158] [4.7 Regression] profiledbootstrap failure on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48158 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 07:22:08 UTC --- Fixed by PR48484 fix. *** This bug has been marked as a duplicate of bug 48484 ***
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #20 from Michael Hope michael.hope at linaro dot org 2011-04-13 07:23:49 UTC --- I'm seeing this problem with r172238 on i686. See: http://builds.linaro.org/toolchain/gcc-4.5+svn172238%5Eprofiled/logs/i686-lucid-cbuild109-scorpius-profiled/ 4.6.0 is fine.
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085 --- Comment #21 from Sylvia fierevere at ya dot ru 2011-04-13 07:24:32 UTC --- Sorry, this mail address it not being used anymore, this message has been sent automatically. Извините, этот адрес более не используется, это сообщение было отправлено автоматически.
[Bug c++/48586] missing no return warning in template operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48586 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.13 07:37:23 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-13 07:37:23 UTC --- you get a warning when the template is instantiated, but it would be better to get the warning earlier
[Bug libfortran/48587] New: Avoid exhausting unit number with NEWUNIT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
Summary: Avoid exhausting unit number with NEWUNIT=
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
As was recently pointed out by Tobias Burnus in a thread on comp.lang.fortran,
the current implementation of NEWUNIT= doesn't reuse unit numbers. Hence it's
possible that a program might exhaust the available unit numbers (this requires
that the program repeatedly closes and reopens files, as OS's have limits on
the number of file descriptors a process may have concurrently opened,
typically 1024 or something like that)
Currently there is just a (mutex protected) static variable which is
decremented for each time an OPEN statement with NEWUNIT= is issued, with a
wraparound check that generates an error if wraparound is detected.
IMHO an elegant solution would be to just reuse the kernel provided file
descriptor. E.g.
int fd = open(...);
if (fd == -1)
{
/* Handle error... */
}
new_unit_number = -fd;
This should work because a successful open() will always return a positive fd
number (see
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html ), and
the kernel takes care of reusing file descriptor numbers of closed files.
[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48090 --- Comment #16 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-13 07:41:13 UTC --- Author: ramana Date: Wed Apr 13 07:41:08 2011 New Revision: 172363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172363 Log: Fix PR target/48090 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.md
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13
07:48:13 UTC ---
--- gcc/cp/class.c.jj 2011-03-31 08:50:52.0 +0200
+++ gcc/cp/class.c 2011-04-13 09:41:42.0 +0200
@@ -5827,7 +5827,8 @@ fixed_type_or_null (tree instance, int *
switch (TREE_CODE (instance))
{
case INDIRECT_REF:
- if (POINTER_TYPE_P (TREE_TYPE (instance)))
+ if ((processing_template_decl TREE_TYPE (instance) == NULL_TREE)
+ || POINTER_TYPE_P (TREE_TYPE (instance)))
return NULL_TREE;
else
return RECUR (TREE_OPERAND (instance, 0));
fixes the ICE, but I doubt it is the right fix. I think other dependent
types (e.g. TEMPLATE_TYPE_PARM or TEMPLATE_TEMPLATE_PARM at least) can be
potentially a POINTER_TYPE_P too. On the other side calling dependent_type_p
(TREE_TYPE (instance)) || POINTER_TYPE_P (TREE_TYPE (instance))) here would
return NULL even for dependent types that will certainly not be
POINTER_TYPE_Ps.
[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48090 --- Comment #17 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-13 07:56:00 UTC --- (In reply to comment #15) On Tue, Apr 12, 2011 at 01:53:48PM +, ramana at gcc dot gnu.org wrote: Still need to backport and test on the 4.6 branch. That is next. Small procedural note: it is preferred to go trunk - 4.6 - 4.5, rather than trunk - 4.5 - 4.6, even if the bug is reported against 4.5. Yes I know but it was just a function of what tree I had ready to test and finish at that point of time. Will do it in the right order from next time. I don't have a 4.4 tree handy and this bug should be latent there as well - so if someone wants to backport it please do so but I don't have the time to do it in the next couple of weeks. cheers Ramana
[Bug fortran/48588] New: internal compiler error compiling a library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 Summary: internal compiler error compiling a library Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lega...@gmail.com Created attachment 23971 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23971 source code Compiling a fortran library compiled many other times with other compilers including gfortran 4.4. Here is the command and output. For some reason I can't produce the preprocessed file C:\Documents and Settings\legarra\Mes documents\gs3\zipable\softwaregfortran -v -save-temps -c ALliba ll.f90 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/b rad/gfortran/dependencies --disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32 --ena ble-libgomp --enable-shared --disable-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-l to Thread model: win32 gcc version 4.6.0 20110214 (experimental) [trunk revision 170140] (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=pentium' '-march=pentium' c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/f951.exe ALliball.f90 -quiet -dumpb ase ALliball.f90 -mtune=pentium -march=pentium -auxbase ALliball -version -fintrinsic-modules-path c:/p rogram files/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/finclude -o ALliball.s GNU Fortran (GCC) version 4.6.0 20110214 (experimental) [trunk revision 170140] (i586-pc-mingw32) compiled by GNU C version 4.6.0 20110214 (experimental) [trunk revision 170140], GMP version 4. 3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20110214 (experimental) [trunk revision 170140] (i586-pc-mingw32) compiled by GNU C version 4.6.0 20110214 (experimental) [trunk revision 170140], GMP version 4. 3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ALliball.f90:9521:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #14 from devurandom at gmx dot net 2011-04-13 08:05:35 UTC --- (In reply to comment #13) Fixed on 4.5. Will 4.4 also be fixed? A release candidate for 4.4.6 was just released, so it should probably happen quickly.
[Bug middle-end/48584] [4.7 Regression] AVX testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48584 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.13 08:42:29 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-13 08:42:29 UTC --- I will have a look once I managed to turn on a SB machine.
[Bug target/48519] wrong return-value, with an if () {} after return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48519 --- Comment #10 from Herbert hilmar.ackermann at googlemail dot com 2011-04-13 09:07:04 UTC --- ah ok, thank you very much, this was the bug ;) regards
[Bug libfortran/48589] New: Invalid G0/G0.d editing for NaN/infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589 Summary: Invalid G0/G0.d editing for NaN/infinity Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Created attachment 23972 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23972 Test case For NaN and infinity, the form of the output field for the G0 and G0.d edit descriptors is set to a fixed width of 25, but Fortran 2008 demands: 10.7.5.2.2 3 For an internal value that is an IEEE infinity or NaN, [...] the form of the output field for the G0 and G0.d edit descriptors is the same as for F0.0.
[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-13 10:20:00 UTC --- There is a problem with reusing numbers - it is probably only a small one - but it might be larger than the problem of running out of unit IDs: The user might reuse NEWUNIT= IDs: Open(newunit=id) ... close(id) open(unit=id) ... The latter is illegal as one may only pass positive numbers to unit=, but I would not count on it. Given that the number is huge, we decided that the current method of just incrementing the value should be sufficient for nearly all cases and one can think about something clever if a real-space code encounters the problem. However, I don't mind if one solves the problem before.
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.1 Summary|internal compiler error |[4.6/4.7 Regression] ICE |compiling a library |(segfault) in ||gfc_get_nodesc_array_type --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-13 10:25:37 UTC --- Valgrind shows: ==24723== Invalid read of size 4 ==24723==at 0x5C3338: gfc_get_nodesc_array_type (trans-types.c:1444) ==24723==by 0x5C6DCC: gfc_sym_type (trans-types.c:2009) ==24723==by 0x5C646C: gfc_get_function_type (trans-types.c:2607) ==24723==by 0x584B0C: build_function_decl (trans-decl.c:1775) ==24723==by 0x58: gfc_create_function_decl (trans-decl.c:2340) ==24723==by 0x587B4E: gfc_get_extern_function_decl (trans-decl.c:1582) ==24723==by 0x59C93F: gfc_conv_procedure_call (trans-expr.c:1689) ==24723==by 0x5B8C06: gfc_trans_call (trans-stmt.c:380) The latter is: expr = as-lower[n]; if (expr-expr_type == EXPR_CONSTANT) Thus, it looks as if as-lower[n] == NULL.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug testsuite/48565] libstdc++ testsuite failures when using -pipe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48565 --- Comment #3 from Allan McRae allan at archlinux dot org 2011-04-13 10:35:24 UTC --- So, just to clarify... Is this being seen as something that the person building the gcc test-suite should deal with or something that should be dealt with in the test-suite?
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588
--- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2011-04-13
10:37:29 UTC ---
Confirmed on fairly recent trunk:
GNU Fortran (GCC) 4.7.0 20110404 (experimental)
Reduced testcase:
MODULE LA_PRECISION
IMPLICIT NONE
INTEGER, PARAMETER :: dp = KIND(1.0D0)
END MODULE LA_PRECISION
module lapack90
INTERFACE
SUBROUTINE DGESV_F90( A, B, IPIV, INFO )
USE la_precision, ONLY: wp = dp
IMPLICIT NONE
INTEGER, INTENT(OUT), OPTIONAL :: INFO
INTEGER, INTENT(OUT), OPTIONAL, TARGET :: IPIV(:)
REAL(WP), INTENT(IN OUT) :: A(:,:), B(:,:)
END SUBROUTINE DGESV_F90
END INTERFACE
end module
SUBROUTINE DGESV_F90( A, B, IPIV, INFO )
USE la_precision, ONLY: wp = dp
IMPLICIT NONE
INTEGER, INTENT(OUT), OPTIONAL :: INFO
INTEGER, INTENT(OUT), OPTIONAL, TARGET :: IPIV(:)
REAL(WP), INTENT(IN OUT) :: A(:,:), B(:,:)
END SUBROUTINE DGESV_F90
MODULE DENSEOP
USE LAPACK90
implicit none
integer, parameter :: r8 = SELECTED_REAL_KIND( 15, 307 )
real(r8)::denseop_tol=1.d-50
CONTAINS
SUBROUTINE GEINV8 (x)
real(r8)::x(:,:)
real(r8),allocatable::x_o(:,:)
allocate(x_o(size(x,1),size(x,1)))
CALL dgesv_f90(x,x_o)
x=x_o
END SUBROUTINE GEINV8
END MODULE DENSEOP
!!!
It looks like a AS_DEFERRED vs AS_ASSUMED_SHAPE problem.
Program received signal SIGSEGV, Segmentation fault.
gfc_get_nodesc_array_type (etype=0x8018540a8, as=0x801a0d440,
packed=PACKED_FULL, restricted=1 '\001')
at /home/mik/gcc46/src/gcc/fortran/trans-types.c:1444
1444 if (expr-expr_type == EXPR_CONSTANT)
(gdb) bt
#0 gfc_get_nodesc_array_type (etype=0x8018540a8, as=0x801a0d440,
packed=PACKED_FULL, restricted=1 '\001')
at /home/mik/gcc46/src/gcc/fortran/trans-types.c:1444
#1 0x00580482 in gfc_sym_type (sym=0x801a436c0)
at /home/mik/gcc46/src/gcc/fortran/trans-types.c:2009
#2 0x000801a436c0 in ?? ()
#3 0x000801a90f70 in ?? ()
#4 0x000801a43500 in ?? ()
#5 0x in ?? ()
(gdb) up
#1 0x00580482 in gfc_sym_type (sym=0x801a436c0)
at /home/mik/gcc46/src/gcc/fortran/trans-types.c:2009
2009 type = gfc_get_nodesc_array_type (type, sym-as,
(gdb) p sym.name
$4 = 0x801844f58 a
(gdb) p *sym.as
$5 = {rank = 2, corank = 0, type = AS_DEFERRED, cotype = 0, lower = {0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}, upper = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
cray_pointee = 0 '\0', cp_was_assumed = 0 '\0'}
(gdb) p sym.attr.dummy
$6 = 1
[Bug target/48338] [4.7 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48338 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 10:37:54 UTC --- Seems aio_suspend.c is problematic. Strangely, it segfaults even when aio_suspend.c is built with gcc 4.5 or 4.4, but with -O0 -D__OPTIMIZE__ instead of -O2, so it probably relies on some optimization that is no longer occurring after the FRE changes.
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.13 10:38:26 CC||mikael at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/48576] wrong code when accessing variables in a large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48576 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.13 10:45:15 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-13 10:45:15 UTC --- Confirmed.
[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-04-13 10:46:42 UTC --- (In reply to comment #1) There is a problem with reusing numbers - it is probably only a small one - but it might be larger than the problem of running out of unit IDs: The user might reuse NEWUNIT= IDs: Open(newunit=id) ... close(id) open(unit=id) ... The latter is illegal as one may only pass positive numbers to unit=, but I would not count on it. I don't see how this would differ from the current behavior vs. my suggested implementation. In any case, we check that the UNIT= number is positive when opening units: program negative_unit implicit none open(-10, file=foo.txt) write(-10, *) Hello world close(-10) end program negative_unit $ ./negative_unit At line 3 of file negative_unit.f90 Fortran runtime error: Bad unit number in OPEN statement (this is with 4.4; presumably this restriction hasn't been lifted?) Both the current implementation and my suggested one ensure that any unit number returned in NEWUNIT= is negative. This ensures that the UNIT= and NEWUNIT= number ranges are kept separate from each other, so they shouldn't interact. Given that the number is huge, we decided that the current method of just incrementing the value should be sufficient for nearly all cases and one can think about something clever if a real-space code encounters the problem. Ah, but what about a k-space code? ;) However, I don't mind if one solves the problem before. Yeah, well, I don't think this is a big deal; after all it's pretty unlikely that any program will overflow the counter.
[Bug middle-end/48590] New: Alias analysis confused by builtin-stack-save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48590
Summary: Alias analysis confused by builtin-stack-save/restore
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Lame testcase for now:
float foo (int i, double *d)
{
float f;
double dd;
int j;
dd = *d;
for (j = 0; ji; ++j)
{
float a[i];
f+=a[j] + *d + dd;
}
return f;
}
we fail to CSE *d because we think that __builtin_stack_save () clobbers it.
__builtin_stack_restore () has similar effects on DSE (it appears to use
all aliased memory).
We have to be careful when improving this to not allow sinking operations
on alloca'd memory over a __builtin_stack_restore ().
[Bug middle-end/48590] Alias analysis confused by builtin-stack-save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48590 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.13 11:04:23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-13 11:04:23 UTC --- Mine anyway.
[Bug target/48338] [4.7 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48338 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 11:06:48 UTC --- With gcc 4.6 built aio_suspend.os, it works even with -O0 or -O2 -fno-inline, if __pthread_cleanup_routine has __attribute__((always_inline)). With current trunk, even if that routine is inlined it crashes though.
[Bug middle-end/48590] Alias analysis confused by builtin-stack-save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48590 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-13 11:13:14 UTC --- The following should be safe (but doesn't try to address the dead code elimination issue). Index: gcc/tree-ssa-alias.c === --- gcc/tree-ssa-alias.c(revision 170321) +++ gcc/tree-ssa-alias.c(working copy) @@ -1432,6 +1432,9 @@ call_may_clobber_ref_p_1 (gimple call, a tree ptr = gimple_call_arg (call, 0); return ptr_deref_may_alias_ref_p_1 (ptr, ref); } +case BUILT_IN_STACK_SAVE: +case BUILT_IN_STACK_RESTORE: + return false; case BUILT_IN_GAMMA_R: case BUILT_IN_GAMMAF_R: case BUILT_IN_GAMMAL_R:
[Bug middle-end/48580] missed optimization: integer overflow checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.13 12:11:47 CC||rguenth at gcc dot gnu.org Component|rtl-optimization|middle-end Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-13 12:11:47 UTC --- I too would see it as two pieces, pattern matching on trees to produce a canonical builtin call and RTL expansion of that for optimal target code generation (where I don't know whether we can do better than using UNSPECs). Note that usually you also want to use the result of the multiplication (if it didn't overflow), and using just a single multiplication might be even more complicated (if we need to go the UNSPEC way). For the latter reasons I think the builtins should be sth like __builtin_smul_ovfl_p (multiplication-result, op0, op1), thus pass in the multiplication result and keep the multiplication itself in the IL to also allow for regular optimizations to work on them. If the multiplication is just used as the builtin call argument expansion can get rid of it. The set of builtins with defined behavior is still useful, if not only to allow mixing of wrapv/trapv/... operations in C source. But it isn't exactly the form I'd like the operations to reside in the IL. Pattern-matching the multiplication overflow code can be tricky because of the various ways the handling of zero operands can be implemented. Implementing this entirely on the RTL side seems very tricky to me.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/48591] New: OpenMP ICE with atomics on __float128 in 32-bit only i686 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48591
Summary: OpenMP ICE with atomics on __float128 in 32-bit only
i686 cc1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
extern void abort (void);
int
main ()
{
__float128 f = 0.0;
int i;
#pragma omp parallel for reduction(+:f)
for (i = 0; i 128; i++)
f++;
if (f != 128.0Q)
abort ();
return 0;
}
ICEs with -fopenmp in 32-bit i686-linux cc1 (while works fine with x86_64-linux
cc1 with -fopenmp -m32).
[Bug middle-end/48580] missed optimization: integer overflow checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-13 12:45:35 UTC --- On Wed, 13 Apr 2011, rguenth at gcc dot gnu.org wrote: For the latter reasons I think the builtins should be sth like __builtin_smul_ovfl_p (multiplication-result, op0, op1), thus pass in the multiplication result and keep the multiplication itself in the IL to also allow for regular optimizations to work on them. If the multiplication is just used as the builtin call argument expansion can get rid of it. My inclination is that we probably want to separate the API for users from the built-in functions or other operations used internally - possibly providing a header gccarith.h with a supported API and saying the built-in functions are subject to change and should not be used directly in source code. Maybe (inspired by the style used on C1X stdatomic.h) one could have operations like arith_mul_signed (a, b, 32, ARITH_SAT) that multiplies a and b (integers to infinite precision, producing an infinite precision result), saturates the result to 32-bit signed and returns an implementation-defined type (signed, two's complement, at least 32 bits), or arith_mul_signed_check (a, b, 32, ARITH_WRAP, overflow_p) that stores an overflow flag in the provided _Bool *. Or the overflow handling (wrap, saturate, undefined, unspecified-value, trap) could be part of the macro/function name (putting it as a separate operand is inspired by the memory_order parameters in stdatomic.h). The _check versions with explicit overflow flags could be used with any overflow handling other than undefined behavior. (So if you don't care about what the value is when the overflow flag is set - if you'll just call some error handler - then you'd use unspecified-value as the overflow handling.) On divide by zero, both division and modulo operations would have undefined behavior except for the trap case - but modulo -1 would always be defined, unlike for C INT_MIN % -1 (I'm thinking of these operations as all being defined on their own by producing an infinite precision result first, but there might also be operations such as divmod producing multiple results). It may also make sense to expose different variations of division/modulo (rounding to 0, -infinity or +infinity; a true modulo operation, rounding to -infinity, is one of those things C doesn't make easy; GCC has these as TRUNC_DIV_EXPR, FLOOR_DIV_EXPR, CEIL_DIV_EXPR and corresponding *_MOD_EXPR). Starting with addition then increasing the set of operations gradually probably makes sense. Along with all the arithmetic operations you get range check operations - take a value (in any integer type), and check whether it is in the signed/unsigned range with a given number of bits, wrapping/saturating etc. and setting overflow flags as needed. These are just like the above but with one fewer operands. The explicit number of bits (required to be an integer constant expression) is deliberate because it is sometimes useful e.g. to saturate to 16 bits, but integer promotions in C make it rather fragile to rely on 16-bit operands remaining 16-bit rather than getting implicitly promoted to 32 bits. A consequence is that operations with strange numbers of bits can be written without involving bit-field types (since the result is allowed to have more than the given number of bits). I don't expect those to be very efficient in general, but note that ARM for example has SSAT and USAT instructions to saturate a value to a given number of bits (up to 32) and set a flag if it was out of range.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-04-13 13:05:46 UTC --- It is caused y revision 172257: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00452.html
[Bug middle-end/48591] OpenMP ICE with atomics on __float128 in 32-bit only i686 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48591 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 13:12:19 UTC --- Created attachment 23973 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23973 gcc46-pr48591.patch Untested fix.
[Bug middle-end/48592] New: alloca () calls are not DCEd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48592
Summary: alloca () calls are not DCEd
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
We should DCE alloca () calls. Testcase:
void foo (int i)
{
int a[i];
}
[Bug middle-end/48592] alloca () calls are not DCEd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48592 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Last reconfirmed||2011.04.13 13:25:42 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-13 13:25:42 UTC --- Very simple, mine.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.13 13:39:18 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-13 13:39:18 UTC --- Confirmed. Let me have a look.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #8 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-13 13:43:41 UTC --- Candidate patch proposed at http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00985.html
[Bug c/48561] internal compiler error: in change_address_1, at emit-rtl.c:1954
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48561 --- Comment #2 from Brian Davis brian.davis at eclipseoptions dot com 2011-04-13 14:26:46 UTC --- Created attachment 23974 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23974 preprocessed source
[Bug c/48561] internal compiler error: in change_address_1, at emit-rtl.c:1954
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48561 --- Comment #3 from Brian Davis brian.davis at eclipseoptions dot com 2011-04-13 14:28:15 UTC --- Not sure why it didn't get attached before, but perhaps I uncompressed it on my local file system after setting the path but before submitting the bug and didn't check the results carefully. Anyway, now attached.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-13
14:55:48 UTC ---
Compilation segfaults in LTRANS stage on line 1738 in tree-inline.c
(the assert below) because the dereferenced dest is zero.
/* Constant propagation on argument done during inlining
may create new direct call. Produce an edge for it. */
if ((!edge
|| (edge-indirect_inlining_edge
id-transform_call_graph_edges == CB_CGE_MOVE_CLONES))
(fn = gimple_call_fndecl (stmt)) != NULL)
{
struct cgraph_node *dest = cgraph_get_node (fn);
/* We have missing edge in the callgraph. This can happen
when previous inlining turned an indirect call into a
direct call by constant propagating arguments or we are
producing dead clone (for further cloning). In all
other cases we hit a bug (incorrect node sharing is the
most common reason for missing edges). */
gcc_assert (dest-needed || !dest-analyzed
|| dest-address_taken
|| !id-src_node-analyzed
|| !id-dst_node-analyzed);
fn is function_decl 0x765d3300 __comp_dtor
id-transform_call_graph_edges is CB_CGE_MOVE_CLONES
calling cgraph_edge (id-dst_node, stmt) from within the debugger
(to get edge which it says is optimized out) returns NULL.
I'd rather avoid calling cgraph_get_create_node here, the node should
be created by whatever inserts it into the IL. Let me check whether
the bug goes away if I disable IPA-CP first.
[Bug testsuite/48565] libstdc++ testsuite failures when using -pipe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48565 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-13 15:09:36 UTC --- It shouldn't happen unless the person running the testsuite specifies it, so they can not specify it. How did you configure the library to hit this problem? Jakub's suggestion is that the testsuite could filter it out, so that even when users do specify it, the testsuite doesn't use it.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #9 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-13 15:09:29 UTC --- Author: dodji Date: Wed Apr 13 15:09:26 2011 New Revision: 172375 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172375 Log: Fix PR c++/48574 gcc/cp/ * class.c (fixed_type_or_null): We cannot determine the dynamic type of a reference variable if its initializer is dependent. gcc/testsuite/ * g++.dg/template/dependent-expr7.C: New test case. Added: trunk/gcc/testsuite/g++.dg/template/dependent-expr7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #10 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-13 15:12:21 UTC --- Fixed in 4.7 (trunk)
[Bug testsuite/48565] libstdc++ testsuite failures when using -pipe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48565 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-13 15:12:31 UTC --- (In reply to comment #4) How did you configure the library to hit this problem? I know you said with -pipe in your CFLAGS, is that all? You could probably edit scripts/testsuite_flags to remove -pipe as a workaround
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #11 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-13 15:19:42 UTC --- Author: dodji Date: Wed Apr 13 15:19:40 2011 New Revision: 172376 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172376 Log: Fix PR c++/48574 gcc/cp/ * class.c (fixed_type_or_null): We cannot determine the dynamic type of a reference variable if its initializer is dependent. gcc/testsuite/ * g++.dg/template/dependent-expr7.C: New test case. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/dependent-expr7.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/class.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-13 15:21:01 UTC --- Fixed in 4.6.1
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 --- Comment #6 from Vladimir Makarov vmakarov at redhat dot com 2011-04-13 15:21:23 UTC --- I found one problem with reg equivalences. They were just ignored. It is a result of bad merging the big IRA patch and changes in IRA for last half year. I found the problem solution improves the code size (at least for -O2). I'll send the patch today. But I guess it does not solve all the code size degradation. Therefore I continue my work on the PR. Thanks for the small tests, Richard. It saved a lot of my time.
[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:38:53 UTC --- Author: jakub Date: Wed Apr 13 15:38:50 2011 New Revision: 172377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172377 Log: PR c++/48570 * semantics.c (cxx_eval_array_reference): Handle reading from wchar_t, char16_t and char32_t STRING_CST. * g++.dg/cpp0x/constexpr-wstring1.C: New test. * g++.dg/cpp0x/constexpr-wstring2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-13 15:38:56 UTC --- And indeed it does. Therefore I believe we should add it to the referenced set of a clone in the WPA stage...?
[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:47:44 UTC --- Author: jakub Date: Wed Apr 13 15:47:40 2011 New Revision: 172378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172378 Log: PR c++/48570 * semantics.c (cxx_eval_array_reference): Handle reading from wchar_t, char16_t and char32_t STRING_CST. * g++.dg/cpp0x/constexpr-wstring1.C: New test. * g++.dg/cpp0x/constexpr-wstring2.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/48591] OpenMP ICE with atomics on __float128 in 32-bit only i686 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48591 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:50:12 UTC --- Author: jakub Date: Wed Apr 13 15:50:02 2011 New Revision: 172379 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172379 Log: PR middle-end/48591 * omp-low.c (expand_omp_atomic_fetch_op): Return false if decl is NULL. (expand_omp_atomic_pipeline): Return false if cmpxchg is NULL. * gcc.dg/gomp/pr48591.c: New test. * testsuite/libgomp.c/pr48591.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr48591.c trunk/libgomp/testsuite/libgomp.c/pr48591.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog
[Bug middle-end/48591] OpenMP ICE with atomics on __float128 in 32-bit only i686 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48591 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:52:22 UTC --- Author: jakub Date: Wed Apr 13 15:52:17 2011 New Revision: 172381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172381 Log: PR middle-end/48591 * omp-low.c (expand_omp_atomic_fetch_op): Return false if decl is NULL. (expand_omp_atomic_pipeline): Return false if cmpxchg is NULL. * gcc.dg/gomp/pr48591.c: New test. * testsuite/libgomp.c/pr48591.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/gomp/pr48591.c branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr48591.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/omp-low.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/libgomp/ChangeLog
[Bug regression/48570] [4.6/4.7 Regression] wrong subscription with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|gcc-4.6: wrong subscription |[4.6/4.7 Regression] wrong |with -std=c++0x |subscription with ||-std=c++0x --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:58:46 UTC --- Fixed.
[Bug middle-end/48591] OpenMP ICE with atomics on __float128 in 32-bit only i686 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48591 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-13 15:59:18 UTC --- Fixed for 4.6+.
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 --- Comment #12 from gjl at gcc dot gnu.org 2011-04-13 16:36:57 UTC --- Author: gjl Date: Wed Apr 13 16:36:50 2011 New Revision: 172384 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172384 Log: PR target/45263 * config/avr/libgcc.S (__do_global_ctors, __do_global_dtors): Save R20 around calls of __tablejump_elpm__ Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/libgcc.S
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 --- Comment #13 from gjl at gcc dot gnu.org 2011-04-13 16:46:32 UTC --- Author: gjl Date: Wed Apr 13 16:46:29 2011 New Revision: 172385 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172385 Log: Fix ChangeLog entry for PR target/45263 Modified: trunk/gcc/ChangeLog
[Bug c++/48581] [C++0x][SFINAE] Lack of ADL in default template argument types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48581 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-13 17:00:58 UTC --- Fixed for 4.7.
[Bug middle-end/48580] missed optimization: integer overflow checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Steven Fuerst svfuerst at gmail dot com changed: What|Removed |Added CC||svfuerst at gmail dot com --- Comment #10 from Steven Fuerst svfuerst at gmail dot com 2011-04-13 17:44:22 UTC --- There are C and x86 assembly code fragments showing how to do signed and unsigned saturating arithmetic here: http://locklessinc.com/articles/sat_arithmetic/ Although, if there were new intrinsics that allowed direct access to the overflow and carry flags from arithmetic instructions, they would be quite useful.
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org 2011-04-13 18:26:55 UTC --- Author: vmakarov Date: Wed Apr 13 18:26:52 2011 New Revision: 172389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172389 Log: 2011-04-13 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/48455 * ira-costs.c (find_costs_and_classes): Use i_mem_cost instead of `temp_costs-mem_cost'. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug c++/48593] New: Wrong return type when applying address operator to inherited, template dependend member, using a typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48593
Summary: Wrong return type when applying address operator to
inherited, template dependend member, using a typedef
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meinh...@uni-mainz.de
The following code should compile but does not. It works on any other compiler
I tried (Comeau, Intel and MSVC). It seems the espression (Super::data) is
interpreted as a pointer-to-data-member. This interpretation cannot be correct,
because the braces would not be legal in that kind of expression.
A possible workaround is using (this-data) instead.
Works as expected if done without templates.
Code:
template typename T struct foo
{
T data;
};
templatetypename T struct bar: public fooT
{
typedef fooT Super;
void some_func()
{
T* ptr = (Super::data);
}
};
int main()
{
barint b;
b.some_func();
}
Output:
$ g++ -v -Wall -Wextra test.cc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -quiet -v -D_GNU_SOURCE test.cc
-D_FORTIFY_SOURCE=2 -quiet -dumpbase test.cc -mtune=generic -auxbase test -Wall
-Wextra -version -fstack-protector -o /tmp/ccqnK7Ea.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 88858f45841827736473e527a4e9ab10
test.cc: In member function ‘void barT::some_func() [with T = int]’:
test.cc:18: instantiated from here
test.cc:11: error: cannot convert ‘int fooint::*’ to ‘int*’ in initialization
test.cc:11: warning: unused variable ‘ptr’
[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48456 --- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2011-04-13 18:38:21 UTC --- Author: pault Date: Wed Apr 13 18:38:17 2011 New Revision: 172390 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172390 Log: 2011-04-13 Paul Thomas pa...@gcc.gnu.org PR fortran/48360 PR fortran/48456 * trans-array.c (get_std_lbound): For derived type variables return array valued component lbound. 2011-04-13 Paul Thomas pa...@gcc.gnu.org PR fortran/48360 PR fortran/48456 * gfortran.dg/realloc_on_assign_6.f03: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_6.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-array.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/48360] [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48360 --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2011-04-13 18:38:21 UTC --- Author: pault Date: Wed Apr 13 18:38:17 2011 New Revision: 172390 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172390 Log: 2011-04-13 Paul Thomas pa...@gcc.gnu.org PR fortran/48360 PR fortran/48456 * trans-array.c (get_std_lbound): For derived type variables return array valued component lbound. 2011-04-13 Paul Thomas pa...@gcc.gnu.org PR fortran/48360 PR fortran/48456 * gfortran.dg/realloc_on_assign_6.f03: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_6.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-array.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #53 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-13 18:47:24 UTC --- reduced testcase for 4.7 MODULE M1 INTEGER, PARAMETER :: dp=8 TYPE realspace_grid_type REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r END TYPE realspace_grid_type TYPE realspace_grid_p_type TYPE(realspace_grid_type), POINTER :: rs_grid END TYPE realspace_grid_p_type TYPE realspaces_grid_p_type TYPE(realspace_grid_p_type), DIMENSION(:), POINTER :: rs END TYPE realspaces_grid_p_type END MODULE MODULE M2 USE M1 CONTAINS SUBROUTINE S1() INTEGER :: i,j TYPE(realspaces_grid_p_type), DIMENSION(:), POINTER :: rs_gauge REAL(dp), DIMENSION(:, :, :), POINTER:: y y=rs_gauge(i)%rs(j)%rs_grid%r END SUBROUTINE END MODULE USE M2 CALL S1() END gfortran -O0 -flto test.f90 In file included from :0:0: test.f90: In function ‘s1’: test.f90:17:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) y = D.2087_27-r; test.f90:17:0: internal compiler error: verify_gimple failed
[Bug libgcj/48533] Installer fails on libjava component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48533 --- Comment #1 from John T jrt at worldlinc dot net 2011-04-13 18:53:29 UTC --- On building all components of GCC 4.6.0 except java, ada and go, there was no problem installing with the prefix for 4.6.0 set to /usr/local. The problem seems confined to the java files for 4.6.0. I haven't tried installing any other version of gcc java to /usr/local.
[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-13 18:58:47 UTC --- If someone overflows the counter I think they should get what they deserve. ;) I suppose one could put an OPEN .. CLOSE in a DO LOOP and see what happens now. It might take a while to get there. IIRC when I implemented this I set the limit small and tested an error check for this, but maybe I am wrong.
[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-13 19:00:44 UTC --- OK , I will have a look, thanks.
[Bug fortran/48360] [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48360 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2011-04-13 19:20:12 UTC --- Fixed on trunk and 4.6. Thanks for the report Paul
[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48456 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2011-04-13 19:21:01 UTC --- Fixed on trunk and 4.6. Thanks for the report Paul
[Bug c++/48594] New: [4.3/4.4/4.5/4.6/4.7] Rejects valid with pointer-to-member in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
Summary: [4.3/4.4/4.5/4.6/4.7] Rejects valid with
pointer-to-member in template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org
https://bugzilla.redhat.com/show_bug.cgi?id=695567
struct A { } a;
typedef void (*pfn)();
pfn operator-* (A, int);
template class T
void f()
{
(a-*1)();
}
used to be accepted in 3.2/3.3, 3.4 and above errors out. Or:
#include vector
#include boost/spirit/include/phoenix.hpp
namespace ph = boost::phoenix;
struct Triangle {};
extern ph::actorph::valuestd::vectorTriangle * vp;
#ifndef WORKS
templatetypename T
#endif
void foo ()
{
void (std::vectorTriangle::*const p)(const Triangle)
= std::vectorTriangle::push_back;
Triangle tria1;
(vp-*p)(tria1);
}
#ifndef WORKS
void bar ()
{
fooint ();
}
#endif
(preprocessed source in https://bugzilla.redhat.com/attachment.cgi?id=491460 )
errors out similarly, with different error, if not in template, it is accepted.
[Bug target/48595] New: score-elf fails to build with --enable-werror-always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595 Summary: score-elf fails to build with --enable-werror-always Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: li...@gcc.gnu.org Blocks: 44756 Target: score-elf gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I.. -I. -Iada -I../../../gcc/gcc -I../../../gcc/gcc/ada -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../gcc/gcc/ada/gcc-interface/targtyps.c -o ada/targtyps.o In file included from ./tm_p.h:5:0, from ../../../gcc/gcc/ada/gcc-interface/targtyps.c:33: ./tm-preds.h:69:0: error: CONSTRAINT_LEN redefined [-Werror] ../../../gcc/gcc/defaults.h:956:0: note: this is the location of the previous definition ./tm-preds.h:72:0: error: REG_CLASS_FROM_CONSTRAINT redefined [-Werror] ../../../gcc/gcc/defaults.h:969:0: note: this is the location of the previous definition ./tm-preds.h:86:0: error: EXTRA_MEMORY_CONSTRAINT redefined [-Werror] ../../../gcc/gcc/defaults.h:940:0: note: this is the location of the previous definition ./tm-preds.h:88:0: error: EXTRA_ADDRESS_CONSTRAINT redefined [-Werror] ../../../gcc/gcc/defaults.h:946:0: note: this is the location of the previous definition cc1: all warnings being treated as errors make[2]: *** [ada/targtyps.o] Error 1 make[2]: *** Waiting for unfinished jobs score has a constraints.md, yet defines REG_CLASS_FROM_LETTER.
[Bug c++/48594] [4.3/4.4/4.5/4.6/4.7] Rejects valid with pointer-to-member in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-13 20:50:29 UTC --- Author: jason Date: Wed Apr 13 20:50:26 2011 New Revision: 172394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172394 Log: PR c++/48594 * decl2.c (build_offset_ref_call_from_tree): Fix calling a functor or pointer to (non-member) function. Added: trunk/gcc/testsuite/g++.dg/template/operator11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48594] [4.3/4.4/4.5/4.6/4.7] Rejects valid with pointer-to-member in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-13 20:51:26 UTC --- Author: jason Date: Wed Apr 13 20:51:23 2011 New Revision: 172395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172395 Log: PR c++/48594 * decl2.c (build_offset_ref_call_from_tree): Fix calling a functor or pointer to (non-member) function. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/operator11.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl2.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/48495] ICE in in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48495 --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org 2011-04-13 22:13:05 UTC --- Pat, I tried recreating the ICE, but can't with either trunk (r172389) or the FSF 4.6 branch (r172395). What revision and configure options did you use?
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2011-04-13 22:37:02 UTC --- Author: danglin Date: Wed Apr 13 22:36:59 2011 New Revision: 172400 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172400 Log: Backport from mainline: 2011-04-08 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/48366 * config/pa/pa.c (hppa_register_move_cost): Increase to 18 cost of move from floating point to shift amount register . (emit_move_sequence): Remove secondary reload support for floating point to shift amount amount register copies. (pa_secondary_reload): Return GENERAL_REGS for floating point/shift amount register copies. * config/pa/pa32-regs.h (HARD_REGNO_MODE_OK): For shift amount register, return false if mode isn't a scalar integer mode. * config/pa/pa64-regs.h (HARD_REGNO_MODE_OK): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa.c branches/gcc-4_6-branch/gcc/config/pa/pa32-regs.h branches/gcc-4_6-branch/gcc/config/pa/pa64-regs.h
[Bug rtl-optimization/48596] New: [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596
Summary: [4.7 Regression] [SH] unable to find a register to
spill in class 'FPUL_REGS'
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org
Created attachment 23975
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23975
A test case
The attached testcase causes a spill failure with -O1 -m4 -ml:
foo.c: In function 'foo':
foo.c:27:1: error: unable to find a register to spill in class 'FPUL_REGS'
foo.c:27:1: error: this is the insn:
(insn 105 104 106 8 (parallel [
(set (reg:SI 264)
(fix:SI (reg:DF 66 fr2 [262])))
(use (reg/v:PSI 151 ))
]) foo.c:22 357 {fix_truncdfsi2_i}
(expr_list:REG_DEAD (reg:DF 66 fr2 [262])
(expr_list:REG_DEAD (reg/v:PSI 151 )
(expr_list:REG_EQUIV (mem:SI (reg/f:SI 78 fr14 [orig:242 D.2027 ]
[242]) [0 MEM[(struct Info *)D.2027_55]+0 S4 A32])
(nil)
foo.c:27:1: internal compiler error: in spill_failure, at reload1.c:2113
for sh-elf target.
[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||sh-*-* Known to work||4.6.0 Known to fail||4.7.0 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-04-13 22:47:25 UTC --- It started to fail between revisions 171582 and 171649. .ira dump says Spilling for insn 105. Using reg 150 for reload 0 reload failure for reload 3 Reloads for insn # 105 Reload 0: FPUL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine, secondary_reload_p Reload 1: reload_in (SI) = (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242]) GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0) reload_in_reg: (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242]) secondary_in_reload = 0 Reload 2: GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine, secondary_reload_p Reload 3: reload_out (SI) = (mem:SI (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242]) [0 MEM[(struct Info *)D.2027_55]+0 S4 A32]) FPUL_REGS, RELOAD_FOR_OUTPUT (opnum = 0) reload_out_reg: (reg:SI 264) secondary_out_reload = 2 It looks odd to choose floating point register fr14 for a memory address.
[Bug libstdc++/48526] [C++0x] std::is_constructiblevoid, Args...::value shall be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48526 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-04-13 22:52:48 UTC --- Author: paolo Date: Wed Apr 13 22:52:45 2011 New Revision: 172401 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172401 Log: 2011-04-13 Daniel Krugler daniel.krueg...@googlemail.com Paolo Carlini paolo.carl...@oracle.com PR libstdc++/48526 * include/std/type_traits (struct is_constructible): Re-implement, according to n3290. (struct is_default_constructible): Add. (struct is_destructible): Likewise. (struct __and_, __or_, __not_): Add and use throughout; reorder some facilities, other minor tweaks. * testsuite/util/testsuite_tr1.h: Add test types. * testsuite/20_util/is_constructible/value-2.cc: New. * testsuite/20_util/is_default_constructible/value.cc: Likewise. * testsuite/20_util/is_default_constructible/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_default_constructible/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_destructible/value.cc: Likewise. * testsuite/20_util/is_destructible/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_destructible/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust dg-error line numbers. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Likewise. * testsuite/20_util/ratio/cons/cons_overflow_neg.cc: Likewise. 2011-04-13 Paolo Carlini paolo.carl...@oracle.com * testsuite/20_util/is_function/value.cc: Add, adapted from the tr testsuite. * testsuite/20_util/is_function/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_function/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_function/24808.cc: Likewise. * testsuite/20_util/is_function/35637.cc: Likewise. * testsuite/20_util/is_object/value.cc: Likewise. * testsuite/20_util/is_object/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_object/requirements/explicit_instantiation.cc: : Likewise. * testsuite/20_util/is_object/24808.cc: Likewise. * testsuite/20_util/is_compound/value.cc: Likewise. * testsuite/20_util/is_compound/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_compound/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_member_object_pointer/value.cc: Likewise. * testsuite/20_util/is_member_object_pointer/requirements/ typedefs.cc: Likewise. * testsuite/20_util/is_member_object_pointer/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_fundamental/value.cc: Likewise. * testsuite/20_util/is_fundamental/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_fundamental/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_member_pointer/value.cc: Likewise. * testsuite/20_util/is_member_pointer/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_member_pointer/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_member_function_pointer/value.cc: Likewise. * testsuite/20_util/is_member_function_pointer/ requirements/typedefs.cc: Likewise. * testsuite/20_util/is_member_function_pointer/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/is_convertible/value.cc: Minor tweak, adjust Copyright years. Added: trunk/libstdc++-v3/testsuite/20_util/is_compound/ trunk/libstdc++-v3/testsuite/20_util/is_compound/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_compound/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_compound/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_compound/value.cc trunk/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/ trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc trunk/libstdc++-v3/testsuite/20_util/is_destructible/ trunk/libstdc++-v3/testsuite/20_util/is_destructible/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_destructible/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_destructible/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_destructible/value.cc trunk/libstdc++-v3/testsuite/20_util/is_function/ trunk/libstdc++-v3/testsuite/20_util/is_function/24808.cc
[Bug libstdc++/48526] [C++0x] std::is_constructiblevoid, Args...::value shall be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48526 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-13 22:54:11 UTC --- Fixed for 4.7.0.
[Bug c/48597] New: x86-64 unwind register save location misses half-register write?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597
Summary: x86-64 unwind register save location misses
half-register write?
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@cern.ch
On RHEL6 x86-64, GCC compiled libm has inaccurate unwind info for
__ieee754_rem_pio2f() as called by tanf(). The problem is GCC knows %rbp is
saved, and correctly describes the save location, but delays emitting the info
from actual register save to a later address, missing write to half-size
register alias %ebp in between. If unwinding starts in the in-between region,
%rbp is not restored correctly off the stack, leading to problems later in a
stack frame with CFA defined as offset off %rbp.
The start of assembly and unwind info for __ieee754_rem_pio2f follows.
Dump of assembler code for function __ieee754_rem_pio2f:
0x735b1080 +0: push %rbp
0x735b1081 +1: movd %xmm0,%ebp
0x735b1085 +5: push %rbx
0x735b1086 +6: mov%ebp,%ecx
0x735b1088 +8: mov%rdi,%rbx
0x735b108b +11: and$0x7fff,%ecx
0x735b1091 +17: sub$0x18,%rsp
1d30 003c 1d34 FDE cie= pc=0002c080..0002c3ba
DW_CFA_advance_loc: 1 to 0002c081
DW_CFA_def_cfa_offset: 16
DW_CFA_advance_loc: 5 to 0002c086
DW_CFA_def_cfa_offset: 24
DW_CFA_advance_loc: 5 to 0002c08b
DW_CFA_offset: r3 (rbx) at cfa-24
DW_CFA_offset: r6 (rbp) at cfa-16
As you can see at 0x2c081 / 0x735b1081 a movd %xmm0, %ebp instruction
writes to %rbp, but the unwind info describes the save location for the
register only at 0x2c08b / 0x735b108b.
It's easiest to demo the effect in GDB; the original problem occurred in a
sampling profiler which uses libunwind. See (1) for the full GDB session trace.
To replicate this, you need a) a call to tanf() with an argument requiring
__ieee754_rem_pio2f() call, b) a function above tanf() with CFA based on %rbp
(SimpleNavigableLayer::wellInside() in (1)), and c) a stack walk within the
three instructions with inaccurate unwind info.
RHEL6 glibc seems to be built with GCC 4.4.4 (2). The entire libm has just four
instances of 'movd %xmmN,%ebp', in __ieee754_asinf, __ieee754_j1f,
__ieee754_lgammaf_r, __ieee754_rem_pio2f; all with the same unwind info issue.
In GLIBC 2.13 compiled with GCC 4.6.x pre-release (3), the first three still
have a 'vmovd %xmmN,%ebp', plus there's one in cprojf, but none in
__ieee754_rem_pio2f. Of these only __ieee754_lgammaf_r is incorrect (4), all
others have correct unwind info - though I am not sure if they are just
'different' rather than 'fixed', see how __ieee754_rem_pio2f changed in (5).
If there is easy enough a fix, we have some interest in back-port to 4.4.x in
case we have any luck convincing RHEL to pick up the patch and rebuild
libc/libm.
(1)
$ gdb --args cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun...(no
debugging symbols found)...done.
(gdb) b __ieee754_rem_pio2f
Function __ieee754_rem_pio2f not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__ieee754_rem_pio2f) pending.
(gdb) b 'SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const'
Function SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 ('SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const') pending.
(gdb) disa 1
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just end.
ena 1
cont
end
(gdb) r
Starting program: /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
[Thread debugging using libthread_db enabled]
14-Apr-2011 01:22:27 CEST Initiating request to open file
file:0E1B7BC9-7E2C-E011-A37B-0018F3D096B6.root
14-Apr-2011 01:22:29 CEST Successfully opened file
[Bug target/48598] New: x86 backend fails to properly mark memory alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48598
Summary: x86 backend fails to properly mark memory alignment
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 pr1000]$ cat p.i
extern const unsigned char __popcount_tab[256];
int
__popcountdi2 (unsigned long long x)
{
int i, ret = 0;
for (i = 0; i (8 * 8); i += 8)
ret += __popcount_tab[(x i) 0xff];
return ret;
}
[hjl@gnu-6 pr1000]$ gcc -O2 -fPIC p.i -S -da
(insn 19 18 20 (set (reg/f:DI 108)
(mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref:DI (__popcount_tab) [flags 0x40]
var_dec
l 0x7210e000 __popcount_tab)
] UNSPEC_GOTPCREL)) [2 S8 A8])) p.i:8 -1
(nil))
__popcount_tab should be marked with 64bit alignment.
[Bug c++/48599] New: [C++0x] no diagnostic for invalid use of auto with array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48599 Summary: [C++0x] no diagnostic for invalid use of auto with array declarator Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hst...@ca.ibm.com Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu A program is ill-formed if an array declarator is used to declare an entity whose type contains the auto type specifier. A diagnostic is expected. See subclause 8.3.4 [dcl.array] paragraph 1 in the 2011 FDIS. ### Self-contained source (a.cpp): int v[1]; auto (*p)[1] = v; ### Command to reproduce: g++ -std=c++0x -Wall -W -pedantic -c a.cpp -o a.o ### Compiler output: (No messages; return code 0) ### g++ -v output: Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../gcc-4.5.0/configure --prefix=/data/gcc --program-suffix=-4.5.0 --disable-libssp --disable-libgcj --enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 (GCC)
[Bug middle-end/48600] New: [4.6 regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 Summary: [4.6 regression] ICE when using cold attribute Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Compiling the attached file at -O1 or above yields a stack overflow: g++ -O1 ci.cpp g++: internal compiler error: Segmentation fault (program cc1plus) valgrind says: ==7379== Stack overflow in thread 1: can't grow stack to 0x7fe801ff8 ==7379== Can't extend stack to 0x7fe801410 during signal delivery for thread 1: ==7379== no stack segment ==7379== ==7379== Process terminating with default action of signal 11 (SIGSEGV) ==7379== Access not within mapped region at address 0x7FE801410 ==7379==at 0x89E8D5: ??? (in /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.6.0/cc1plus) ==7379== If you believe this happened as a result of a stack ==7379== overflow in your program's main thread (unlikely but ==7379== possible), you can try to increase the size of the ==7379== main thread stack using the --main-stacksize= flag. ==7379== The main thread stack size used in this run was 8388608. ==7379== Stack overflow in thread 1: can't grow stack to 0x7fe801f70 If you remove the cold attribute from Arch::Debugger_entry(), the ICE (and explosive memory consumption) goes away. Tested with 4.6.0 RC, final, and another 4.6 variant. They all have the same problem. Testing with 4.5.2 and 4.4.4 shows no such problem.
[Bug target/45373] V850 increment loops compile into incorrect assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45373 Alex Marshall trap15 at raidenii dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Alex Marshall trap15 at raidenii dot net 2011-04-14 03:30:09 UTC --- I have just come back to this, and it appears that the correct code was being generated in the first place. I must have misread the datasheet or something. In any case, this is now resolved.
