While tackling this bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31998 ) I
found a problem with the boehm-gc. This is a seperate bug report only about
boehm-gc (and not about the interrelated issues of the above report).
/gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-05-19 06:02 ---
fixed:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00150.html
by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01733.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed
This "spec bug" probably affects other targets too.
I did search for "Unreachable" "statement" and came up ONE hit - unrelated:
"Unreachable code at beginning of switch "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
It seems that is a complicated issue that is interrelated with a few factors
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-05-19 05:18 ---
Subject: Bug 30250
Author: ghazi
Date: Sat May 19 04:18:05 2007
New Revision: 124849
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124849
Log:
PR middle-end/30250
* builtins.c (do_mpfr_lgamma_
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-19 05:14 ---
Functionality installed on trunk.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-05-19 05:12 ---
Functionality installed on trunk.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-19 04:34 ---
I think this is fixed in 4.2.0 which was just released, i686-darwin was not
that well supported in GCCs before 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../.././libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes ../.././libiberty/regex.c -o
regex.o
/var/tmp//ccaaq6Zh.s:10725:indirect jmp without `*'
/var/tmp//ccaaq6Zh.s:10740:indirect jmp without `*'
/var/tmp//ccaaq6Zh.s:10755:indirect
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:47
---
This patch looks simple enough. Has it been regression tested? Anything else
planned with this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:38
---
Adding FX to cc. This is not a regression relative to 4.1, but its sure ugly!
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:29
---
I see it here too. This is a frontend problem I think. Looks to me like its
the transpose portion looking at -fdump-tree-original.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from hjl at lucon dot org 2007-05-19 02:52 ---
malloc is
void *malloc(size_t size);
and size_t is unsigned. I am not sure if checking size < 0 in Fortran is needed
or done properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31974
--- Comment #3 from gmorain at gmail dot com 2007-05-19 02:17 ---
(In reply to comment #2)
> I can reproduce the failure on powerpc-linux-gnu with 4.1.0 but it works on
> the
> trunk. combine is doing something wrong.
>
I tested it on 4.2.0, and it works OK. Except, I can't understan
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:10
---
Fixed on trunk, 4.3
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:07
---
Subject: Bug 31964
Author: jvdelisle
Date: Sat May 19 01:07:41 2007
New Revision: 124847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124847
Log:
2007-05-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:04
---
Subject: Bug 31964
Author: jvdelisle
Date: Sat May 19 01:04:03 2007
New Revision: 124846
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124846
Log:
2007-05-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #11 from malitzke at metronets dot com 2007-05-19 02:02 ---
Well, this is getting funny.
You and apparently others at gcc are looking at the computer-sofware world
through a high powered telescope and in this drastically reduced field of
vision you-all only see gcc. I refres
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31996
Just like PR 31995, this was found on the pointer plus branch after fixing
forwprop (note fowrwprop could be improved even more but that is a different
story and then we just get back to PR 31995 really), This testcase is really
vect-103 but modified to confuse data-ref:
/* { dg-require-effective-t
--- Comment #11 from patchapp at dberlin dot org 2007-05-19 01:30 ---
Subject: Bug number PR31716
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01265.html
--
http://gcc.gnu.org/bugzilla/s
While looking into some failures on the pointer plus branch after fixing up
forwprop, I noticed that we would get a failure in the vectorizer testsuite and
the reason is because we no longer could determine dependence for the two data
accesses.
Here is the testcase which is a modified version of v
conjg(transpose(a)) produces the wrong answers. Both absoft and ifort
produce correct answers.
program main
implicit none
complex (kind=4),dimension(2,2)::a,b,c
a(1,1) = (1.,1.)
a(2,1) = (2.,2.)
a(1,2) = (3.,3.)
a(2,2) = (4.,4.)
print *,"original",a
b=conjg(transpose(a))
print
--- Comment #2 from hjl at lucon dot org 2007-05-19 00:46 ---
I have verified that this patch
http://gcc.gnu.org/ml/fortran/2007-05/msg00123.html
causes the regression. FX, can you take a look? Thanks.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-05-18 23:58
---
Have to remind myself to submit the patch. The odd messages are from trying to
match and resolve other things, after failing already. I am working on a patch
to try circumvent some of these. Garbage in Garbage
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-05-18 23:52
---
Created an attachment (id=13582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13582&action=view)
Patch to eliminate segfault
This patch eliminates the segfault from the original test case and the last
tes
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-18 23:48
---
(In reply to comment #9)
> Mr Pinski
Well I am going to help now you have provided the preprocessed source for the
missed optimization (since that is all what it is), read the history behind
libgcc (it dates back b
--- Comment #9 from malitzke at metronets dot com 2007-05-18 23:45 ---
Mr Pinski
I give up. I hereby formally request that you, Mr. Pinksi, refrain from having
anything to do with problem reports originating from myself (Rainer
Malitzke-Goes alias Ray Malitzke). I rather see them langui
--- Comment #20 from m dot vegni at it-systems dot it 2007-05-18 23:31
---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
Testsuite ran on i686-pc-linux-gnu without failures (i've enabled c and
c++ only).
xorg-server now compiles as well.
The patch deserves more testing
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-18 23:13 ---
> You might just as well close on the basis of your last paragraph.
> This is really a documentation issue in getting the info to people like
> kernel.org and others writing programs for free-standing or embedded
--- Comment #7 from malitzke at metronets dot com 2007-05-18 23:10 ---
Created an attachment (id=13581)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13581&action=view)
timekeeping.i from ./kernel/time/timekeeping.c
Second requested attachemnt.
Observation:
You might just as wel
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||dgregor at gcc dot gnu dot
|
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
--- 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
--- 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
--
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 #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)
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 #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
--- 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 #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 #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 #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 #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 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 #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 #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 #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
"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 #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
--- 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 #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
"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 #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
--- 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 #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 #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 #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 #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
-
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |tree-optimization
Target Milestone|--- |4.2
--- 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
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 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
--- 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
1 - 100 of 130 matches
Mail list logo
