[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #18 from t dot artem at mailcity dot com 2007-05-18 08:32 --- As for GCC 4.2.0 the bug is still relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug fortran/31716] segfault with real array bounds
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-05-18 08:50 --- Jerry, the patch eliminates the ICE and regtests cleanly. $> cat pr31716.f90 program main real, parameter :: n = 1024, iter=1000 real, dimension(n) :: num1,num2 call random_number(num1) do i=1,iter num2 = num1**2 end do end program main $> gfortran-svn -Wall pr31760.f90 pr31760.f90:3.18: real, dimension(n) :: num1,num2 1 Error: Expression at (1) must be of INTEGER type pr31760.f90:3.33: real, dimension(n) :: num1,num2 1 Error: The module or main program array 'num2' at (1) must have constant shape pr31760.f90:3.18: real, dimension(n) :: num1,num2 1 Error: Expression at (1) must be of INTEGER type pr31760.f90:3.28: real, dimension(n) :: num1,num2 1 Error: The module or main program array 'num1' at (1) must have constant shape The messages "must have constant shape" puzzles me as N is a PARAMETER?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug fortran/31716] segfault with real array bounds
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-05-18 08:53 --- > $> gfortran-svn -Wall pr31760.f90 This should of course read "gfortran-svn -Wall pr31716.f90" - the contents of the file does correspond to this PR, the file name does not ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug c++/31970] g++ compiles incorrect c++ code
--- Comment #2 from asp_ at mail dot ru 2007-05-18 08:56 --- Have you received correct link? http://mx1.ru/~asp/super_example.cpp Also I've sent email with file attached. Did you receive it? (In reply to comment #1) > The link you give doesn't work. Can you attach your testcase? > W. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
[Bug middle-end/31344] [4.3 Regression] bootstrap broken on i[345]86-linux
--- Comment #25 from ubizjak at gmail dot com 2007-05-18 09:48 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2007- |patches/2007- |05/msg00390.html|05/msg01192.html Status|ASSIGNED|RESOLVED Component|rtl-optimization|middle-end Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug rtl-optimization/31344] [4.3 Regression] bootstrap broken on i[345]86-linux
--- Comment #23 from uros at gcc dot gnu dot org 2007-05-18 09:37 --- Subject: Bug 31344 Author: uros Date: Fri May 18 08:37:03 2007 New Revision: 124825 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124825 Log: PR rtl-optimization/31344 * expr.c (emit_move_change_mode): Change mode of push operands here. testsuite/ChangeLog: PR rtl-optimization/31344 * gcc.dg/pr31344.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr31344.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #81 from rguenth at gcc dot gnu dot org 2007-05-18 09:45 --- Yes, both testcases are valid and are using placement new. Note the loop is only to confuse the optimizers enough to re-order the stores and produce a miscompilation. Note the loop runs exactly once, and in essence we are doing int *p = XXX; /* integer memory */ *p = 0; long *q = new (p) long; *q = -1; and the compiler is re-ordering the stores which is wrong. *p and *q need to alias because of the placement new. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug rtl-optimization/31344] [4.3 Regression] bootstrap broken on i[345]86-linux
--- Comment #24 from uros at gcc dot gnu dot org 2007-05-18 09:46 --- Subject: Bug 31344 Author: uros Date: Fri May 18 08:46:30 2007 New Revision: 124826 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124826 Log: * PR rtl-optimization/31344 is actually middle-end bug. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #82 from rguenth at gcc dot gnu dot org 2007-05-18 09:47 --- Oh, and the double-ness is to show that at RTL expansion we actually unify alias sets of long and double, not long and int, which is wrong again. See my comment #51. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/31984] Infinite loop (eating all mem) compiling xorg 1.3.0.0
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-18 10:14 --- *** This bug has been marked as a duplicate of 30052 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31984
[Bug target/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-18 10:14 --- *** Bug 31984 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||m dot vegni at it-systems ||dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-05-18 11:06 --- The testcase of comment #8 does not segfault on mainline (20070517) any more, but still does in the 4.2 branch. Messages for mainline (note the empty names in "Error: '' at (1) is not a function"): $> gfortran-svn -g -Wall -c pr18923.f90 pr18923.f90:3.16: subroutine FOO 1 Error: MODULE attribute conflicts with PROCEDURE attribute at (1) pr18923.f90:4.16: integer :: I 1 Error: Unexpected data declaration statement in CONTAINS section at (1) pr18923.f90:5.56: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: Unexpected data declaration statement in CONTAINS section at (1) pr18923.f90:6.5: end subroutine 1 Error: Expecting END MODULE statement at (1) pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: '' at (1) is not a function pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: '' at (1) is not a function pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: '' at (1) is not a function pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: '' at (1) is not a function pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: '' at (1) is not a function pr18923.f90:5.18: character(len=selected_int_kind(I)) :: C, D, E, F, G 1 Error: Expression at (1) must be of INTEGER type Backtrace for 4.2: Program received signal SIGSEGV, Segmentation fault. gfc_resolve_expr (e=0x8612478) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:1751 1751expr->ts = expr->symtree->n.sym->result->ts; (gdb) bt #0 gfc_resolve_expr (e=0x8612478) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:1751 #1 0x08092ade in resolve_index_expr (e=0x8611160) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:5362 #2 0x08092bfb in resolve_charlen (cl=) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:5386 #3 0x0809311f in resolve_types (ns=0x86119c0) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7255 #4 0x080930a7 in resolve_types (ns=0x8610a20) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7248 #5 0x08095e2c in gfc_resolve (ns=0x8610a20) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7311 #6 0x0808a309 in gfc_parse_file () at /home/daniel/svn/gcc-4.2/gcc/fortran/parse.c:3222 #7 0x080ac02d in gfc_be_parse_file (set_yydebug=0) at /home/daniel/svn/gcc-4.2/gcc/fortran/f95-lang.c:303 #8 0x08310faa in toplev_main (argc=2, argv=0xbf87ea84) at /home/daniel/svn/gcc-4.2/gcc/toplev.c:1033 #9 0x080d893f in main (argc=2, argv=0x1) at /home/daniel/svn/gcc-4.2/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug libstdc++/31970] g++ compiles incorrect c++ code
--- Comment #5 from pcarlini at suse dot de 2007-05-18 11:45 --- Note that this is only a Quality of Implementation issue, cannot be considered a bug, because the type of set::iterator is implementation defined in the standard, and must only conform to the general requirements in 23.1, must be a bidirectional iterator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
[Bug libstdc++/31970] g++ compiles incorrect c++ code
--- Comment #4 from pcarlini at suse dot de 2007-05-18 11:33 --- Suspending until the next ABI... -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
[Bug libstdc++/31970] g++ compiles incorrect c++ code
--- Comment #3 from pcarlini at suse dot de 2007-05-18 11:33 --- Yes, that's right, the issue dates back to the original HP / SGI design: certainly isn't something we can fix without breaking binary compatibility. In short, it's because _Rb_tree_iterator is templatized only on _Tp. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |NEW Component|c++ |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-18 11:33:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-05-18 12:46 ---
F95, section 12.3.2.3, INTRINSIC statement:
R1209 intrinsic-stmt isINTRINSIC [ :: ] intrinsic-procedure-name-list
Constraint: Each intrinsic-procedure-name shall be the name of an intrinsic
procedure.
This doesn't mention any types at all. In addition, only SUN warns about a
superfluous type here:
$> ifort -warn all pr20373.f90# no message
$> sunf95 -w3 pr20373.f90
integer, intrinsic :: dsqrt
^
"pr20373.f90", Line = 1, Column = 23: CAUTION: The type statement for generic
intrinsic function DSQRT is ignored.
Following this, following patch emits a warning if std=gnu and an error if
std=f95|f2203 (not regtested). The wording of the msg could be improved ...
Index: resolve.c
===
--- resolve.c (revision 124790)
+++ resolve.c (working copy)
@@ -6400,6 +6400,12 @@
&& !gfc_intrinsic_name(sym->name, 1))
gfc_error("Intrinsic at %L does not exist", &sym->declared_at);
+ /* Due to F95, 12.3.2.3, INTRINSIC statements shall have no type. */
+ if (sym->attr.intrinsic && sym->ts.type != BT_UNKNOWN)
+gfc_notify_std(GFC_STD_LEGACY | GFC_STD_GNU,
+ "Intrinsic at %L shall not have a type specifier",
+ &sym->declared_at);
+
/* Resolve array specifier. Check as well some constraints
on COMMON blocks. */
$> gfortran-svn -g -Wall -std=gnu pr20373.f90
pr20373.f90:1.27:
integer, intrinsic :: dsqrt
1
Warning: Intrinsic at (1) shall not have a type specifier
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
Keywords||diagnostic, patch
Known to fail||4.2.1 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug fortran/24965] Wrong file name in error message
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-18 14:00 --- I'm not 100% sure whether the code below resembles the problem Erik reported here, but if so, it is fixed in mainline and 4.2: $> cat pr24965.inc real :: x $> cat pr24965.f90 real :: x include "pr24965.inc" x = 3.14 end $> gfortran-svn -g -Wall pr24965.f90 pr24965.inc:1.9: Included at pr24965.f90:2: real :: x 1 Error: Symbol 'x' at (1) already has basic type of REAL -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24965
[Bug target/31985] New: Wide operations (i.e. adddi3) are split too late
Following test generates unoptimized code for test_c(). Generated code should
look like code, generated for test_asm():
--cut here--
typedef unsigned SI __attribute__ ((mode (SI)));
typedef unsigned DI __attribute__ ((mode (DI)));
#define add_ss_c(sh, sl, ah, al, bh, bl)\
{ \
DI __a = (al) | ((DI) ah << 32); \
DI __b = (bl) | ((DI) bh << 32); \
\
DI __c = __a + __b; \
\
(sl) = (SI) (__c & 0x); \
(sh) = (SI) (__c >> 32); \
}
#define add_ss_asm(sh, sl, ah, al, bh, bl) \
__asm__ ("addl %5,%1\n\tadcl %3,%0"\
: "=r" ((SI) (sh)), \
"=&r" ((SI) (sl)) \
: "%0" ((SI) (ah)), \
"g" ((SI) (bh)), \
"%1" ((SI) (al)), \
"g" ((SI) (bl)))
void test_c (SI a, SI b, SI c, SI d)
{
volatile SI x, y;
add_ss_c (x, y, a, b, c, d);
}
void test_asm (SI a, SI b, SI c, SI d)
{
volatile SI x, y;
add_ss_asm (x, y, a, b, c, d);
}
--cut here--
gcc -O2 -fomit-frame-pointer:
test_c:
subl$28, %esp #,
xorl%edx, %edx #
movl40(%esp), %eax # c, tmp66
movl44(%esp), %ecx # d, d
movl%esi, 20(%esp) #,
movl%ebx, 16(%esp) #,
movl%eax, %edx # tmp66,
movl$0, %eax#, tmp66
movl%eax, %esi #, tmp74
movl32(%esp), %eax # a, tmp70
movl%edx, %ebx # tmp75, __c
orl %ecx, %esi # d, tmp74
xorl%edx, %edx #
movl%esi, %ecx # tmp74, __c
movl36(%esp), %esi # b, b
movl%edi, 24(%esp) #,
movl24(%esp), %edi #,
movl%eax, %edx # tmp70,
movl$0, %eax#, tmp70
orl %esi, %eax # b, tmp72
movl20(%esp), %esi #,
addl%eax, %ecx # tmp72, __c
adcl%edx, %ebx #, __c
movl%ecx, 8(%esp) # __c, y
movl%ebx, %ecx # __c, __c
xorl%ebx, %ebx # __c
movl16(%esp), %ebx #,
movl%ecx, 12(%esp) # __c, x
addl$28, %esp #,
ret
test_asm:
subl$16, %esp #,
movl20(%esp), %eax # a, a
movl24(%esp), %edx # b, b
#APP
addl 32(%esp),%edx # d, tmp63
adcl 28(%esp),%eax # c, tmp62
#NO_APP
movl%eax, 12(%esp) # tmp62, x
movl%edx, 8(%esp) # tmp63, y
addl$16, %esp #,
ret
This issue needs to be fixed in order to implement effective i386 (DImode) and
x86_64 (TImode) wide operations in longlong.h. As discussed in thread starting
at [1], it was found that the problem is, that wide operations are split after
reload [2] due to FLAGS_REG link between "add" and "adc" insns. FLAGS_REG can
be accidetally clobbered by reload.
[1] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01084.html
[2] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01187.html
--
Summary: Wide operations (i.e. adddi3) are split too late
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
[Bug target/17390] missing floating point compare optimization
--- Comment #13 from ubizjak at gmail dot com 2007-05-18 15:13 --- (In reply to comment #12) > ping This patch needs to be ported to dataflow infrastructure [1] and has to be re-thought a bit. [1]: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-18 14:58 --- Created an attachment (id=13579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13579&action=view) preprocessed source delta's taking ages on this, so here's the current (large) code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug middle-end/31490] Compile error section type conflict
--- Comment #10 from segher at kernel dot crashing dot org 2007-05-18 14:57 --- Created an attachment (id=13578) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13578&action=view) proposed patch still need to run the testsuite on it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug rtl-optimization/31987] New: [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
I get the following ICE with gcc 4.3 at -O3: (sid)24533:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O3 ickle-Icons.cc ickle-Icons.cc: In member function 'bool Icons::setIcons(const std::string&)': ickle-Icons.cc:152: internal compiler error: in remove_insn, at emit-rtl.c:3579 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug c++/31986] conversion-type-id should match in both contexts
--- Comment #1 from andrew dot stubbs at st dot com 2007-05-18 14:54
---
EDG version 3.8 gives the warning:
t.cpp", line 15: warning:
ambiguous class member reference -- type "T" (declared at line 14)
used in preference to type "C::T" (declared at line 6)
printf ("%d\n", (T) c.operator T()); // invalid
^
In contrast to GCC, this gives the output "2 2 2", not "1 2 2".
And in -strict mode (full standard conformance) gives the error:
t.cpp", line 15: error:
ambiguous class member reference -- type "T" (declared at line 14)
used in preference to type "C::T" (declared at line 6)
printf ("%d\n", (T) c.operator T()); // invalid
^
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31986
[Bug target/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #19 from dberlin at gcc dot gnu dot org 2007-05-18 14:46 --- Created an attachment (id=13576) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view) Possible patch The attached is a huge backport of the 4.3 solver changes. I have only minimally tested it. Let me know if it helps on memory usage, and I will bootstrap/regtest it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #85 from rguenth at gcc dot gnu dot org 2007-05-18 14:46
---
To avoid confusion about what testcase we speak, let's talk about the one
I replicated below. I believe this one is valid as the storage is a union
instantiated in main() and a pointer to it is passed to foo(). It doesn't
matter the argument pointer type is double*, as we access the memory first
as int* (which is ok and starts lifetime of int typed memory) and then we
EOL that object and start lifetime of a long via placement new (alignment
is ok, as is size).
So, anyone disagrees that the below testcase is valid?
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
void __attribute__((noinline)) bar() {};
long __attribute__((noinline)) foo(double *p, int n)
{
long *f;
for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31986] New: conversion-type-id should match in both contexts
The following C++ program should not compile:
#include
class C
{
public:
typedef float T;
operator T() {return 1;};
operator int() {return 2;};
} c;
int
main ()
{
typedef int T;
printf ("%d\n", (T) c.operator T()); // invalid
printf ("%d\n", T(c));
printf ("%d\n", (T)c);
}
The C++ standard, clause 3.4.5, paragraph 7, says that the `T' should refer to
the same type in both `C' and `main'.
The output from this program, with GCC 4.1.1, is "1 2 2" (i.e. a `float' and
two `int's). This shows that the name `T' is significant here.
--
Summary: conversion-type-id should match in both contexts
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31986
[Bug fortran/24633] MODULE attribute conflicts with PROCEDURE attribute
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-18 14:25 --- Subject: Bug 24633 Author: dfranke Date: Fri May 18 13:25:07 2007 New Revision: 124828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124828 Log: 2007-05-18 Daniel Franke <[EMAIL PROTECTED]> PR fortran/24633 * symbol.c (gfc_add_flavor): Add the NAME to error message if available. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24633
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-18 14:16 --- I see several reasons for not doing this: 1) External tools expect the current output format. Your proposal will break that. 2) Standards are not freely distributable, thus they are not widely available. 3) Getting the extra text (testcases, examples, etc) right seems even more complex than getting the original message right. 4) Given the effort-benefit ratio, I don't see many GCC developers jumping into this. Nevertheless, as Andrew points out, we would rather correct cryptic diagnostics. Whenever you find one, you could open a bug report for it. We already have similar bug reports (see PR 29062). Finally, if you still think it is worth it, you could implement it yourself as a wrapper to the output of GCC (similar to how colorgcc [*] works). Parse the output of GCC, match diagnostic messages, and depending on the matched message, write whatever text you think would be appropriate. Much easier than hacking GCC itself and it will give an idea on how difficult the task actually is and how many people would be actually interested on it. [*] http://packages.debian.org/unstable/devel/colorgcc.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #83 from gdr at cs dot tamu dot edu 2007-05-18 14:26 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "ian at airs dot com" <[EMAIL PROTECTED]> writes: | The test case in comment #71 doesn't use placement new either. | | This PR was originally about placement new. Yes. | I think there is general agreement | thta placement new needs to avoid aliasing problem. Yes. The intent of placement new is to specify a new dynamic type, and end the lifetime of previous object. This is type safe, beause the "old" object no longer exists. | I don't think there is | general agreement that arbitrary type casting needs to avoid aliasing problems. agree. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/24633] MODULE attribute conflicts with PROCEDURE attribute
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-05-18 14:27 --- Fixed in trunk, the changes will not be backported to 4.2. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24633
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #84 from gdr at cs dot tamu dot edu 2007-05-18 14:30 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Comment #81 from rguenth at gcc dot gnu dot org 2007-05-18 09:45 --- | Yes, both testcases are valid and are using placement new. Note the loop | is only to confuse the optimizers enough to re-order the stores and produce | a miscompilation. Note the loop runs exactly once, and in essence we are doing | | int *p = XXX; /* integer memory */ | *p = 0; | long *q = new (p) long; This is OK as long as int and long have same alignment, sizeof, etc. For example, that code is invalid on 64-bit platform where int has alignment and the storage is not large enough to meet long's requirement. This is the case only when the "operator new" is not overloaded, but is the "standard one". The exact conditions are so tricky to explicit that it would just be OK for us to accept it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-18 14:55 --- Created an attachment (id=13577) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13577&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #2 from ubizjak at gmail dot com 2007-05-18 15:28 --- Confirmed, backtrace: #1 0x082aa0d0 in remove_insn (insn=0xb7b25620) at ../../gcc-svn/trunk/gcc/emit-rtl.c:3579 #2 0x08262d08 in delete_insn (insn=0xb7b25620) at ../../gcc-svn/trunk/gcc/cfgrtl.c:134 #3 0x08262ef8 in delete_insn_chain (start=0xb7b25620, finish=0xb7b17140) at ../../gcc-svn/trunk/gcc/cfgrtl.c:214 #4 0x08263161 in rtl_delete_block (b=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfgrtl.c:373 #5 0x08263299 in cfg_layout_delete_block (bb=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfgrtl.c:2467 #6 0x08254fdd in delete_basic_block (bb=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfghooks.c:464 #7 0x08253de1 in cleanup_cfg (mode=64) at ../../gcc-svn/trunk/gcc/cfgcleanup.c:2002 #8 0x0872f2a8 in fwprop_done () at ../../gcc-svn/trunk/gcc/fwprop.c:917 #9 0x0872f357 in fwprop_addr () at ../../gcc-svn/trunk/gcc/fwprop.c:999 #10 0x083ba9e3 in execute_one_pass (pass=0x88fa680) at ../../gcc-svn/trunk/gcc/passes.c:1065 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-18 15:28:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug c++/31988] New: new operator should not permit default first parameter
The following C++ program should not compile:
#include
class C
{
public:
void * operator new (size_t = 32); // invalid
};
The C++ standard, clause 3.7.3.1, paragraph 1, says that the first parameter to
new should not have a default argument. GCC gives no error and no warning.
--
Summary: new operator should not permit default first parameter
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988
[Bug fortran/25061] procedure name conflict
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-18 15:49 ---
I had a short look at this. The problem is in decl.c:693f:
if (sym->attr.flavor != 0
&& sym->attr.proc != 0
&& (sym->attr.subroutine || sym->attr.function)
&& sym->attr.if_source != IFSRC_UNKNOWN)
gfc_error_now ("Procedure '%s' at %C is already defined at %L",
name, &sym->declared_at);
(gdb) print sym->name
$5 = 0x887e4f6 "i1"
(gdb) print sym->attr.proc
$8 = PROC_UNKNOWN
(gdb) print sym->attr.if_source
$10 = IFSRC_UNKNOWN
Interestingly, if the subroutine I1 is duplicated, the expected error (I1
already defined as interface) is emitted:
$> cat pr25061.f90
MODULE foo
INTERFACE I1
SUBROUTINE S1(I)
END SUBROUTINE S1
SUBROUTINE S2(R)
END SUBROUTINE S2
END INTERFACE I1
CONTAINS
SUBROUTINE I1(I)
END SUBROUTINE I1
SUBROUTINE I1(R) ! same as before, but I1 in triplicate now
END SUBROUTINE I1
END MODULE
$> gfortran-svn -g -Wall
pr25061.f90:11.15:
SUBROUTINE I1(R)
1
pr25061.f90:2.12:
INTERFACE I1
2
Error: Procedure 'i1' at (1) is already defined at (2)
$> gfortran-svn -v
gcc version 4.3.0 20070517 (experimental)
Adding Paul, The Interface Wizard, Thomas as CC. He will probably now how to
handle this :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org, pault at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25061
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |tree-optimization Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug target/31989] New: [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
I have verified that this patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01333.html causes bug 31666 and bug 31681. -- Summary: [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu OtherBugsDependingO 31666,31681 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug c++/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #2 from hjl at lucon dot org 2007-05-18 16:32 --- I have verified that this patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01333.html causes this regression on Linux/x86-64. Richard, can you take a look? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug c/31990] New: udivdi3 not found for linux kernel
I just filed (verbatim) the PR reproduced below with bugzilla.kernel.org (8501) Hopefully the exports will be able to communicate directly. Most recent __gcc__ compiler where this bug did *NOT* occur: gcc-4.2.0 Distribution: Hardware Environment: x86 (will try on MAC G4 machine) Software Environment: gcc compilers Problem Description: "make V=1" output kernel/built-in.o: In function `getnstimeofday': (.text+0x1e48d): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1e5b5): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': -- Summary: udivdi3 not found for linux kernel Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-unknown-linux-gnu GCC host triplet: i686-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #86 from ian at airs dot com 2007-05-18 17:24 --- Re comment #80, comment #81, comment #82. My patch handles the placement new in comment #73 to indicate an alias between double and long. The mis-ordered code is actually aliasing int and long. That aliasing is due to a cast to (int*). There is no placement new in that cast. There is no reason for the compiler to avoid exchanging the store via int* and the store via long*. Why should it? If you omitted the placement new, this would be a standard aliasing violation between int and double. With the placement new, it's still an aliasing violation between int and long. The placement new doesn't excuse you from all aliasing violations: it just excuses you from aliasing violations involving the actual types in question. If you want to make a principled argument that placement new excuses you from all aliasing violations, then again the result is that in a function which uses placement new we should disable TBAA for that function. That would be OK with me and easy to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #2 from daney at gcc dot gnu dot org 2007-05-18 17:31 --- Currently building mipsel-unknown-linux-gnu. # cat LAST_UPDATED Wed May 16 12:35:18 PDT 2007 Wed May 16 19:35:18 UTC 2007 (revision 124776) libstdc++-v3 was built without ICEing (currently building in libjava). The differences from Martin's configuration are that my target is little endian and I configured with --disable-static. The testcase would appear to be when building the static library version of strstream.o (I see no -fpic in the compiler invocation). FWIW this is my configure command: ../gcc/configure --with-arch=mips32 --with-float=soft --disable-java-awt --without-x --disable-tls --enable-__cxa_atexit --disable-jvmpi --disable-static --disable-libmudflap --enable-languages=c,c++,java I guess I will try the strstream.ii in the bug attachment with my compiler when it finishes bootstrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #89 from mark at codesourcery dot com 2007-05-18 17:44 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
> Re comment #80, comment #81, comment #82. My patch handles the placement new
> in comment #73 to indicate an alias between double and long. The mis-ordered
> code is actually aliasing int and long. That aliasing is due to a cast to
> (int*). There is no placement new in that cast. There is no reason for the
> compiler to avoid exchanging the store via int* and the store via long*. Why
> should it?
I don't think the fact that "p" is a "double *" is relevant; it could
just as well be "void *". This kind of code is unambiguously valid:
void f(double *p) { (int*)p = 3; }
void g() {
int i;
f((double *)&i);
}
Pedantically, the alignment of "double" has to be no stricter than "int"
for this to be valid, but since we define pointer conversion as a no-op,
it's always valid in GNU C.
This is why I liked your earlier patch that made placement new a memory
barrier. I think the right handling of placement new is basically to
say "everything we know about types is forgotten here". One can limit
that to things to which the operand might point, but points-to analysis
(should not) tell you that "p" and "l" cannot point at the same place,
since we have no idea what "p" points at.
I don't think this is equivalent to totally disabling TBAA in C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #88 from ian at airs dot com 2007-05-18 17:35 --- Regarding comment #85, this again relies on the notion of dynamic type of a memory location such that the only possible end result is to eliminate TBAA when compiling C++. The only thing I can say about this sort of test case is that I agree that one can make an argument from the standard that this type of code is valid. However, as I've said before, e.g., in comment #76, I don't think that anybody really wants that end result. Any example that inherently relies on a type cast is going to lead you straight to eliminating TBAA. And note that your example is clearly invalid in C. Adding the placement new doesn't really have anything to do with whether it is valid or invalid in C++. Can you show me a test case which my patch gets wrong which does not involve type casting outside of placement new itself? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #87 from ian at airs dot com 2007-05-18 17:27 --- I'm not sure what to make of comment #84. We don't determine aliasing by alignment or size. We determine it by type. We don't currently treat int and long as aliasing each other even if they happen to have the same alignment and size. I believe this is correct according to the C standard but I am less familiar with the C++ standard. We could change the aliasing machinery in that way for C++ if it seems to be appropriate, but I would prefer to take that to a different PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-18 17:29 --- First off, can you attach the preprocessed source for built-in.c ? Second this might not be a bug in GCC but in the kernel not providing all of the required functions that are in libgcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #92 from pinskia at gcc dot gnu dot org 2007-05-18 18:55
---
> So if that is not valid, and the placement new case is valid, then what is the
> essential difference between the cases? The variable is being accessed via
> two
> different types. Why is that OK?
> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
> void g() { int i; f((double *)&i); }
Because the memory that p was pointing to, stops being an int once a placement
new happens. For F, it goes:
> void f(double* p)
> {
p points to an variable that is an int
> *(int*)p = 3
access the int via an int.
> long *l = new (p) long;
The memory is no longer an int, it has become a long, it cannot be accessed as
an int no longer as that would be undefined.
> *l = 4;
Access the memory as a long and since the type is a long, this is well defined.
>}
Now after this function returns the variable can only be accessed as a long
(well and via a character type).
Hopefully this explains why this is valid. Now should we do anything about it,
I don't know because how often does this happen in real life, I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #94 from ian at airs dot com 2007-05-18 19:03 --- I tried the original test case with icc, and it gets the right result. The assignment b->p = 0 is discarded. Unfortunately I'm not sure what this actually tells us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-18 19:09 --- > 3. I referred to to the experts in both organizations and I do not believe > that > you are the gcc expert in machine descriptions. Have you looked into what I have done? Lets see my first big patch: 2002-12-02 Andrew Pinski <[EMAIL PROTECTED]> * config/rs6000/rs6000.md (ffssi): Convert to expander. (ffsdi): Likewise. (cntlzw2, cntlzd2): New patterns. And then more recently: 2007-03-31 Andrew Pinski <[EMAIL PROTECTED]> PR target/31364 * config/rs6000/rs6000.md (call): Convert to LR hard reg for secureplt. (call_value): Likewise. 2006-11-29 Andrew Pinski <[EMAIL PROTECTED]> PR target/29945 * config/spu/spu.md (extend_compare): New pattern. (extend_compare): Change to expand and use the above pattern. Plus this: spu portAndrew Pinski [EMAIL PROTECTED] I don't see how you can say I am not an expert at this. Also one more thing did you read http://gcc.gnu.org/bugs.html which explains exactly what we need for a bug report? The reason why the bitfield patch has not go in yet, is because I am busy with other work and it is a minor issue on my plate right now (have you looked into what I have been doing lately?). Also 4.3 is no where near being released in the next month or two so calm down. We can't all fix bugs in the same time as they are reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #1 from hjl at lucon dot org 2007-05-18 19:05 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01223.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #93 from mark at codesourcery dot com 2007-05-18 19:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
> void g() { int i; f((double *)&i); }
>
> And the specific question is whether we are permitted to interchange the
> assignments to *p and *l.
I do not think we are.
> void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
>
> Is that valid? Is the compiler permitted to interchange the assignments to *p
> and *l? Consider that, as in comment #73, p might actually point to a union
> of
> int and long. Does that fact that that union might exist somewhere else make
> this test case valid? Presumably it does not. Presumably this is invalid.
Agreed; this case is invalid.
> So if that is not valid, and the placement new case is valid, then what is the
> essential difference between the cases? The variable is being accessed via
> two
> different types. Why is that OK?
Because placement new changes the type of storage, in the same way that
using ordinary ("delete") and then using (ordinary) "new" (but getting
back the same memory pointer) does. The placement "new" operator is
special.
> You're right that don't have to abandon TBAA to make this work, that we can
> make it work by turning placement new into a memory barrier. But then you
> have
> to address comment #42. That approach will cause a performance regression for
> natural valid code. The question then becomes whether we are willing to pay
> that performance regression for normal code in order to support this sort of
> weird code.
I am willing to accept that performance regression. I don't consider
that code "normal"; many C++ performance libraries now provide a way to
produce an uninitialized container, precisely to avoid default
construction. POOMA could use that technique.
It would of course be better (though, in my opinion, not essential) to
have a more gentle barrier. If we could tell the compiler to forget the
type of anything that the argument to placement-new might point to, but
not to assume that arbitrary weirdness has occurred, then the compiler
could still eliminate the redundant stores.
In other words, in Comment #42, the problem is that the volatile asm
tells the compiler that not only must the stores/loads not be reordered
across the barrier, but that stores before the barrier must actually
occur because their may be some arbitrary action at the barrier that
depends upon the values written. If we had a barrier that says just
that the operations may not be reordered across the barrier -- but does
not say that the operations before the barrier are side-effecting --
then we could still eliminate them as redundant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #90 from ian at airs dot com 2007-05-18 18:38 ---
I agree that this is valid:
void f(double *p) { *(int*)p = 3; }
void g() {
int i;
f((double *)&i);
}
But I don't think that is the question at hand. The variable is always being
accessed in the same type, which is also the type of its declaration. The
question at hand is this:
void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
void g() { int i; f((double *)&i); }
And the specific question is whether we are permitted to interchange the
assignments to *p and *l.
Let's consider this:
void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
Is that valid? Is the compiler permitted to interchange the assignments to *p
and *l? Consider that, as in comment #73, p might actually point to a union of
int and long. Does that fact that that union might exist somewhere else make
this test case valid? Presumably it does not. Presumably this is invalid.
So if that is not valid, and the placement new case is valid, then what is the
essential difference between the cases? The variable is being accessed via two
different types. Why is that OK?
You're right that don't have to abandon TBAA to make this work, that we can
make it work by turning placement new into a memory barrier. But then you have
to address comment #42. That approach will cause a performance regression for
natural valid code. The question then becomes whether we are willing to pay
that performance regression for normal code in order to support this sort of
weird code.
Can anybody see a way through this maze?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #3 from tbm at cyrius dot com 2007-05-18 18:45 --- I started a build on my mipsel box too and it has failed in the same way as on mips. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #91 from pcarlini at suse dot de 2007-05-18 18:46 --- (In reply to comment #90) > Can anybody see a way through this maze? Humbly, I'd like to suggest again that we have a look to the assembly produced by other compilers. I remember that some GCC contributors have access to compilers such as ICC, XLC++, Sun, etc. and I don't think we should strive at all costs for perfect optimization, if that means keeping busy our best contributors for months and risking producing wrong code. We can always return to the issue later, as an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #2 from malitzke at metronets dot com 2007-05-18 18:57 --- Andy there you go again: Irrelevancies and make work for others. You folks at gcc made tons of changes in gcc-4.3 regarding machine definitions and similar. I have some evidence that some blatant mistakes were silently corrected without mentioning even ICE's in gcc bootstrap. I refrained (wisely) from saying anything about compilations using 3Gigs of memory and then collapsing,. Now an insider has come to acknowledge that problem,PR31863. How about your patch to overcome the PR 31541 (bit field addressing) now untouched for almost one month. It is no wonder that a lot of packages, when I tell them about easy fixes regarding gcc-4.x.y, reply "we rather deal deal with gcc-3.x.y or even gcc-2.x( even with -fno-strength-reduce). The gcc group really working hard at overcoming problems noticed by users are the gfortran people (Yes, I had my run-in with them over the goto thing, but they have not caused me to file any PR's after that) Now to some perhaps ppoorly understood by my self technical issues: 1. binutils does a MACRO regarding udevdi3, but its is impossible to build binutils (even current CVS with gcc-4.3.0) 2. gcc-4.2.1 compiles the impacted kernel fine. To my simple, but seasoned, mind the onus when something stops working is on the party that made changes (namley gcc going from 4.2 to 4.3); not on the one that did not change in this case kernel-2.6.20.11. 3. I referred to to the experts in both organizations and I do not believe that you are the gcc expert in machine descriptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libgcj/31939] Command line arguments are byteswapped before being passed to the program runing in custom locale.
--- Comment #4 from serg at vostok dot net 2007-05-18 20:07 ---
For subject 2.
The point is to find where arguments of "int main(int argc, char** argv)" are
converted into java.lang.String to be passed to "static void main(String[]
args)".
Trail:
gcc/java/jvgenmain.c:
int main(int argc,char **argv)
constructs a C code to call the main java method with
JvRunMain(classname,argc,argv)
libjava/prims.cc:
void JvRunMain (jclass klass, int argc, const char **argv)
simply calls
_Jv_RunMain (klass, NULL, argc, argv, false)
void _Jv_RunMain (jclass klass, const char *name, int argc, const char **argv,
bool is_jar)
simply calls
_Jv_RunMain (NULL, klass, name, argc, argv, is_jar)
void _Jv_RunMain (JvVMInitArgs *vm_args, jclass klass, const char *name, int
argc, const char **argv, bool is_jar)
calls
JvConvertArgv (argc - 1, argv + 1)
JArray * JvConvertArgv (int argc, const char **argv)
copies each argument into jbyteArray bytes, then calls
new java::lang::String (bytes, 0, len)
to make a String from it with a default encoding.
libjava/java/lang/String.java:
public String(byte[] data, int offset, int count)
calls
init (data, offset, count,System.getProperty("file.encoding", "8859_1"))
libjava/java/lang/natString.cc:
void java::lang::String::init (jbyteArray bytes, jint offset, jint count,
jstring encoding)
uses
gnu::gcj::convert::BytesToUnicode::getDecoder(encoding)
to make a converter
and
converter->read(array, outpos, avail)
to convert data
libjava/gnu/gcj/convert/BytesToUnicode.java:
class BytesToUnicode extends IOConverter
public static BytesToUnicode getDecoder (String encoding)
uses eigther
new Input_iconv(encoding)
or
new BytesToCharsetAdaptor(Charset.forName(encoding))
Looks like I will have to test both Input_iconv and BytesToCharsetAdaptor to
see if any of them is buggy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31939
[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted
--- Comment #1 from jb at gcc dot gnu dot org 2007-05-18 20:07 --- Seems to work fine on i686-pc-linux-gnu. I would have guessed it to be something related to padding, but it's weird that it's not seen in 32-bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31933
[Bug target/31628] stdcall function is miscompiled
--- Comment #8 from hjl at gcc dot gnu dot org 2007-05-18 20:30 --- Subject: Bug 31628 Author: hjl Date: Fri May 18 19:29:45 2007 New Revision: 124831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124831 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31628 * gcc.target/i386/pr31628.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr31628.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #7 from jb at gcc dot gnu dot org 2007-05-18 20:52 --- Seems unf_io_convert_3.f90 is fixed by the patch for PR31915, which adds padding for CONVERT. The patch was committed as r124741. Closing, please verify and reopen if I'm wrong. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #95 from rguenth at gcc dot gnu dot org 2007-05-18 20:55 --- But construction/initialization of uninitalized memory in happens with placement new! So we're back to square one. What this PR initially was about is a fixed type memory allocator in C++ which needs to change memory from allocated type T to free-space-managing-structure S at deallocation time and the other way around at allocation time. We absolutely _have_ to handle this case correct. And we need to optimize the routines that use placement new, because they resemble patterns used in libraries like POOMA or Boost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-05-18 21:10 --- The testcase still crashes on mainline (and 4.1 and 4.2 branch) if I compile it without "-g" or with "--param ggc-min-expand=0 --param ggc-min-heapsize=0 -g". Looks like there are some invalid pointers. Whether the program crashes or not depends on the garbage they are pointing to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #4 from malitzke at metronets dot com 2007-05-18 21:11 --- Andy! Taking your your advice to calm down I looked for the built-in.c file you wanted preprocessed. Well, it does not exist as built-in.o is a composite object file. The Kernel peoople being a more helpful and b) having more expertise asked for time.s and timekeeping.s out out time.c and timekeeping.c. I attached already both to PR8501. and you can take it from there. -- malitzke at metronets dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #96 from pcarlini at suse dot de 2007-05-18 21:12 --- (In reply to comment #95) > But construction/initialization of uninitalized memory in happens > with > placement new! Placement new is used only for non-POD types, to be clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug rtl-optimization/26655] [4.0/4.1 Regression] ICE in ix86_secondary_memory_needed, at config/i386/i386.c:16446
--- Comment #22 from reichelt at gcc dot gnu dot org 2007-05-18 21:12 --- Reopening bug... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
[Bug rtl-optimization/26655] [4.0/4.1 Regression] ICE in ix86_secondary_memory_needed, at config/i386/i386.c:16446
--- Comment #23 from reichelt at gcc dot gnu dot org 2007-05-18 21:13 --- ... to close as fixed in GCC 4.2.0 and later. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.1.3 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #16 from jb at gcc dot gnu dot org 2007-05-18 21:15 --- The critical thing with inlining array intrinsics, IMHO is to give the optimizer more data to work with allowing it to get rid of temp arrays, perform loop fusion or fission etc. So with a trivial benchmark like #15, you don't see any difference, except with potentially higher optimization for user code than libgfortran. For example in gas_dyn/chozdt: REAL, DIMENSION (NODES) :: DTEMP !--- ! Profile for gfortran 4.3: ! CPU_CLK_UNHALTED L2_CACHE_MISS ! samp %runtim samp %tot ! 59887 22.4783 1484 10.9828 : DTEMP = DX/(ABS(VEL) + SOUND) ! ifort 9.1 profile ! 40104 16.2034 1198 8.8166 : DTEMP = DX/(ABS(VEL) + SOUND) DTEMP = DX/(ABS(VEL) + SOUND) ISET = MINLOC (DTEMP) DT = DTEMP(ISET(1)) If MINLOC were inlined, perhaps a sufficiently optimizer could convert this into the equivalent REAL :: DTEMPMIN INTEGER :: i DTEMPMIN = HUGE(1.0d0) DO I = 1, NODES DT = DX(I)/(ABS(VEL(I)+SOUND(I)) IF (DT < DTEMPMIN) THEN DTEMPMIN = DT END IF END DO DT = DTEMPMIN i.e. avoid the temporary array entirely. Yes, I guess this is quite a lot to ask. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #97 from mark at codesourcery dot com 2007-05-18 21:17 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: > But construction/initialization of uninitalized memory in happens > with > placement new! So we're back to square one. What this PR initially was about > is a fixed type memory allocator in C++ which needs to change memory from > allocated type T to free-space-managing-structure S at deallocation time and > the other way around at allocation time. We absolutely _have_ to handle > this case correct. And we need to optimize the routines that use > placement new, because they resemble patterns used in libraries like POOMA > or Boost. First and foremeost, we have to generate correct code. If that means the memory barrier solution, for now, then so be it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #17 from jb at gcc dot gnu dot org 2007-05-18 21:20 --- Or even better (duh): REAL :: DTEMP DT = HUGE(1.0d0) DO I = 1, NODES DTEMP = DX(I)/(ABS(VEL(I)+SOUND(I)) IF (DTEMP < DT) THEN DT = DTEMP END IF END DO -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/25252] ICE on invalid code
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-05-18 21:27 --- Still crashes for me on mainline and 4.1 and 4.2 branch (i686-pc-linux-gnu). Looks like there are some invalid pointers. Whether the program crashes or not depends on the garbage they are pointing to. This looks actually similar to PR 18923 where we also get crashes or garbled names in error messages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #98 from pcarlini at suse dot de 2007-05-18 21:27 --- (In reply to comment #97) > First and foremeost, we have to generate correct code. If that means > the memory barrier solution, for now, then so be it. Yes, but I'm a little worried myself not by but by containers like , and , where we call allocator::contruct, which uses placement new, to "install" the value in the allocated node. In that case, unfortunately, per 20.4.1.1/12, we can't optimize it for POD types :( At minimum we should benchmark a bit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #3 from tbm at cyrius dot com 2007-05-18 21:31 --- Note that this works with 20070422 (and fails with 20070515). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #2 from tbm at cyrius dot com 2007-05-18 21:32 --- This appeared between 20070326 (works) and 20070422 (ICE). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug middle-end/31991] New: [4.3 regression] gfortran.dg/st_function.f90 FAILs
Since May 1st this testcase fails for all optimization levels above -O0. According to gcc-testresults it passed on April 30th. -- Summary: [4.3 regression] gfortran.dg/st_function.f90 FAILs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug middle-end/31991] [4.3 regression] gfortran.dg/st_function.f90 FAILs
--- Comment #1 from tobi at gcc dot gnu dot org 2007-05-18 21:37 --- Sorry, I meant to say that it started failing on May 2nd. E.g. it fails here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00090.html and passes here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00042.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #99 from pcarlini at suse dot de 2007-05-18 21:37 --- To complete my reasoning: in case we end-up with some sort of very bad pessimization of placement new, probably we'll have to adjust such containers to not call allocator::contruct at all when the default allocator is involved && a POD type is contructed, similarly to std::vector and std::deque for the uninitialized functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-05-18 21:44 --- Although I can not observe a crash on my machine with either flag setting, valgrind shows loads of ==32659== Invalid read of size 4 ==32659==at 0x809432F: gfc_resolve_expr (resolve.c:3220) ==32659== Address 0x4213C2C is 20 bytes inside a block of size 24 free'd ==32659==at 0x402119F: free (vg_replace_malloc.c:233) ==32659==by 0x80A4D42: gfc_undo_symbols (symbol.c:1959) in varying places, always related to gfc_undo_symbols ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug middle-end/31991] [4.3 regression] gfortran.dg/st_function.f90 FAILs
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-18 21:49 --- *** This bug has been marked as a duplicate of 31095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-18 21:49 --- *** Bug 31991 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-18 21:59 --- (In reply to comment #4) > Andy! Don't call me Andy! It is childish. > Taking your your advice to calm down I looked for the built-in.c file you > wanted preprocessed. Well, it does not exist as built-in.o is a composite > object file. And how do I know that from your descirption of the bug? As you just have: kernel/built-in.o: In function `getnstimeofday': (.text+0x1e48d): undefined reference to `__udivdi3' Which is why I was asking for built-in.i because I thought like a normal code, it was a normal object file and not an incremental linked one. > The Kernel peoople being a more helpful and b) having more expertise asked for > time.s and timekeeping.s out out time.c and timekeeping.c. I attached already > both > to PR8501. and you can take it from there. So attach time.i and timekeeping.i here which is exactly what we need. Note this is really only a missed optimization for GCC wise as if we call __udivdi3 now instead of doing it inlined, the code is just slower, libgcc contains __udivdi3. So the kernel needs to add the function but we can also fix GCC so we don't produce that for a missed optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the "right" alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same "dynamic type" (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #100 from gdr at cs dot tamu dot edu 2007-05-18 22:04 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "ian at airs dot com" <[EMAIL PROTECTED]> writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the "right" alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same "dynamic type" (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/31066] Suboptimal vectorization after inlining
--- Comment #3 from jb at gcc dot gnu dot org 2007-05-18 22:11 --- Closing as invalid. gfortran vectorizes the loop in gas_dyn:eos as it should. The real reason why gfortran sucks at gas_dyn is that ifort uses the reciprocal approximation instructions and a Newton-Rhapson step instead of division and square root instructions. I.e. instead of calculating sqrt(a/b) which has both a divide and a square root (both are pretty slow instructions) it calculates 1/sqrt(b*(1/a)) + the NR step. See PR31723. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-05-18 22:11
---
Eventually, I got a traceable segfault with this shortened testcase:
$> cat pr18923.f90
module FOO
contains
subroutine FOO
character(len=selected_int_kind(0)) :: C
end subroutine
end
Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
1747expr->ts = expr->symtree->n.sym->result->ts;
(gdb) bt
#0 gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
#1 0x08095bbe in resolve_index_expr (e=0x887f380) at
../../../gcc/gcc/fortran/resolve.c:5482
#2 0x08095c2f in resolve_charlen (cl=0x8845148) at
../../../gcc/gcc/fortran/resolve.c:5508
#3 0x0809746f in resolve_types (ns=0x887f020) at
../../../gcc/gcc/fortran/resolve.c:7401
#4 0x08097557 in resolve_types (ns=0x88451b0) at
../../../gcc/gcc/fortran/resolve.c:7414
#5 0x08099bfc in gfc_resolve (ns=0x88451b0) at
../../../gcc/gcc/fortran/resolve.c:7477
#6 0x0808d6ac in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3248
#7 0x080aeabd in gfc_be_parse_file (set_yydebug=0) at
../../../gcc/gcc/fortran/f95-lang.c:303
#8 0x082ffe68 in toplev_main (argc=2, argv=0xbf93d354) at
../../../gcc/gcc/toplev.c:1051
#9 0x080f262f in main (argc=2, argv=0x1) at ../../../gcc/gcc/main.c:35
Most notable point are the identical expressions in this if/else clause
(resolve.c:1740f):
/* Make sure that the expression has a typespec that works. */
if (expr->ts.type == BT_UNKNOWN)
{
if (expr->symtree->n.sym->result
&& expr->symtree->n.sym->result->ts.type != BT_UNKNOWN)
expr->ts = expr->symtree->n.sym->result->ts;
else
expr->ts = expr->symtree->n.sym->result->ts; /* crashes here */
}
Otherwise, I'm out of my wits here. Hope this helps someone?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| But I don't think that is the question at hand. The variable is always being
| accessed in the same type, which is also the type of its declaration. The
| question at hand is this:
|
| void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
| void g() { int i; f((double *)&i); }
|
| And the specific question is whether we are permitted to interchange the
| assignments to *p and *l.
After the placement new, the lifetime of *p is ended, and the lifetime
of *l starts there. I don't think that leaves room for exchanging the
stores to *p and *l.
| Let's consider this:
|
| void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
|
| Is that valid?
If p is pointing to a union object that contain both int and long,
yes, it is valid. Otherwisem, it is not.
| Is the compiler permitted to interchange the assignments to *p
| and *l?
It is valid if we have a union object, otherwise, no.
-- Gaby
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #101 from gdr at cs dot tamu dot edu 2007-05-18 22:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| But I don't think that is the question at hand. The variable is always being
| accessed in the same type, which is also the type of its declaration. The
| question at hand is this:
|
| void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
| void g() { int i; f((double *)&i); }
|
| And the specific question is whether we are permitted to interchange the
| assignments to *p and *l.
After the placement new, the lifetime of *p is ended, and the lifetime
of *l starts there. I don't think that leaves room for exchanging the
stores to *p and *l.
| Let's consider this:
|
| void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
|
| Is that valid?
If p is pointing to a union object that contain both int and long,
yes, it is valid. Otherwisem, it is not.
| Is the compiler permitted to interchange the assignments to *p
| and *l?
It is valid if we have a union object, otherwise, no.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #102 from gdr at cs dot tamu dot edu 2007-05-18 22:15 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #96 from pcarlini at suse dot de 2007-05-18 21:12 --- | (In reply to comment #95) | > But construction/initialization of uninitalized memory in happens with | > placement new! | | Placement new is used only for non-POD types, to be clear. yes, but it is also valid for POD types. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #103 from gdr at cs dot tamu dot edu 2007-05-18 22:16 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #98 from pcarlini at suse dot de 2007-05-18 21:27 --- | (In reply to comment #97) | > First and foremeost, we have to generate correct code. If that means | > the memory barrier solution, for now, then so be it. | | Yes, but I'm a little worried myself not by but by containers like | , and , where we call allocator::contruct, which uses | placement new, to "install" the value in the allocated node. In that case, | unfortunately, per 20.4.1.1/12, we can't optimize it for POD types :( At | minimum we should benchmark a bit... If the element type is a POD, we should use assignment, not placement new. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #3 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31666 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #2 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31989 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #3 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31681 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #3 from hjl at lucon dot org 2007-05-18 22:40 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug target/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #4 from hjl at lucon dot org 2007-05-18 22:40 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #4 from hjl at lucon dot org 2007-05-18 22:41 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #104 from pcarlini at suse dot de 2007-05-18 22:44 --- (In reply to comment #103) > If the element type is a POD, we should use assignment, not placement new. Agreed, in principle. But before adding a load of templates and dispatching, let's wait a bit for the outcome of this issue and benchmark carefully: the performance difference may be minor, given that we are dynamically allocating memory for the new node. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31992] New: [4.1/4.2/4.3 regression] ICE initializing static variable of template class
The following valid code snippet triggers a segfault since GCC 4.1.2:
=
template struct A
{
static const int i;
};
template const int A::i( A::i );
=
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3 regression] ICE initializing static
variable of template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
[Bug target/31985] Wide operations (i.e. adddi3) are split too late
--- Comment #1 from ubizjak at gmail dot com 2007-05-18 22:52 ---
Similar problems are shown for DImode store in following test:
--cut here--
typedef unsigned SI __attribute__ ((mode (SI)));
typedef unsigned DI __attribute__ ((mode (DI)));
#define umul_ppmm_c(w1, w0, u, v) \
{ \
DI __c = (DI) u * v;\
\
(w0) = (SI) (__c & 0x); \
(w1) = (SI) (__c >> 32);\
}
#define umul_ppmm_asm(w1, w0, u, v) \
__asm__ ("mull %3"\
: "=a" ((SI) (w0)), \
"=d" ((SI) (w1)) \
: "%0" ((SI) (u)), \
"rm" ((SI) (v)))
void test_c (SI a, SI b)
{
volatile SI x, y;
umul_ppmm_c (x, y, a, b);
}
void test_asm (SI a, SI b)
{
volatile SI x, y;
umul_ppmm_asm (x, y, a, b);
}
--cut here--
gcc -O2 -fomit-frame-pointer
test_c:
subl$16, %esp
movl24(%esp), %eax
mull20(%esp)
movl%eax, 8(%esp)
movl%edx, %eax
xorl%edx, %edx
movl%eax, 12(%esp)
addl$16, %esp
ret
test_asm:
subl$16, %esp
movl20(%esp), %eax
#APP
mull 24(%esp)
#NO_APP
movl%eax, 8(%esp)
movl%edx, 12(%esp)
addl$16, %esp
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
[Bug c++/31992] [4.1/4.2/4.3 regression] ICE initializing static variable of template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-05-18 22:53 --- There is no guarantee that you are hitting the same problem, but if so, this is very helpful (sometimes :) ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #6 from malitzke at metronets dot com 2007-05-18 22:58 --- Created an attachment (id=13580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13580&action=view) time.i form ./kernel/time.c first requested attachment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug c++/31993] New: [4.3 regression] ICE with template class in variadic template class
The following valid code snippet with variadic templates triggers an ICE
on mainline:
=
template struct A;
template class... T> struct A...>
{
template struct B {};
B<0> b;
};
=
bug.cc:6: internal compiler error: tree check: expected tree that contains
'decl non-common' structure, have 'template_template_parm' in
convert_template_argument, at cp/pt.c:4665
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with template class in variadic
template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
[Bug c++/31993] [4.3 regression] ICE with template class in variadic template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||dgregor at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
