--- 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
--- 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
--- 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/sh
--- 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.
--- 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/m
--- 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_chan
--- 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 essen
--- 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.
M
--- 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.cg
--- 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
--
--- 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
-
--- 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-sv
--- 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, m
--- 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
Stat
--- 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.
--
--- 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 do
--- 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.1
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)\
{
--- 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/bugzi
--- 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
--- 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?
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 s
--- 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)
print
--- 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.
Le
--- 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(). I
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
--- 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 fo
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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 de
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.
--
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |tree-optimization
Target Milestone|--- |4.2
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
Sev
--- 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|
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 Environme
--- 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 cas
--- 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
--- 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
--- 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
--- 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 alignmen
--- 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
--- 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(dou
--- 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
--- 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
--- 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
--- 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() { i
--- 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
--- 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
--- 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
--- 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 silen
--- 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(i
--- 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
--- 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
--- 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:
--- 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 m
--- 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 t
--- 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) h
--- 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_b
--- 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
St
--- 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
---
--- 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
--- 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
> w
--- 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.cg
--- 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
--- 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
--- 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
--- 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
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
Se
--- 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
-
--- 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 invo
--- 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 0
--- 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
--
--- 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
---
--- 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 co
"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.
T
--- 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
--- 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
--- 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 sign
"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;
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 |
--- 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 |
--- 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 |
--- 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 thi
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
--- 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)
--
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
--- 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
--- 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
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 compile
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||dgregor at gcc dot gnu dot
|
1 - 100 of 130 matches
Mail list logo
